كما هو الحال في الإصدارات السابقة، يتضمّن Android 17 تغييرات في السلوك قد تؤثر في تطبيقك. وتنطبق تغييرات السلوك التالية حصريًا على التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android أو الإصدارات الأحدث. إذا كان تطبيقك يستهدف الإصدار 17 من نظام التشغيل Android أو الإصدارات الأحدث، عليك تعديل تطبيقك ليتوافق مع هذه السلوكيات، حيثما ينطبق ذلك.
احرص أيضًا على مراجعة قائمة التغييرات في السلوك التي تؤثر في جميع التطبيقات
التي تعمل على Android 17 بغض النظر عن targetSdkVersion لتطبيقك.
الوظيفة الأساسية
يتضمّن نظام التشغيل Android 17 التغييرات التالية التي تعدّل أو توسّع العديد من الإمكانات الأساسية لنظام التشغيل Android.
تنفيذ جديد لـ MessageQueue بدون قفل
بدءًا من الإصدار 17 من نظام التشغيل Android، تتلقّى التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (المستوى 37 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث تنفيذًا جديدًا غير متزامن للدالة android.os.MessageQueue. يحسّن التنفيذ الجديد الأداء ويقلّل من عدد اللقطات التي لم يتم عرضها، ولكن قد يؤدي إلى تعطّل التطبيقات التي تستخدم الحقول والأساليب الخاصة MessageQueue.
لمزيد من المعلومات، بما في ذلك استراتيجيات تخفيف الأثر، يُرجى الاطّلاع على إرشادات تغيير سلوك MessageQueue.
أصبحت الحقول الثابتة النهائية غير قابلة للتعديل
Apps running on Android 17 or higher that target
Android 17 (API level 37) or higher cannot change static final fields. If
an app attempts to change a static final field by using reflection, it will
cause an IllegalAccessException. Attempting to modify one of these fields
through JNI APIs (such as SetStaticLongField()) will cause the app to crash.
تسهيل الاستخدام
يُجري نظام التشغيل Android 17 التغييرات التالية لتحسين ميزات تسهيل الاستخدام.
تسهيل استخدام لوحة المفاتيح الخارجية المعقّدة الخاصة بمحرّك طرق الإدخال
تقدّم هذه الميزة واجهات برمجة تطبيقات جديدة، وهي AccessibilityEvent وTextAttribute
، لتحسين الملاحظات المنطوقة التي تقدّمها قارئات الشاشة عند إدخال النص بلغات CJKV. يمكن لتطبيقات محرر أسلوب الإدخال (IME) للغات CJKV الآن الإشارة إلى ما إذا تم اختيار مرشّح لتحويل النص أثناء إنشاء النص. يمكن للتطبيقات التي تتضمّن حقول تعديل تحديد أنواع تغيير النص عند إرسال أحداث تسهيل الاستخدام التي تشير إلى تغيير النص.
على سبيل المثال، يمكن للتطبيقات تحديد أنّ تغييرًا في النص قد حدث أثناء إنشاء النص، أو أنّ تغييرًا في النص نتج عن عملية إرسال.
يسمح ذلك لخدمات تسهيل الاستخدام، مثل قارئات الشاشة، بتقديم ملاحظات أكثر دقة استنادًا إلى طبيعة تعديل النص.
عدد التطبيقات التي تستخدم حِزم SDK
تطبيقات محرر أسلوب الإدخال (IME): عند ضبط إنشاء النص في حقول التعديل، يمكن لمحررات أسلوب الإدخال استخدام
TextAttribute.Builder.setTextSuggestionSelected()للإشارة إلى ما إذا تم اختيار مرشّح معيّن للتحويل.التطبيقات التي تتضمّن حقول تعديل: يمكن للتطبيقات التي تحتفظ بـ
InputConnectionمخصّص استرداد بيانات اختيار المرشّح من خلال استدعاءTextAttribute.isTextSuggestionSelected(). بعد ذلك، يجب أن تستدعي هذه التطبيقاتAccessibilityEvent.setTextChangeTypes()عند إرسال أحداثTYPE_VIEW_TEXT_CHANGED. سيتم تفعيل هذه الميزة تلقائيًا للتطبيقات التي تستهدف الإصدار Android 17 (مستوى واجهة برمجة التطبيقات 37) والتي تستخدمTextViewالعادي. (أي أنّTextViewسيتولّى استرداد البيانات من محرر أسلوب الإدخال وضبط أنواع تغيير النص عند إرسال الأحداث إلى خدمات تسهيل الاستخدام).خدمات تسهيل الاستخدام: يمكن لخدمات تسهيل الاستخدام التي تعالج أحداث
TYPE_VIEW_TEXT_CHANGEDاستدعاءAccessibilityEvent.getTextChangeTypes()لتحديد طبيعة التعديل وتعديل استراتيجيات الملاحظات وفقًا لذلك.
الخصوصية
يتضمّن نظام التشغيل Android 17 التغييرات التالية لتحسين خصوصية المستخدم.
تفعيل ECH (Encrypted Client Hello)
Android 17 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.
For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the client sends an ECH extension with randomized contents (a mechanism called ECH GREASE). See RFC 9849 for more details on how ECH GREASE works.
To allow apps to customize this behavior, Android 17 adds a new
<domainEncryption> element to the Network Security Configuration file.
Developers can use <domainEncryption> within <base-config> or
<domain-config> tags to select an ECH mode (for example,
"enabled" or "disabled") on a global or per-domain basis.
For more information, see the Encrypted Client Hello documentation.
يجب منح إذن الوصول إلى الشبكة المحلية للتطبيقات التي تستهدف الإصدار 17 من Android
Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission
to protect users from unauthorized local network access. Because this falls
under the existing NEARBY_DEVICES permission group, users who have already
granted other NEARBY_DEVICES permissions aren't prompted again. This new
requirement prevents malicious apps from exploiting unrestricted local network
access for covert user tracking and fingerprinting. By declaring and requesting
this permission, your app can discover and connect to devices on the local area
network (LAN), such as smart home devices or casting receivers.
Apps targeting Android 17 (API level 37) or higher now have two paths to maintain communication with LAN devices: Adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.
For more information, see the Local network permission documentation.
إخفاء كلمات المرور من الأجهزة المادية
إذا كان التطبيق يستهدف الإصدار 17 من نظام التشغيل Android (المستوى 37 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث وكان المستخدم يستخدم جهاز إدخال ماديًا (مثل لوحة مفاتيح خارجية)، سيطبِّق نظام التشغيل Android إعداد show_passwords_physical الجديد على جميع الأحرف في حقل كلمة المرور. يخفي هذا الإعداد تلقائيًا جميع أحرف كلمة المرور.
يعرض نظام Android آخر حرف تم إدخاله من كلمة المرور لمساعدة المستخدم في معرفة ما إذا كان قد أخطأ في كتابة كلمة المرور. ومع ذلك، يصبح هذا الإجراء أقل ضرورة مع لوحات المفاتيح الخارجية الأكبر حجمًا. بالإضافة إلى ذلك، غالبًا ما تحتوي الأجهزة التي تتضمّن لوحات مفاتيح خارجية على شاشات أكبر، ما يزيد من خطر أن يرى شخص ما كلمة المرور التي تم إدخالها.
إذا كان المستخدم يستعمل شاشة الجهاز التي تعمل باللمس، سيطبّق النظام الإعداد الجديد
show_passwords_touch.
حماية كلمات المرور الصالحة لمرة واحدة في رسائل SMS العادية
Beginning with Android 17, Android is extending its SMS OTP protection
to apply to standard SMS messages (SMS messages containing an OTP that do not
use the WebOTP or SMS Retriever formats). For most apps targeting
Android 17 (API level 37) or higher, these SMS messages do not become
available until three hours after receipt. This delay is intended to help
prevent OTP hijacking. During this three hour delay, the
SMS_RECEIVED_ACTION broadcast is withheld and
SMS provider database queries are filtered. The SMS message is
available to these apps after the delay.
Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.
الأمان
يُجري نظام التشغيل Android 17 التحسينات التالية على أمان الأجهزة والتطبيقات.
أمان النشاط
في نظام التشغيل Android 17، تواصل المنصة انتقالها إلى بنية "آمنة تلقائيًا"، حيث تقدّم مجموعة من التحسينات المصمَّمة للحدّ من الثغرات الأمنية الخطيرة، مثل التصيّد الاحتيالي واختطاف التفاعلات وهجمات "الوكيل المرتبك". يتطلّب هذا التعديل أن يوافق المطوّرون صراحةً على معايير الأمان الجديدة للحفاظ على توافق التطبيق وحماية المستخدمين.
تشمل التأثيرات الرئيسية على المطوّرين ما يلي:
- تحسين قيود BAL وتحسين خيار الموافقة: نعمل على تحسين قيود تشغيل النشاط في الخلفية (BAL) من خلال توسيع نطاق الحماية ليشمل
IntentSender. على المطوّرين التوقّف عن استخدام الثابت القديمMODE_BACKGROUND_ACTIVITY_START_ALLOWED. بدلاً من ذلك، يجب استخدام عناصر تحكّم دقيقة، مثلMODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE، التي تقصر عمليات بدء الأنشطة على السيناريوهات التي يكون فيها تطبيق الاتصال مرئيًا، ما يقلّل بشكل كبير من مساحة الهجوم. - أدوات التوافق: على المطوّرين استخدام الوضع الصارم وعمليات التحقّق المعدَّلة من أداة lint لتحديد الأنماط القديمة وضمان الاستعداد لمتطلبات حزمة تطوير البرامج (SDK) المستقبلية.
تفعيل "المحادثة الذكية" تلقائيًا
إذا كان التطبيق يستهدف الإصدار 17 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 37) أو الإصدارات الأحدث، سيتم تفعيل شفافية الشهادات (CT) تلقائيًا. (في نظام التشغيل Android 16، تتوفّر ميزة "التوافق مع التطبيقات"، ولكن يجب أن تفعّلها التطبيقات).
Safer Native DCL—C
إذا كان تطبيقك يستهدف الإصدار 17 من Android (المستوى 37 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث، فإنّ الحماية من تحميل الرموز البرمجية الديناميكية (DCL) الأكثر أمانًا التي تم طرحها في Android 14 لملفات DEX وJAR تشمل الآن المكتبات الأصلية.
يجب وضع علامة "للقراءة فقط" على جميع الملفات الأصلية التي يتم تحميلها باستخدام System.load().
وبخلاف ذلك، يعرض النظام الخطأ UnsatisfiedLinkError.
ننصح التطبيقات بتجنُّب تحميل الرموز البرمجية ديناميكيًا قدر الإمكان، لأنّ ذلك يزيد بشكل كبير من خطر تعرُّض التطبيق للاختراق من خلال إدخال رموز برمجية أو التلاعب بها.
تقييد حقول معلومات التعريف الشخصية في عرض بيانات CP2
For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) restricts certain columns containing Personally Identifiable Information (PII) from the data view. When this change is enabled, these columns are removed from the data view to enhance user privacy. The restricted columns include:
Apps that are using these columns from ContactsContract.Data
can extract them from ContactsContract.RawContacts
instead, by joining with RAW_CONTACT_ID.
فرض عمليات التحقّق الصارمة من SQL في CP2
بالنسبة إلى التطبيقات التي تستهدف الإصدار 17 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 37) والإصدارات الأحدث، يفرض مقدِّم جهات الاتصال 2 (CP2) عملية تحقّق صارمة من صحة طلبات بحث SQL عند الوصول إلى الجدول ContactsContract.Data بدون إذن READ_CONTACTS.
بموجب هذا التغيير، إذا لم يكن لدى التطبيق إذن READ_CONTACTS، سيتم ضبط الخيارَين StrictColumns وStrictGrammar عند طلب البحث في جدول ContactsContract.Data. إذا كان طلب البحث يستخدم نمطًا غير متوافق مع هذه الأنماط، سيتم رفضه وسيؤدي إلى حدوث استثناء.
الوسائط
يتضمّن نظام التشغيل Android 17 التغييرات التالية على سلوك الوسائط.
تعزيز أمان الصوت في الخلفية
Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.
Some audio restrictions apply to all apps. However, the restrictions are more stringent if an app targets Android 17 (API level 37). If one of these apps interacts with audio while it is in the background, it must have a foreground service running. In addition, the app must meet one or both of these requirements:
- The foreground service must have while-in-use (WIU) capabilities.
- The app must have the exact alarm permission and be interacting with
USAGE_ALARMaudio streams.
For more information, including mitigation strategies, see Background audio hardening.
أشكال الأجهزة
يتضمّن نظام التشغيل Android 17 التغييرات التالية لتحسين تجربة المستخدم على مجموعة من أحجام الأجهزة وعوامل الشكل.
تغييرات في واجهة برمجة التطبيقات الخاصة بالمنصة لتجاهل قيود الاتجاه وإمكانية تغيير الحجم ونسبة العرض إلى الارتفاع على الشاشات الكبيرة (sw>=600dp)
We introduced Platform API changes in Android 16 to ignore orientation, aspect ratio, and resizability restrictions on large screens (sw >= 600dp) for apps targeting API level 36 or higher. Developers have the option to opt out of these changes with SDK 36, but this opt-out will no longer be available for apps that target Android 17 (API level 37) or higher.
For more information, see Restrictions on orientation and resizability are ignored.
إمكانية الاتصال
يقدّم نظام التشغيل Android 17 التغيير التالي لتحسين التوافق
والتوافق مع سلوك InputStream العادي في Java لمقابس RFCOMM عبر البلوتوث.
سلوك متسق للدالة read() في BluetoothSocket مع RFCOMM
For apps targeting Android 17 (API level 37), the
read() method of the InputStream obtained from an
RFCOMM-based BluetoothSocket now returns -1 when the
socket is closed or the connection is dropped.
This change makes RFCOMM socket behavior consistent with LE CoC sockets and
aligns with the standard InputStream.read()
documentation, which states that -1 is returned when the end of the stream is
reached.
Apps that rely solely on catching an IOException to break out of a read loop may
be impacted by this change and should update the BluetoothSocket read loops to
explicitly check for a return value of -1. This ensures the loop terminates
correctly when the remote device disconnects or the socket is closed. For an
example of the recommended implementation, see the
code snippet in the Transfer Bluetooth data
guide.