تغييرات السلوك: جميع التطبيقات

يقدّم الإصدار Android 9 (المستوى 28 من واجهة برمجة التطبيقات) عددًا من التغييرات في نظام Android. تسري تغييرات السلوك التالية على جميع التطبيقات عند تشغيلها على نظام Android 9 الأساسي، بغض النظر عن مستوى واجهة برمجة التطبيقات الذي تستهدفه. ويجب على جميع المطورين مراجعة هذه التغييرات وتعديل تطبيقاتهم لدعمها بشكل صحيح، حيثما ينطبق ذلك على التطبيق.

لمعرفة التغييرات التي لا تؤثر إلا في التطبيقات التي تستهدف المستوى 28 من واجهة برمجة التطبيقات أو مستوى أعلى، يُرجى الاطّلاع على التغييرات في السلوك: التطبيقات التي تستهدف المستوى 28 من واجهة برمجة التطبيقات أو مستوى أعلى.

إدارة الطاقة

يقدّم نظام التشغيل Android 9 ميزات جديدة لتحسين إدارة طاقة الجهاز. وهذه التغييرات بالإضافة إلى الميزات التي كانت متوفّرة قبل Android 9 تساعد في ضمان توفير موارد النظام للتطبيقات التي تكون في أمس الحاجة إليها.

لمعرفة التفاصيل، يُرجى الاطّلاع على إدارة التشغيل.

تغييرات الخصوصية

لتحسين خصوصية المستخدمين، يدخل الإصدار 9 من نظام التشغيل Android العديد من التغييرات في السلوك، مثل الحدّ من وصول التطبيقات التي تعمل في الخلفية إلى أجهزة استشعار الجهاز، وحظر المعلومات التي يتم استردادها من عمليات البحث عن شبكات Wi-Fi، وقواعد الأذونات الجديدة ومجموعات الأذونات المتعلقة بالمكالمات الهاتفية وحالة الهاتف وعمليات البحث عن شبكات Wi-Fi.

تؤثر هذه التغييرات في جميع التطبيقات التي تعمل بنظام التشغيل Android 9، بغض النظر عن إصدار حزمة تطوير البرامج (SDK) المستهدَف.

وصول محدود إلى أجهزة الاستشعار في الخلفية

يحد نظام التشغيل Android 9 من قدرة تطبيقات الخلفية على الوصول إلى إدخال المستخدم وبيانات جهاز الاستشعار. إذا كان تطبيقك يعمل في الخلفية على جهاز يعمل بنظام التشغيل Android 9، سيطبّق النظام القيود التالية على تطبيقك:

• لا يمكن لتطبيقك الوصول إلى الميكروفون أو الكاميرا.
• لا تتلقّى أجهزة الاستشعار التي تستخدم وضع إعداد التقارير المستمر، مثل مقاييس التسارع والجيروسكوب.
• لا تتلقّى أدوات الاستشعار التي تستخدم وضعَي on-change أو one-لقطة التقارير الأحداث.

إذا كان تطبيقك يحتاج إلى رصد أحداث أجهزة الاستشعار على الأجهزة التي تعمل بنظام التشغيل 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 ومعرّف مجموعة الخدمات الأساسية إلا إذا كان لتطبيق الاتصال الأذونات التالية:

• ACCESS_FINE_LOCATION أو ACCESS_COARSE_LOCATION
• حالة ACCESS_WIFI_STATE

يتطلب استرداد SSID أو معرّف مجموعة الخدمات الأساسية (BSSID) أيضًا تفعيل خدمات الموقع الجغرافي على الجهاز (ضمن الإعدادات > الموقع الجغرافي).

المعلومات التي تتم إزالتها من طرق خدمة Wi-Fi

في نظام التشغيل Android 9، لا تتلقّى الأحداث وعمليات البث التالية معلومات عن الموقع الجغرافي للمستخدم أو بيانات تحديد الهوية الشخصية:

• الطريقتان 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() بدلاً من ذلك.

تعتمد معلومات الاتصال الهاتفي الآن على إعداد الموقع الجغرافي للجهاز

إذا كان المستخدم قد أوقف خدمة الموقع الجغرافي على الجهاز على جهاز يعمل بنظام التشغيل Android 9، لن يتم عرض نتائج من خلال الطرق التالية:

• getAllCellInfo()
• listen()
• getCellLocation()
• getNeighboringCellInfo()

قيود استخدام الواجهات التي لا تتضمن حزمة SDK

