يقدّم الإصدار Android 9 (المستوى 28 من واجهة برمجة التطبيقات) عددًا من التغييرات في نظام Android. تسري تغييرات السلوك التالية على جميع التطبيقات عند تشغيلها على نظام Android 9 الأساسي، بغض النظر عن مستوى واجهة برمجة التطبيقات الذي تستهدفه. يجب على جميع المطورين مراجعة هذه التغييرات وتعديل تطبيقاتهم لدعمها بشكل صحيح، حيثما ينطبق ذلك على التطبيق.
لمعرفة التغييرات التي لا تؤثر سوى في التطبيقات التي تستهدف المستوى 28 من واجهة برمجة التطبيقات أو مستوى أعلى، يُرجى الاطّلاع على تغييرات السلوك: التطبيقات التي تستهدف المستوى 28 من واجهة برمجة التطبيقات +28.
إدارة الطاقة
يقدّم Android 9 ميزات جديدة لتحسين إدارة طاقة الجهاز. هذه التغييرات بالإضافة إلى الميزات التي كانت متوفّرة قبل Android 9 تساعد في ضمان توفُّر موارد النظام للتطبيقات التي تحتاج إليها أكثر من غيرها.
لمعرفة التفاصيل، يُرجى الاطّلاع على إدارة الطاقة.
تغييرات الخصوصية
لتحسين خصوصية المستخدم، يقدّم Android 9 تغييرات متعددة في السلوك، مثل الحدّ من وصول التطبيقات التي تعمل في الخلفية إلى أجهزة استشعار الجهاز، وحظر المعلومات التي يتم استردادها من عمليات البحث عن شبكات Wi-Fi، وقواعد الأذونات الجديدة ومجموعات الأذونات المتعلقة بالمكالمات الهاتفية وحالة الهاتف وعمليات البحث عن شبكات Wi-Fi.
تؤثّر هذه التغييرات في جميع التطبيقات التي تعمل بالإصدار 9 من Android، بغض النظر عن إصدار حزمة تطوير البرامج (SDK) المستهدَف.
وصول محدود إلى أجهزة الاستشعار في الخلفية
يحدّ Android 9 من قدرة التطبيقات التي تعمل في الخلفية على الوصول إلى مدخلات المستخدم وبيانات جهاز الاستشعار. إذا كان تطبيقك يعمل في الخلفية على جهاز يعمل بنظام التشغيل Android 9، سيطبّق النظام القيود التالية على تطبيقك:
- لا يمكن لتطبيقك الوصول إلى الميكروفون أو الكاميرا.
- لا تتلقى أجهزة الاستشعار التي تستخدم وضع إعداد التقارير المستمر، مثل مقاييس التسارع والجيروسكوب، أي أحداث.
- أجهزة الاستشعار التي تستخدم وضعَي إعداد التقارير عند التغيير أو اللقطة الواحدة لا تتلقّى الأحداث.
إذا كان تطبيقك يحتاج إلى رصد أحداث أداة الاستشعار على الأجهزة التي تعمل بنظام التشغيل Android 9، استخدِم خدمة تعمل في المقدّمة.
تم حظر الوصول إلى سجلّات المكالمات.
يقدّم Android 9 مجموعة أذونات
CALL_LOG وينقل أذونات
READ_CALL_LOG
وWRITE_CALL_LOG
وPROCESS_OUTGOING_CALLS
إلى هذه المجموعة. في إصدارات Android السابقة، كانت هذه الأذونات
ضمن مجموعة أذونات PHONE.
تمنح مجموعة أذونات CALL_LOG هذه المستخدمين إمكانية التحكّم وأذونات الوصول بشكل أفضل للتطبيقات التي تحتاج إلى الوصول إلى معلومات حساسة حول المكالمات الهاتفية، مثل قراءة سجلات المكالمات الهاتفية وتحديد أرقام الهواتف.
إذا كان تطبيقك يتطلب الوصول إلى سجلات المكالمات أو يحتاج إلى معالجة مكالمات صادرة، يجب
طلب هذه الأذونات صراحةً من مجموعة أذونات
CALL_LOG. وفي حال عدم حدوث ذلك، يتم عرض SecurityException.
ملاحظة: بما أنّ هذه الأذونات قد غيّرت المجموعات ويتم منحها في وقت التشغيل، يمكن للمستخدم رفض وصول تطبيقك إلى معلومات سجلات المكالمات الهاتفية. في هذه الحالة، يجب أن يتمكّن تطبيقك من التعامل مع نقص الوصول إلى المعلومات بشكلٍ ملائم.
إذا كان تطبيقك يتّبع أفضل الممارسات المتعلقة بأذونات التشغيل، يمكنه التعامل مع التغيير في مجموعة الأذونات.
تم حظر الوصول إلى أرقام الهواتف
إنّ التطبيقات التي تعمل على نظام التشغيل Android 9 لا يمكنها قراءة أرقام الهواتف أو حالة الهاتف بدون
الحصول أولاً على إذن
READ_CALL_LOG
بالإضافة إلى الأذونات الأخرى التي تتطلبها حالات استخدام التطبيق.
تظهر أرقام الهواتف المرتبطة بالمكالمات الواردة والصادرة في
البث الخاص بحالة الهاتف،
مثل المكالمات الواردة والصادرة، ويمكن الوصول إليها من خلال صف
PhoneStateListener.
في حال عدم الحصول على إذن
READ_CALL_LOG، يكون حقل رقم الهاتف الذي يتم توفيره في
PHONE_STATE_CHANGED عمليات بث وخلال PhoneStateListener فارغًا.
لقراءة أرقام الهواتف من حالة الهاتف، عليك تحديث التطبيق لطلب الأذونات الضرورية استنادًا إلى حالة استخدامك:
- لقراءة الأرقام من إجراء
النية الخاص بالسمة
PHONE_STATE، عليك الحصول على كلٍّ من إذنREAD_CALL_LOGوإذنREAD_PHONE_STATE. - لقراءة الأرقام من
onCallStateChanged()، تحتاج إلى إذنREAD_CALL_LOGفقط. ولن تحتاج إلى إذنREAD_PHONE_STATE.
تم تقييد الوصول إلى معلومات الموقع الجغرافي والاتصال بشبكة Wi-Fi.
في الإصدار 9 من Android، تكون متطلبات الأذونات التي يتطلبها التطبيق من أجل إجراء عمليات البحث عن شبكات Wi-Fi أكثر صرامة مقارنةً بالإصدارات السابقة. لمعرفة التفاصيل، يُرجى الاطّلاع على قيود البحث عن شبكات Wi-Fi.
وتنطبق قيود مماثلة أيضًا على الطريقة
getConnectionInfo()
التي تعرض عنصر WifiInfo
يصف اتصال Wi-Fi الحالي. يمكنك فقط استخدام طرق هذا الكائن لاسترداد قيم SSID ومعرّف مجموعة الخدمات الأساسية (BSSID) إذا كان تطبيق الاتصال لديه الأذونات التالية:
- ACCESS_FINE_LOCATION أو ACCESS_COARSE_LOCATION
- حالة ACCESS_WIFI_STATE
يتطلب استرداد SSID أو معرّف مجموعة الخدمات الأساسية (BSSID) أيضًا تفعيل خدمات الموقع الجغرافي على الجهاز (ضمن الإعدادات > الموقع الجغرافي).
المعلومات التي تتم إزالتها من طرق خدمة Wi-Fi
في الإصدار 9 من نظام التشغيل Android، لا تتلقّى الأحداث وعمليات البث التالية أي معلومات عن الموقع الجغرافي للمستخدم أو بيانات تحديد الهوية الشخصية:
- الطريقة
getScanResults()وgetConnectionInfo()منWifiManager. - الطريقتان
discoverServices()وaddServiceRequest()منWifiP2pManager. - بث
NETWORK_STATE_CHANGED_ACTION.
لم يعُد بث نظام NETWORK_STATE_CHANGED_ACTION
من Wi-Fi يحتوي على SSID (المعروف سابقًا باسم EXTRA_SSID)
أو معرّف مجموعة الخدمات الأساسية (BSSID) (المعروف سابقًا باسم EXTRA_BSSID) أو معلومات الاتصال (المعروفة سابقًا باسم
EXTRA_NETWORK_INFO). إذا كان تطبيقك بحاجة إلى هذه المعلومات، يمكنك استدعاء
getConnectionInfo()
بدلاً من ذلك.
تعتمد معلومات الاتصال الهاتفي الآن على إعداد الموقع الجغرافي للجهاز
إذا أوقف المستخدم الموقع الجغرافي للجهاز على جهاز يعمل بالإصدار 9 من نظام التشغيل Android، لن تظهر النتائج باتّباع الطرق التالية:
قيود استخدام الواجهات غير المستندة إلى حزمة تطوير البرامج (SDK)
للمساعدة في ضمان استقرار التطبيق وتوافقه، تحظر المنصة استخدام بعض الطرق والحقول التي لا تتضمنها حزمة SDK. تنطبق هذه القيود سواء حاولت الوصول إلى هذه الطرق والحقول مباشرةً من خلال التفكير أو استخدام JNI. في Android 9، يمكن لتطبيقك الاستمرار في الوصول إلى هذه الواجهات المقيَّدة، ويستخدم النظام الأساسي نخب محمصة وإدخالات السجل للفت انتباهك إليها. إذا كان تطبيقك يُظهر اهتمامًا كبيرًا، من المهم أن تتابع استراتيجية تنفيذ أخرى غير الواجهة المحدودة. إذا كنت تعتقد أنّه لا يمكن استخدام استراتيجية بديلة، يمكنك الإبلاغ عن خطأ لطلب إعادة النظر في الحظر.
تحتوي القيود المفروضة على الواجهات غير المستندة إلى حزمة تطوير البرامج (SDK) على معلومات مهمة أخرى. يجب عليك مراجعته لضمان استمرار عمل تطبيقك بشكل صحيح.
تغييرات في سلوك الأمان
التغييرات في أمان الجهاز
يضيف Android 9 إمكانات متعددة لتحسين أمان تطبيقك، بغض النظر عن الإصدار الذي يستهدفه تطبيقك.
تغييرات تنفيذ بروتوكول أمان طبقة النقل (TLS)
خضع تنفيذ بروتوكول أمان طبقة النقل (TLS) للنظام لعدة تغييرات في Android 9:
- إذا تعذّر الاتصال بين مثيل
SSLSocketأثناء إنشائه، يطرح النظامIOExceptionبدلاً منNullPointerException. - تتعامل فئة
SSLEngineبعناية مع أي تنبيهاتclose_notifyيتم تلقّيها.
لمعرفة مزيد من المعلومات حول إجراء طلبات ويب آمنة في تطبيق Android، يمكنك الاطّلاع على مثال HTTPS.
فلتر SECCOMP أكثر صرامة
يفرض Android 9 مزيدًا من القيود على مكالمات النظام المتاحة للتطبيقات. يُعد هذا السلوك امتدادًا لفلتر SECCOMP الذي يتضمنه Android 8.0 (مستوى واجهة برمجة التطبيقات 26).
التغييرات في التشفير
أدخل Android 9 تغييرات عديدة على تنفيذ خوارزميات التشفير والتعامل معها.
عمليات تنفيذ المعلَمات والخوارزميات لتشفير البيانات
يوفر Android 9 عمليات تنفيذ إضافية لمَعلمات الخوارزمية في Conscrypt. تتضمن هذه المعلَمات: AES وDESEDE وOAEP وEC. تم إيقاف إصدارات Bouncy Castle لهذه المَعلمات والعديد من الخوارزميات بدءًا من نظام التشغيل Android 9.
إذا كان تطبيقك يستهدف Android 8.1 (المستوى 27 لواجهة برمجة التطبيقات) أو إصدارًا أقدم، ستتلقّى تحذيرًا
عند طلب تنفيذ Bouncy Castle إحدى هذه الخوارزميات التي تم إيقافها. ومع ذلك، إذا كنت تستهدف الإصدار 9 من Android، سيؤدي كل طلب إلى عرض
NoSuchAlgorithmException.
تغييرات أخرى
يقدِّم Android 9 تغييرات أخرى تتعلّق بالتشفير:
- عند استخدام مفاتيح PBE، إذا كانت لعبة Bouncy Castle تتوقع متجهًا للإعداد (IV) ولم يوفر تطبيقك متجهًا، ستتلقّى تحذيرًا.
- يسمح لك تنفيذ Conscrypt لشفرة ARC4 بتحديد ARC4/ECB/NoPadding أو ARC4/NONE/NoPadding.
- تمت إزالة موفّر بنية تشفير جافا (JCA). ونتيجةً
لذلك، إذا استدعى تطبيقك
SecureRandom.getInstance("SHA1PRNG", "Crypto")، سيحدث خطأNoSuchProviderException. - إذا حلَّل تطبيقك مفاتيح RSA من مخازن مؤقتة أكبر من بنية المفتاح، لن يحدث استثناء بعد ذلك.
لمعرفة المزيد حول استخدام ميزات التشفير في Android، يمكنك الاطّلاع على التشفير.
الملفات المشفّرة الآمنة على أجهزة Android لم تعُد متاحة.
يزيل Android 9 تمامًا التوافق مع ملفات التشفير الآمنة (ASECs) على نظام التشغيل Android.
في الإصدار 2.2 من نظام التشغيل Android (المستوى 8 من واجهة برمجة التطبيقات)، قدّم Android تكنولوجيا ASECs لإتاحة وظائف التطبيقات على بطاقة SD. في نظام التشغيل Android 6.0 (المستوى 23 من واجهة برمجة التطبيقات)، قدّمت المنصة تقنية جهاز تخزين قابل للاستخدام يمكن للمطوّرين استخدامها بدلاً من ASEC.
تعديلات على مكتبات وحدة العناية المركّزة (ICU)
يستخدم Android 9 الإصدار 60 من مكتبة وحدة العناية المركّزة (ICU). يستخدم Android 8.0 (مستوى واجهة برمجة التطبيقات 26) وAndroid 8.1 (مستوى واجهة برمجة التطبيقات 27) وحدة ICU 58.
تُستخدم وحدة ICU لتوفير واجهات برمجة التطبيقات العامة أسفل android.icu package
ويتم استخدامها داخليًا في نظام Android الأساسي لإتاحة تنفيذ الانتشار على نطاق عالمي.
على سبيل المثال، يتم استخدامه لتنفيذ صفوف Android في java.util وjava.text وandroid.text.format.
يتضمّن تحديث ICU 60 العديد من التغييرات البسيطة والمفيدة، من بينها التوافق مع بيانات Emoji 5.0 وتنسيقات التاريخ/الوقت المحسَّنة، كما هو موثّق في ملاحظات إصدار ICU 59 وICU 60.
التغييرات البارزة في هذا التحديث:
- تم تغيير طريقة معالجة النظام الأساسي للمناطق الزمنية.
- تتعامل المنصة مع توقيت غرينيتش والتوقيت العالمي المنسق بشكل أفضل، ولم يعُد التوقيت العالمي المنسَّق مرادفًا لتوقيت غرينيتش.
توفر وحدة العناية المركّزة (ICU) الآن أسماء مناطق مترجمة لتوقيت غرينيتش والتوقيت العالمي المنسق. يؤثّر هذا التغيير في سلوك التنسيق والتحليل في
android.icuلمناطق، مثل "GMT" و"Etc/GMT" و"UTC" و"Etc/UTC" و "Zulu". - يستخدم
java.text.SimpleDateFormatالآن وحدة العناية المركّزة (ICU) لتوفير أسماء معروضة بالتوقيت العالمي المنسّق أو توقيت غرينتش، وهو ما يعني:- يؤدي تنسيق
zzzzإلى إنشاء سلسلة مترجَمة طويلة للعديد من اللغات. وفي السابق، كان هذا التقرير يُصدر "التوقيت العالمي المنسق" (UTC) وسلاسل مثل "GMT+00:00" لتوقيت غرينتش. - يتعرَّف تحليل
zzzzعلى سلاسل مثل "التوقيت العالمي المنسَّق" و "توقيت غرينتش". - قد تواجه التطبيقات مشاكل توافق إذا افترضت أنّ "التوقيت العالمي المنسق" أو "GMT+00:00" يتم عرضها للسمة
zzzzفي جميع اللغات.
- يؤدي تنسيق
- تم تغيير سلوك
java.text.DateFormatSymbols.getZoneStrings():- كما هي الحال في
SimpleDateFormat، أصبح للتوقيت العالمي المتفق عليه وتوقيت غرينيتش أسماء طويلة. تصبح صيغ DST لأسماء المناطق الزمنية للمنطقة الزمنية بالتوقيت العالمي المنسّق (UTC)، مثل "UTC" و"Etc/UTC" و "Zulu"، GMT+00:00، وهو العنصر الاحتياطي القياسي في حال عدم توفر أسماء، بدلاً من السلسلةUTCغير القابلة للتغيير في البرنامج. - يتم التعرّف على بعض أرقام تعريف المناطق بشكل صحيح كمرادفات لمناطق
أخرى، ما يتيح لنظام Android العثور على سلاسل لأرقام تعريف مناطق قديمة، مثل
Eire، لم يكن من الممكن حلها في السابق.
- كما هي الحال في
- لم تعُد آسيا/هانوي منطقة معروفة. لهذا السبب، لا تعرض السمة
java.util.TimeZones.getAvailableIds()هذه القيمة، ولا تتعرّف عليها السمةjava.util.TimeZone.getTimeZone(). ويتوافق هذا السلوك مع سلوكandroid.icuالحالي.
- تتعامل المنصة مع توقيت غرينيتش والتوقيت العالمي المنسق بشكل أفضل، ولم يعُد التوقيت العالمي المنسَّق مرادفًا لتوقيت غرينيتش.
- قد تعرض الطريقة
android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String)خطأParseExceptionحتى عند تحليل نص العملة الصحيح. يمكنك تجنُّب هذه المشكلة باستخدامNumberFormat.parseCurrency، وهو متاح بدءًا من الإصدار Android 7.0 (المستوى 24 من واجهة برمجة التطبيقات) لنص العملة بنمطPLURALCURRENCYSTYLE.
التغييرات في اختبار Android
يقدّم Android 9 تغييرات عديدة على مكتبة إطار عمل Android Test وبنية الصفوف الدراسية. تساعد هذه التغييرات المطوّرين على استخدام واجهات برمجة التطبيقات العامة والمتوافقة مع إطار العمل، لكن التغييرات تتيح أيضًا المزيد من المرونة في إنشاء الاختبارات وتشغيلها باستخدام مكتبات تابعة لجهات خارجية أو منطق مخصَّص.
إزالة المكتبات من إطار العمل
يعيد Android 9 تنظيم الفئات المستندة إلى JUnit في ثلاث مكتبات:
android.test.base وandroid.test.runner وandroid.test.mock.
يسمح لك هذا التغيير بإجراء اختبارات على إصدار من JUnit يعمل بشكل أفضل مع تبعيات مشروعك. قد يكون هذا الإصدار من JUnit مختلفًا عن
الإصدار الذي يوفره android.jar.
لمعرفة المزيد من المعلومات حول كيفية تنظيم الصفوف المستندة إلى JUnit في هذه المكتبات، وكيفية إعداد مشروع تطبيقك لكتابة الاختبارات وإجراء الاختبارات، يمكنك الاطّلاع على إعداد مشروع لتطبيق Android Test.
تغييرات إصدار حزمة الاختبار
تمت إزالة طريقة addRequirements() من الفئة
TestSuiteBuilder، وإيقاف الفئة TestSuiteBuilder نفسها.
تطلبت الطريقة addRequirements() من المطوّرين تقديم وسيطات تكون أنواعها واجهات برمجة تطبيقات مخفية، ما يجعل واجهة برمجة التطبيقات غير صالحة.
أداة فك ترميز UTF في Java
UTF-8 هي مجموعة الأحرف التلقائية في Android. يمكن فك ترميز تسلسل UTF-8 بايت باستخدام الدالة الإنشائية String، مثل String(byte[] bytes).
يتّبع برنامج فك ترميز UTF-8 في Android 9 معايير Unicode بشكل أكثر صرامة مقارنةً بالإصدارات السابقة. وتشمل التغييرات ما يلي:
- يتم التعامل مع الصيغة غير الأقصر من رموز UTF-8، مثل
<C0, AF>، على أنّها غير صحيحة. - يتم التعامل مع التنسيق البديل لترميز UTF-8، مثل
U+D800..U+DFFFعلى أنّه غير صحيح. - ويتم استبدال الحد الأقصى للجزء الفرعي بـ
U+FFFDواحدة. على سبيل المثال، في تسلسل البايت "41 C0 AF 41 F4 80 80 41"، تكون الأجزاء الفرعية القصوى هي "C0" و"AF" و"F4 80 80." ويمكن أن تكون "F4 80 80" النتيجة الفرعية الأولية لـ "F4 80 80 80"، ولكن لا يمكن أن تكون "C0" النتيجة الفرعية الأولية لأي تسلسل وحدات تعليمات برمجية جيد التكوين. وبالتالي، يجب أن يكون الناتج "A\ufffd\ufffdA\ufffdA". - لفك ترميز تسلسل UTF-8 / CESU-8 المعدَّل في نظام التشغيل Android 9 أو الإصدارات الأحدث، استخدِم الطريقة
DataInputStream.readUTF()أو طريقة JNINewStringUTF().
إثبات ملكية اسم المضيف باستخدام شهادة
يصف المعيار RFC 2818 طريقتين لمطابقة اسم نطاق مع شهادة، وذلك باستخدام الأسماء المتاحة ضمن الامتداد subjectAltName (SAN)، أو في حال عدم توفّر الامتداد SAN، بالرجوع إلى commonName (CN).
ومع ذلك، تم إيقاف الإجراء الاحتياطي إلى CN نهائيًا في RFC 2818. لهذا السبب،
لم يعد نظام Android يستخدم CN. للتحقّق من اسم المضيف، على الخادم
تقديم شهادة تحتوي على SAN مطابق. أمّا الشهادات التي لا تحتوي على SAN يتطابق مع اسم المضيف، فلا تصبح موثوقة.
عمليات البحث عن عنوان الشبكة يمكن أن تؤدي إلى حدوث انتهاكات في الشبكة
قد تتضمن عمليات البحث عن عنوان الشبكة التي تتطلب تحليل الاسم إدخال/إخراج الشبكة وبالتالي تُعد عمليات حظر. يمكن أن تؤدي عمليات الحظر التي تجريها على سلسلة التعليمات الرئيسية إلى عمليات إيقاف مؤقت أو بيانات غير مكتملة.
الفئة StrictMode هي أداة تطوير تساعد المطوّرين في اكتشاف المشاكل في الرموز البرمجية.
في الإصدار 9 من نظام Android والإصدارات الأحدث، يرصد StrictMode انتهاكات الشبكة
التي تسببها عمليات البحث عن عناوين الشبكة والتي تتطلب تحليل الاسم.
يجب ألّا تشحن تطبيقاتك مع تفعيل "StrictMode". وفي حال إجراء ذلك، قد تحصل تطبيقاتك على استثناءات، مثل NetworkOnMainThreadException عند استخدام طريقتَي
detectNetwork() أو
detectAll() للحصول على سياسة
ترصد انتهاكات الشبكة.
لا يُعد حل عنوان IP الرقمي عملية حظر. تعمل درجة دقة عنوان IP الرقمي كما هي الحال في الإصدارات السابقة على الإصدار 9 من Android.
وضع علامات على المقابس
في إصدارات النظام الأساسي الأقدم من نظام التشغيل Android 9، إذا تم
وضع علامات على المقبس باستخدام طريقة
setThreadStatsTag()،
لن يتم وضع علامة على المقبس عند إرساله إلى عملية أخرى باستخدام
بروتوكول IPC
مع حاوية ParcelFileDescriptor.
في الإصدار 9 من نظام Android والإصدارات الأحدث، يتم الاحتفاظ بعلامة المقبس عند إرسالها إلى عملية أخرى باستخدام IPC للغلاف. قد يؤثر هذا التغيير في إحصاءات حركة بيانات الشبكة، مثلاً عند استخدام طريقة queryDetailsForUidTag().
إذا كنت تريد الاحتفاظ بسلوك الإصدارات السابقة، التي تزيل علامة
مأخذ يتم إرساله إلى عملية أخرى، يمكنك استدعاء
untagSocket() قبل إرسال
المقبس.
مقدار وحدات البايت المتاحة التي تم الإبلاغ عنها في المقبس
تعرض الطريقة available() القيمة 0 عند استدعائها بعد استدعاء طريقة shutdownInput().
إعداد تقارير أكثر تفصيلاً عن إمكانات الشبكة للشبكات الافتراضية الخاصة
في نظام التشغيل Android 8.1 (مستوى واجهة برمجة التطبيقات 27) والإصدارات الأقدم، أبلغَت الفئة NetworkCapabilities فقط عن مجموعة محدودة من المعلومات للشبكات الافتراضية الخاصة، مثل TRANSPORT_VPN، ولكن تم حذف
NET_CAPABILITY_NOT_VPN. جعلت هذه المعلومات المحدودة من الصعب تحديد ما إذا كان استخدام شبكة VPN سيؤدي إلى تحصيل رسوم
من مستخدم التطبيق. على سبيل المثال، لن يؤدي التحقق من
"NET_CAPABILITY_NOT_METERED" إلى تحديد
ما إذا كانت الشبكات الأساسية تفرض تكلفة استخدام أو لا.
في الإصدار 9 من نظام Android والإصدارات الأحدث، عندما تستدعي شبكة VPN طريقة
setUnderlyingNetworks()، يدمج نظام Android عمليات النقل والإمكانات الخاصة بأي
شبكات أساسية ويعرض النتيجة على أنها إمكانات فعّالة للشبكة
الخاصة بشبكة VPN.
في الإصدار 9 من نظام Android والإصدارات الأحدث، تتلقّى التطبيقات التي سبق أن تم التحقّق منها
NET_CAPABILITY_NOT_METERED إمكانات الشبكة الافتراضية الخاصة والشبكات الأساسية.
لم تعُد الملفات في مجلد xt_qtaguid متاحة للتطبيقات.
بدءًا من نظام التشغيل Android 9، لا يُسمح للتطبيقات بالحصول على
إذن وصول مباشر للقراءة إلى الملفات في مجلد /proc/net/xt_qtaguid. السبب هو ضمان الاتساق مع بعض الأجهزة التي لا تحتوي على هذه الملفات على الإطلاق.
وتواصل واجهات برمجة التطبيقات العامة التي تعتمد على هذين الملفين، TrafficStats وNetworkStatsManager، العمل على النحو المطلوب.
ومع ذلك، قد لا تعمل دوال cutil
غير المتوافقة، مثل
qtaguid_tagSocket()،
كما هو متوقع، أو قد لا تعمل مطلقًا، على أجهزة مختلفة.
متطلب FLAG_activity_NEW_TASK تم فرضه الآن.
في الإصدار 9 من Android، لا يمكنك بدء النشاط من
سياق غير نشاط ما لم تتجاوز علامة النية
FLAG_ACTIVITY_NEW_TASK.
وإذا حاولت بدء نشاط بدون تجاوز هذه العلامة، لن يبدأ النشاط، وسيطبع النظام رسالة على السجلّ.
تغييرات تدوير الشاشة
بدايةً من نظام التشغيل Android 9، ستطرأ تغييرات كبيرة على وضع التدوير العمودي. في نظام التشغيل Android 8.0 (مستوى واجهة برمجة التطبيقات 26)، كان بإمكان المستخدمين التبديل بين وضعَي التدوير التلقائي والعمودي باستخدام مربّع الإعدادات السريعة أو إعدادات العرض. تمت إعادة تسمية الوضع العمودي باسم قفل التدوير وأصبح مفعَّلاً عند إيقاف التدوير التلقائي. ولم تطرأ أيّ تغييرات على وضع التدوير التلقائي.
عندما يكون الجهاز في وضع قفل التدوير، يمكن للمستخدمين قفل شاشاتهم بإجراء أي تدوير يتيحه النشاط الظاهر في الأعلى والظاهر. لا ينبغي أن يفترض النشاط أنه
سيتم عرضه دائمًا في الوضع العمودي. إذا كان من الممكن عرض أهم الأنشطة في عدة عمليات تدوير في وضع التدوير التلقائي، ينبغي أن تتوفر الخيارات نفسها في
وضع التدوير المُقفَل، مع بعض الاستثناءات استنادًا إلى إعداد
screenOrientation للنشاط (راجع الجدول أدناه).
إنّ الأنشطة التي تطلب اتجاهًا محددًا (على سبيل المثال،
screenOrientation=landscape) تتجاهل الإعدادات المفضّلة لقفل المستخدم وتتصرف
بالطريقة نفسها التي في Android 8.0.
يمكن ضبط الإعداد المفضّل لاتجاه الشاشة على مستوى النشاط في بيان Android، أو بشكل آلي باستخدام setrequestOrientation().
يعمل وضع قفل التدوير من خلال ضبط تفضيل تدوير المستخدم والذي يستخدمه مدير النوافذ عند التعامل مع تدوير الأنشطة. قد يتم تغيير تفضيل تدوير المستخدم في الحالات التالية. لاحظ أن هناك انحيازًا للعودة إلى التدوير الطبيعي للجهاز، والذي يكون عادةً عموديًا للأجهزة التي تحتوي على شكل الهاتف:
- عندما يقبل المستخدم اقتراح التناوب، يتم تغيير الإعدادات المفضّلة لميزة التناوب إلى الاقتراح.
- عندما يبدِّل المستخدم إلى تطبيق يتم فرض وضع عمودي عليه (بما في ذلك شاشة القفل أو مشغّل التطبيقات)، يتغير خيار التدوير إلى الوضع العمودي.
يلخص الجدول التالي سلوك التدوير لاتجاهات الشاشة الشائعة:
| اتجاه الشاشة | السُلوك |
|---|---|
| غير محدد، مستخدم | في قفل التدوير والتدوير التلقائي، يمكن عرض النشاط في الوضع العمودي أو الأفقي (والعكس). توقَّع دعم كل من التنسيقات العمودية والأفقية. |
| مشهد مستخدم | في قفل التدوير والتدوير التلقائي، يمكن عرض النشاط في الوضع الأفقي أو العكسي. توقَّع إتاحة التنسيقات الأفقية فقط. |
| صورة المستخدم | في قفل التدوير والتدوير التلقائي، يمكن عرض النشاط في الوضع العمودي أو العكسي. توقَّع إتاحة التنسيقات العمودية فقط. |
| مستخدم كامل | في قفل التدوير والتدوير التلقائي، يمكن عرض النشاط في الوضع العمودي أو الأفقي (والعكس). يمكنك توقّع التوافق مع كل من التنسيقات العمودية والأفقية. سيتم منح مستخدمي ميزة "قفل التدوير" خيار قفل الشاشة بعكس الاتجاه العمودي، غالبًا 180 درجة. |
| أداة استشعار،FULLSensor، استشعار صورة بورتريه، مستشعر أفقي | يتم تجاهل الإعدادات المفضّلة لوضع قفل التدوير ويتم التعامل معه كما لو كان التدوير التلقائي نشطًا. لا تستخدم هذا إلا في ظروف استثنائية مع دراسة متأنية لتجربة المستخدم. |
يؤثر إيقاف عميل Apache HTTP في التطبيقات التي تحتوي على أداة ClassLoader غير العادية
في الإصدار Android 6.0،
أزلنا الدعم من برنامج Apache HTTP.
لا يؤثر هذا التغيير في الغالبية العظمى من التطبيقات التي لا تستهدف
الإصدار 9 من Android أو الإصدارات الأحدث. ومع ذلك، يمكن أن يؤثر هذا التغيير في تطبيقات معيّنة
تستخدم بنية ClassLoader غير عادية،
حتى إذا كانت التطبيقات لا تستهدف الإصدار 9 من Android أو الإصدارات الأحدث.
يمكن أن يتأثر التطبيق إذا كان يستخدم ClassLoader غير عادي والتي يتم تفويضها بشكل صريح إلى النظام ClassLoader. يجب أن تمنح هذه التطبيقات تفويضًا للوصول إلى التطبيق
ClassLoader بدلاً من ذلك عند البحث عن صفوف في org.apache.http.*. في حال تفويض ClassLoader إلى النظام، سيتعذّر تشغيل التطبيقات على الإصدار 9 من Android أو الإصدارات الأحدث
مع NoClassDefFoundError،
لأن هذه الفئات لم تعُد معروفة للنظام ClassLoader. لمنع حدوث مشاكل مماثلة في المستقبل، يجب أن تعمل التطبيقات في تحميل الفئات بشكل عام
من خلال التطبيق ClassLoader بدلاً من الوصول إلى النظام ClassLoader
مباشرةً.
تعداد الكاميرات
يمكن للتطبيقات التي تعمل على أجهزة Android 9 اكتشاف كل كاميرا متاحة من خلال الاتصال بالرمز getCameraIdList().
ويجب ألا يفترض التطبيق أن الجهاز يحتوي على كاميرا خلفية واحدة فقط أو كاميرا أمامية واحدة فقط.
على سبيل المثال، إذا كان تطبيقك يحتوي على زر للتبديل بين الكاميرا الأمامية والخلفية، فقد يكون هناك أكثر من كاميرا أمامية أو خلفية واحدة للاختيار من بينها. ويجب التنقل في قائمة الكاميرات، وفحص خصائص كل كاميرا، وتحديد الكاميرات التي يجب عرضها للمستخدم.