للمساعدة في ضمان استقرار التطبيق وتوافقه، يحظر النظام الأساسي استخدام بعض الطرق والحقول التي لا تستند إلى حزمة SDK، وتنطبق هذه القيود سواء كنت تحاول الوصول إلى هذه الطرق والحقول مباشرةً، من خلال الانعكاس أو باستخدام JNI. في نظام Android 9، يمكن لتطبيقك الاستمرار في الوصول إلى هذه الواجهات المحظورة، ويستخدم النظام الأساسي نخب ومداخل السجل لجذب انتباهك. إذا كان تطبيقك يُظهر هذه التغطية، من المهم اتّباع استراتيجية تنفيذ أخرى غير الواجهة المحظورة. إذا كنت تعتقد أنّه لا يمكن تطبيق استراتيجية بديلة، يمكنك الإبلاغ عن خطأ لطلب إعادة النظر في الحظر.

تتضمن القيود المفروضة على الواجهات غير المستندة إلى حزمة تطوير البرامج (SDK) المزيد من المعلومات المهمة. يجب عليك مراجعته لضمان استمرار عمل تطبيقك بشكل صحيح.

التغييرات في سلوك الأمان

تغييرات أمان الجهاز

يضيف Android 9 إمكانات عديدة لتحسين مستوى أمان تطبيقك، بغض النظر عن الإصدار الذي يستهدفه التطبيق.

تغييرات تنفيذ بروتوكول أمان طبقة النقل (TLS)

خضع تنفيذ بروتوكول أمان طبقة النقل (TLS) للنظام للعديد من التغييرات في الإصدار 9 من Android:

• إذا تعذّر الاتصال بالمثيل 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. تم إيقاف إصدارات Buncy Castle لهذه المَعلمات والعديد من الخوارزميات بدءًا من نظام التشغيل Android 9.

ملاحظة: لا يتوافق تنفيذ Conscrypt لمَعلمة EC إلا مع المنحنيات المُسمّاة.

إذا كان تطبيقك يستهدف الإصدار Android 8.1 (المستوى 27 لواجهة برمجة التطبيقات) أو إصدارًا أقدم، ستتلقّى تحذيرًا عند طلب تنفيذ Bouncy Castle إحدى هذه الخوارزميات المتوقّفة نهائيًا. ومع ذلك، إذا كنت تستهدف الإصدار 9 من نظام التشغيل Android، سيؤدي كل من هذه الطلبات إلى عرض علامة NoSuchAlgorithmException.

تغييرات أخرى

يقدّم Android 9 العديد من التغييرات الأخرى المتعلّقة بالتشفير:

• عند استخدام مفاتيح PBE، وإذا كانت لعبة Bouncy Castle تتوقعها (IV) وأن يكون متجه الإعداد (IV) بدون حدوث أي استجابة، سيصلك تحذير.
• يسمح لك تنفيذ Conscrypt لشفرة ARC4 بتحديد إما ARC4/ECB/NoPadding أو ARC4/NONE/NoPadding.
• تمت إزالة موفّر بنية تشفير جافا (JCA). ونتيجة لذلك، إذا استدعى تطبيقك الرقم SecureRandom.getInstance("SHA1PRNG", "Crypto")، سيحدث خطأ NoSuchProviderException.
• وإذا كان تطبيقك يحلّل مفاتيح RSA من المخازن المؤقتة التي تكون أكبر من بنية المفتاح، لن يحدث استثناء بعد ذلك.

لمعرفة المزيد من المعلومات حول استخدام إمكانات التشفير في Android، يمكنك الاطّلاع على التشفير.

الملفات المشفّرة الآمنة في أجهزة Android لم تعُد متوافقة.

يزيل نظام التشغيل Android 9 تمامًا دعم ملفات Android المشفَّرة بشكل آمن (ASECs).

في نظام التشغيل Android 2.2 (المستوى 8 من واجهة برمجة التطبيقات)، قدّم Android معيار ASEC لدعم وظائف التطبيقات على بطاقة SD. في نظام التشغيل Android 6.0 (المستوى 23 من واجهة برمجة التطبيقات)، قدم النظام الأساسي جهاز تخزين قابل للاعتماد يمكن للمطوّرين استخدامه بدلاً من ASECs.

تعديلات على مكتبات ICU

يستخدم الإصدار 9 من Android الإصدار 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.

هناك تغييرات ملحوظة في هذا التعديل:

• تم تغيير طريقة تعامل النظام الأساسي مع المناطق الزمنية.
  • تتعامل المنصة مع توقيتَي GMT وUTC بشكل أفضل، ولم تعُد التوقيت العالمي المتفق عليه مرادفًا لتوقيت غرينتش.

    توفر وحدة 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" و"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، المتوفر منذ الإصدار 7.0 من Android (المستوى 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 معايير يونيكود بشكل أكثر صرامة مقارنةً بالإصدارات السابقة. وتشمل التغييرات ما يلي:

• يتم التعامل مع أقصر صيغة UTF-8 من الترميز 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() أو طريقة JNI NewStringUTF().

التحقق من اسم المضيف باستخدام شهادة

يصف RFC 2818 طريقتَين لمطابقة اسم نطاق مع شهادة، وذلك باستخدام الأسماء المتاحة ضمن الامتداد subjectAltName (SAN)، أو في حال عدم توفُّر الامتداد SAN، ويتم الرجوع إلى commonName (CN).

ومع ذلك، تم إيقاف الإجراء الاحتياطي إلى CN نهائيًا في RFC 2818. لهذا السبب، لم يعُد Android يعود إلى استخدام CN. للتحقّق من اسم المضيف، على الخادم تقديم شهادة ذات SAN مطابقة. أمّا الشهادات التي لا تحتوي على SAN يتطابق مع اسم المضيف، لم تعُد موثوقة.

قد تؤدي عمليات البحث عن عنوان الشبكة إلى حدوث انتهاكات في الشبكة

يمكن أن تتضمن عمليات البحث عن عنوان الشبكة التي تتطلب تحليل الاسم إدخال/إخراج الشبكة وبالتالي يتم اعتبارها عمليات حظر. يمكن أن تؤدي عمليات الحظر على سلسلة التعليمات الرئيسية إلى توقف مؤقت أو عطل.

الفئة StrictMode هي أداة تطوير تساعد المطوّرين في اكتشاف المشاكل في الرموز البرمجية.

في نظام التشغيل Android 9 والإصدارات الأحدث، يرصد StrictMode انتهاكات الشبكة الناتجة عن عمليات البحث عن عنوان الشبكة التي تتطلب تحليل الاسم.

يجب عدم شحن تطبيقاتك مع تفعيل StrictMode. وإذا فعلت ذلك، سيتم تطبيق استثناءات على تطبيقاتك، مثل NetworkOnMainThreadException عند استخدام طريقتَي detectNetwork() أو detectAll() للحصول على سياسة ترصد انتهاكات الشبكة.

لا يُعد حل عنوان IP الرقمي عملية حظر. تعمل طريقة دقة عنوان IP الرقمي كما هي الحال في الإصدارات التي تسبق Android 9.

وضع علامات على المقابس

في إصدارات النظام الأساسي الأقدم من Android 9، إذا تم وضع علامة على المقبس باستخدام طريقة setThreadStatsTag()، لن يتم وضع علامة على المقبس عند إرساله إلى عملية أخرى باستخدام بروتوكول IPC مع حاوية ParcelFileDescriptor.

في نظام التشغيل Android 9 والإصدارات الأحدث، يتم الاحتفاظ بعلامة المقبس عند إرسالها إلى عملية أخرى باستخدام IPC للحافظة. قد يؤثر هذا التغيير في إحصاءات حركة بيانات الشبكة، على سبيل المثال، عند استخدام طريقة queryDetailsForUidTag().

إذا كنت تريد الاحتفاظ بسلوك الإصدارات السابقة، التي تزيل علامة المقبس الذي تم إرساله إلى عملية أخرى، يمكنك طلب untagSocket() قبل إرسال المقبس.

مقدار وحدات البايت المتاحة التي تم الإبلاغ عنها في المقبس

تعرض الطريقة available() القيمة 0 عند استدعائها بعد استدعاء طريقة shutdownInput().

إعداد تقارير أكثر تفصيلاً عن إمكانات الشبكة للشبكات الافتراضية الخاصة

في نظام التشغيل Android 8.1 (مستوى واجهة برمجة التطبيقات 27) والإصدارات الأقدم، تم الإبلاغ عن مجموعة محدودة فقط من المعلومات للشبكات الافتراضية الخاصة في الفئة NetworkCapabilities، مثل TRANSPORT_VPN، ولكن سيتم حذف NET_CAPABILITY_NOT_VPN. وهذه المعلومات المحدودة جعلت من الصعب تحديد ما إذا كان استخدام شبكة VPN سيؤدي إلى فرض رسوم على مستخدم التطبيق. على سبيل المثال، لن يؤدي التحقّق من NET_CAPABILITY_NOT_METERED إلى تحديد ما إذا كانت الشبكات الأساسية خاضعة للقياس أم لا.

في نظام التشغيل Android 9 والإصدارات الأحدث، عندما تستدعي الشبكة الافتراضية الخاصة الطريقة setUnderlyingNetworks()، يدمج نظام Android عمليات النقل والإمكانات الخاصة بأي شبكات أساسية، ويعرض النتيجة باعتبارها إمكانيات الشبكة الفعّالة للشبكة الافتراضية الخاصة.

في نظام التشغيل Android 9 والإصدارات الأحدث، تتلقّى التطبيقات التي تبحث عن NET_CAPABILITY_NOT_METERED إمكانات الشبكة الخاصة بشبكة VPN والشبكات الأساسية.

لم تعُد الملفات المتوفّرة في مجلد xt_qtaguid متاحة للتطبيقات بعد الآن.

بدءًا من نظام التشغيل Android 9، لا يُسمَح للتطبيقات بالحصول على إذن وصول مباشر للقراءة إلى الملفات في مجلد /proc/net/xt_qtaguid. والسبب هو ضمان الاتساق مع بعض الأجهزة التي لا تحتوي على هذه الملفات على الإطلاق.

تواصل واجهات برمجة التطبيقات العامة التي تعتمد على هذين الملفين، TrafficStats وNetworkStatsManager، العمل على النحو المنشود. ومع ذلك، قد لا تعمل دوال cutil غير المتوافقة، مثل qtaguid_tagSocket()، كما هو متوقع، أو قد لا تعمل مطلقًا على أجهزة مختلفة.

تم فرض متطلب FLAG_activity_NEW_TASK الآن.

في الإصدار Android 9، لا يمكنك بدء نشاط من سياق غير نشاط ما لم تتجاوز علامة النية FLAG_ACTIVITY_NEW_TASK. إذا حاولت بدء نشاط بدون تمرير هذه العلامة، لن يبدأ النشاط، وسيطبع النظام رسالة على السجل.

ملاحظة: لطالما كان شرط الإبلاغ هو السلوك المقصود، وتم فرضه على الإصدارات الأقدم من Android 7.0 (المستوى 24 من واجهة برمجة التطبيقات). أدى خطأ في Android 7.0 إلى منع فرض شرط الإبلاغ.

تغييرات تدوير الشاشة

بدءًا من نظام التشغيل Android 9، سنُجري تغييرات كبيرة على وضع التدوير العمودي. في نظام التشغيل Android 8.0 (المستوى 26 من واجهة برمجة التطبيقات)، كان بإمكان المستخدمين التبديل بين وضعَي التدوير التلقائي والعمودي باستخدام مربّعات Quicksettings أو إعدادات العرض. تمت إعادة تسمية وضع "بورتريه" ليصبح قفل التدوير وأصبح نشطًا عند إيقاف ميزة التدوير التلقائي، ولم تطرأ أي تغييرات على وضع التدوير التلقائي.

عندما يكون الجهاز في وضع قفل التدوير، يمكن للمستخدمين قفل شاشتهم بأي تدوير متوافق مع قسم "النشاط المرئي" في أعلى الصفحة. لا ينبغي أن يفترض النشاط أنه سيتم عرضه دائمًا بشكل عمودي. إذا كان من الممكن عرض "النشاط العلوي" في عدة تدويرات في وضع التدوير التلقائي، يجب إتاحة الخيارات نفسها في "وضع التدوير المُقفَل"، مع بعض الاستثناءات وذلك استنادًا إلى إعداد screenOrientation للنشاط (اطّلِع على الجدول أدناه).

تتجاهل الأنشطة التي تطلب اتجاهًا محددًا (مثل screenOrientation=landscape) الإعداد المفضَّل لقفل المستخدم وتتصرف بنفس طريقة عمل Android 8.0.

يمكن ضبط الخيار المفضّل لاتجاه الشاشة على مستوى النشاط في بيان Android، أو آليًا باستخدام setRequestOrientation().

يعمل وضع قفل التدوير عن طريق ضبط تفضيل تدوير المستخدمين الذي يستخدمه WindowManager عند التعامل مع دوران الأنشطة. قد يتم تغيير تفضيل دوران المستخدم في الحالات التالية. لاحظ أن هناك انحيازًا في العودة إلى الدوران الطبيعي للجهاز، والذي يكون عادةً عموديًا لأجهزة شكل الهاتف:

• عندما يقبل المستخدم اقتراح التناوب، يتغيّر الخيار المفضّل لعرض الإعلانات بالتناوب.
• عندما يبدِّل المستخدم إلى تطبيق يتم فرض الوضع العمودي فيه (بما في ذلك شاشة القفل أو مشغّل التطبيقات)، يتغير خيار التدوير إلى الوضع العمودي.

يلخص الجدول التالي سلوك التدوير لاتجاهات الشاشة الشائعة:

اتجاه الشاشة	السُلوك
غير محدد، مستخدم	عند قفل التدوير التلقائي والتدوير، يمكن عرض النشاط في الوضع العمودي أو الأفقي (والعكس). يمكنك توقّع دعم كل من التنسيقات العمودية والأفقية.
تصوّر	في وضع التدوير التلقائي وقفل التدوير، يمكن عرض النشاط في الوضع الأفقي أو الأفقي. سيتم توفير التنسيقات الأفقية فقط.
صورة المستخدم	في وضع "قفل التدوير التلقائي" و"قفل التدوير"، يمكن عرض النشاط في الوضع العمودي أو الوضع العمودي العكسي. يمكنك توقُّع دعم التنسيقات العمودية فقط.
مستخدم كامل	عند قفل التدوير التلقائي والتدوير، يمكن عرض النشاط في الوضع العمودي أو الأفقي (والعكس). يمكنك توقُّع توافق كل من التنسيقات العمودية والأفقية. سيتم منح مستخدمي قفل التدوير خيار القفل لعكس الوضع العمودي، وغالبًا ما تكون درجة الحرارة 180 درجة.
أداة استشعار،fullSensor، مستشعر عمودي، مستشعر أفقي	يتم تجاهل تفضيل وضع قفل التدوير، ويتم التعامل معه كما لو كان التدوير التلقائي نشطًا. لا تستخدم هذا إلا في ظروف استثنائية مع دراسة متأنية لتجربة المستخدم.

يؤثر إيقاف عميل Apache HTTP نهائيًا في التطبيقات التي تحتوي على ClassLoader غير عادي

في الإصدار Android 6.0، أزلنا دعم عميل Apache HTTP. لا يؤثر هذا التغيير في الغالبية العظمى من التطبيقات التي لا تستهدف الإصدار 9 من Android أو الإصدارات الأحدث. ومع ذلك، قد يؤثر هذا التغيير في تطبيقات معيّنة تستخدم بنية ClassLoader غير عادية، حتى إذا كانت التطبيقات لا تستهدف الإصدار 9 من نظام التشغيل Android أو الإصدارات الأحدث.

قد يتأثر التطبيق إذا كان يستخدم ClassLoader غير عادي والتي يفوضها النظام ClassLoader بشكل صريح. يجب أن تمنح هذه التطبيقات تفويضًا للوصول إلى التطبيق ClassLoader بدلاً من ذلك عند البحث عن صفوف في org.apache.http.*. في حال تفويض المستخدمين إلى النظام ClassLoader، سيتعذّر تشغيل التطبيقات على نظام التشغيل Android 9 أو الإصدارات الأحدث عند استخدام NoClassDefFoundError، لأن هذه الفئات لم تعُد معروفة للنظام ClassLoader. لمنع حدوث مشاكل مماثلة في المستقبل، يجب أن تحمِّل التطبيقات الفئات بشكل عام من خلال التطبيق ClassLoader بدلاً من الوصول إلى النظام ClassLoader مباشرةً.

تعداد الكاميرات

يمكن للتطبيقات التي تعمل على أجهزة Android 9 اكتشاف جميع الكاميرات المتاحة من خلال الاتصال على الرقم getCameraIdList(). يجب ألا يفترض التطبيق أن الجهاز يحتوي على كاميرا خلفية واحدة فقط أو كاميرا أمامية واحدة فقط.

على سبيل المثال، إذا كان تطبيقك يحتوي على زر للتبديل بين الكاميرا الأمامية والخلفية، يمكن أن يكون هناك أكثر من كاميرا أمامية أو خلفية يمكنك الاختيار من بينها. يجب عليك التنقل في قائمة الكاميرات، وفحص خصائص كل كاميرا، وتحديد الكاميرات التي يجب عرضها للمستخدم.