يقدّم Android 9 (المستوى 28 من واجهة برمجة التطبيقات) عددًا من التغييرات على نظام Android. تسري تغييرات السلوك التالية على جميع التطبيقات عند تشغيلها على نظام Android 9 الأساسي، بغض النظر عن مستوى واجهة برمجة التطبيقات الذي تستهدفه. ويجب على جميع المطوّرين مراجعة هذه التغييرات وتعديل تطبيقاتهم لدعمها بشكل صحيح، حيثما ينطبق ذلك على التطبيق.
لمعرفة التغييرات التي تؤثر فقط في التطبيقات التي تستهدف المستوى 28 أو أعلى لواجهة برمجة التطبيقات، يمكنك الاطّلاع على تغييرات السلوك: التطبيقات التي تستهدف المستوى 28 من واجهة برمجة التطبيقات أو المستويات الأعلى.
إدارة الطاقة
يقدّم Android 9 ميزات جديدة لتحسين إدارة الطاقة على الأجهزة. تساعد هذه التغييرات بالإضافة إلى الميزات التي كانت متوفّرة قبل Android 9 في ضمان توفير موارد النظام للتطبيقات التي تكون في أمس الحاجة إليها.
للحصول على التفاصيل، يُرجى الاطّلاع على إدارة التشغيل.
تغييرات الخصوصية
لتحسين خصوصية المستخدم، يُدخل نظام التشغيل Android 9 تغييرات متعددة في السلوك، مثل تقييد وصول التطبيقات التي تعمل في الخلفية إلى أدوات الاستشعار في الأجهزة، وتقييد المعلومات التي يتم استردادها من عمليات البحث عن شبكات Wi-Fi، وقواعد الأذونات الجديدة ومجموعات الأذونات المتعلقة بالمكالمات الهاتفية وحالة الهاتف وعمليات البحث عن شبكات Wi-Fi.
تؤثّر هذه التغييرات في جميع التطبيقات التي تعمل بنظام التشغيل Android 9، بغض النظر عن إصدار حزمة تطوير البرامج (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
في نظام التشغيل Android 9، تكون متطلبات الأذونات التي يتطلبها التطبيق لإجراء عمليات البحث عن شبكات Wi-Fi أكثر صرامة مقارنةً بالإصدارات السابقة. لمعرفة التفاصيل، يمكنك الاطّلاع على قيود البحث عن شبكات Wi-Fi.
تنطبق قيود مماثلة أيضًا على الطريقة
getConnectionInfo()
التي تعرض عنصرًا WifiInfo
يصف اتصال Wi-Fi الحالي. لا يمكنك استخدام طرق هذا العنصر
لاسترداد قيم SSID ومعرّف مجموعة الخدمات الأساسية (BSSID) إلا إذا كان تطبيق الاتصال لديه الأذونات
التالية:
- 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، لن تعرض الطرق التالية نتائج:
قيود استخدام الواجهات غير المتوفرة في حزمة تطوير البرامج (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 العديد من التغييرات على تنفيذ خوارزميات التشفير والتعامل معها.
عمليات تنفيذ Conscrypt للمعلمات والخوارزميات
يوفّر Android 9 عمليات تنفيذ إضافية لمَعلمات الخوارزمية في Conscrypt. تتضمن هذه المعلَمات: AES وDESEDE وOAEP وEC. تم إيقاف إصدارات Bounty Castle لهذه المعلَمات والعديد من الخوارزميات بدءًا من نظام Android 9.
إذا كان تطبيقك يستهدف الإصدار Android 8.1 (المستوى 27 من واجهة برمجة التطبيقات) أو الإصدارات الأقدم، ستتلقّى تحذيرًا
عند طلب تطبيق Boungy Castle إحدى هذه الخوارزميات المتوقّفة نهائيًا. ولكن إذا كنت تستهدف الإصدار 9 من نظام التشغيل Android، ستظهر علامة
NoSuchAlgorithmException في كل من هذه الطلبات.
تغييرات أخرى
يقدّم Android 9 العديد من التغييرات الأخرى المتعلّقة بالتشفير:
- عند استخدام مفاتيح PBE، إذا كان تطبيق Boungy Castle تتوقّع متّجه تهيئة (IV) ولم يرسل تطبيقك متّجهًا، ستتلقّى تحذيرًا.
- يسمح لك تنفيذ Conscrypt لشفرة ARC4 بتحديد ARC4/ECB/NoPadding أو ARC4/NONE/NoPadding.
- تمت إزالة موفّر بنية تشفير Java (JCA). ونتيجةً لذلك، إذا استدعى تطبيقك
SecureRandom.getInstance("SHA1PRNG", "Crypto")، سيحدث خطأNoSuchProviderException. - إذا كان تطبيقك يحلّل مفاتيح RSA من مخازن مؤقتة أكبر من بنية المفتاح، لن يظهر استثناء بعد ذلك.
لمعرفة المزيد من المعلومات حول استخدام إمكانات التشفير في Android، يمكنك الاطّلاع على التشفير.
الملفات المشفّرة الآمنة على أجهزة Android لم تعُد متوافقة.
يزيل الإصدار 9 من نظام Android بشكل نهائي إمكانية استخدام الملفات المشفَّرة بشكل آمن على نظام التشغيل Android (ASECs).
في نظام التشغيل Android 2.2 (المستوى 8 لواجهة برمجة التطبيقات)، قدّم نظام التشغيل Android أداة ASEC لدعم وظائف التطبيقات على بطاقة 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 العديد من التغييرات البسيطة والمفيدة، بما في ذلك إتاحة بيانات الرموز التعبيرية 5.0 والتنسيقات المحسَّنة للتاريخ/الوقت، كما هو موثَّق في ملاحظات الإصدار 59 وICU 60.
في ما يلي التغييرات البارزة:
- لقد تم تغيير طريقة معالجة النظام الأساسي للمناطق الزمنية.
- تتعامل المنصّة مع توقيتَي غرينيتش والتوقيت العالمي المنسَّق (UTC) بشكل أفضل، إذ لم يعُد التوقيت العالمي المنسّق مرادفًا لتوقيت غرينتش.
يوفر ICU الآن أسماء مناطق مترجمة لتوقيت غرينتش والتوقيت العالمي المنسق. يؤثّر هذا التغيير في تنسيق وتحليل
android.icuلمناطق، مثل "توقيت غرينيتش" و"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، يتضمّن كلّ من التوقيت العالمي المنسَّق (UTC) وتوقيت غرينيتش أسماء طويلة الآن. تصبح صيغ التوقيت الصيفي لأسماء المناطق الزمنية في التوقيت العالمي المنسَّق (UTC)، مثل "التوقيت العالمي المُنسّق" (UTC) و"Etc/UTC" و "Zulu" ، GMT+00:00، وهي الصيغة الاحتياطية العادية في حال عدم توفّر أسماء، بدلاً من السلسلة غير القابلة للتغيير في البرنامجUTC. - يتم التعرّف على بعض معرّفات المناطق بشكل صحيح كمرادفات للمناطق الأخرى، ما يتيح لنظام Android العثور على سلاسل لأرقام تعريف المناطق القديمة، مثل
Eire، والتي تعذّر حلّها سابقًا.
- كما هي الحال في
- لم تعُد آسيا/هانوي منطقة معروفة. لهذا السبب، لا تعرض دالة
java.util.TimeZones.getAvailableIds()هذه القيمة ولا يتعرّف عليهاjava.util.TimeZone.getTimeZone(). وهذا السلوك متوافق مع سلوكandroid.icuالحالي.
- تتعامل المنصّة مع توقيتَي غرينيتش والتوقيت العالمي المنسَّق (UTC) بشكل أفضل، إذ لم يعُد التوقيت العالمي المنسّق مرادفًا لتوقيت غرينتش.
- وقد تعرض طريقة
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 معايير 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 هي أداة تطوير تساعد المطوّرين في اكتشاف المشاكل في الرموز البرمجية.
في نظام التشغيل Android 9 والإصدارات الأحدث، يرصد StrictMode انتهاكات الشبكة
الناجمة عن عمليات البحث عن عنوان الشبكة التي تتطلب تحليل الاسم.
يجب عدم شحن تطبيقاتك التي تكون فيها ميزة StrictMode مفعَّلة. وفي حال إجراء ذلك، قد تواجه تطبيقاتك استثناءات، مثل NetworkOnMainThreadException، عند استخدام طريقتَي
detectNetwork() أو
detectAll() للحصول على سياسة ترصد انتهاكات الشبكة.
لا يعتبر حل عنوان IP الرقمي عملية حظر. تعمل درجة دقة عنوان IP الرقمي كما هي الحال في الإصدارات السابقة لنظام التشغيل Android 9.
وضع علامات للمقابس
في إصدارات النظام الأساسي الأقدم من 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 إلى تحديد ما إذا كانت الشبكات الأساسية
خاضعة للقياس أم لا.
في نظام التشغيل Android 9 والإصدارات الأحدث، عندما تستدعي شبكة VPN الطريقة
setUnderlyingNetworks()، يدمج نظام Android وسائل النقل والإمكانات الخاصة بأي
شبكات أساسية، ويعرض النتيجة على أنّها إمكانات الشبكة الفعّالة
من شبكة VPN.
في نظام التشغيل 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 9، ستطرأ تغييرات كبيرة على وضع التدوير العمودي. في نظام التشغيل Android 8.0 (المستوى 26 من واجهة برمجة التطبيقات)، يمكن للمستخدمين التبديل بين وضعَي التدوير التلقائي والعمودي باستخدام مربّع Quicksettings أو إعدادات العرض. تمت إعادة تسمية الوضع الرأسي قفل التدوير وأصبح نشطًا عند إيقاف التدوير التلقائي. لم يتم إجراء أي تغييرات على وضع التدوير التلقائي.
عندما يكون الجهاز في وضع القفل للتدوير، يمكن للمستخدمين قفل شاشتهم بأي تدوير يدعمه النشاط المرئي في الجزء العلوي. لا ينبغي أن يفترض النشاط أنه
سيتم عرضه دائمًا في عمودي. وإذا كان من الممكن عرض "النشاط الأهم" بعدة تدويرات في
وضع التدوير التلقائي، يجب إتاحة الخيارات نفسها في
وضع قفل التدوير، مع بعض الاستثناءات استنادًا إلى إعداد
screenOrientation "النشاط" (اطّلِع على الجدول أدناه).
تتجاهل الأنشطة التي تطلب اتجاهًا محددًا (على سبيل المثال،
screenOrientation=landscape) الإعدادات المفضّلة لقفل المستخدم، وتتصرف
بنفس الطريقة التي يتّبعها نظام التشغيل Android 8.0.
يمكن ضبط الإعداد المفضّل لاتجاه الشاشة على مستوى النشاط في بيان Android، أو آليًا باستخدام setRequestOrientation().
يعمل وضع قفل التدوير من خلال ضبط تفضيل تدوير المستخدم الذي يستخدمه WindowManager عند التعامل مع "تدوير النشاط". يمكن أن يتم تغيير تفضيل عرض المستخدمين بالتناوب في الحالات التالية. لاحظ أن هناك تحيزًا للرجوع إلى الدوران الطبيعي للجهاز، والذي يكون عادةً في الوضع العمودي للأجهزة التي تحتوي على شكل الهاتف:
- عندما يقبل المستخدم اقتراحًا بالتناوب، يتم تغيير الإعدادات المفضّلة للتناوب إلى هذا الاقتراح.
- عندما ينتقل المستخدم إلى تطبيق وضع عمودي مفروض (بما في ذلك شاشة القفل أو مشغّل التطبيقات)، يتم تغيير تفضيل التدوير إلى الوضع العمودي.
يلخص الجدول التالي سلوك الدوران لاتجاهات الشاشة الشائعة:
| اتجاه الشاشة | السُلوك |
|---|---|
| غير محدد، مستخدم | عند استخدام التدوير التلقائي وقفل التدوير، يمكن عرض النشاط في الوضع العمودي أو الأفقي (والعكس). توقع دعم كل من التخطيطات العمودية والأفقية. |
| مستخدم أفقي | عند استخدام التدوير التلقائي وقفل التدوير، يمكن عرض النشاط إما بالوضع الأفقي أو العكسي. توقَّع دعم التخطيطات الأفقية فقط. |
| صورة المستخدم | في حال قفل التدوير التلقائي والتدوير، يمكن عرض النشاط إما في الوضع العمودي أو العمودي العكسي. يجب أن يتم دعم التنسيقات العمودية فقط. |
| مستخدم كامل | عند استخدام التدوير التلقائي وقفل التدوير، يمكن عرض النشاط في الوضع العمودي أو الأفقي (والعكس). ومن المتوقّع أن تتوافق مع كل من التنسيقات العمودية والأفقية. سيتوفّر لمستخدمي قفل التدوير خيار القفل بعكس الوضع العمودي، غالبًا بزاوية 180 درجة. |
| أداة استشعار، مستشعر كامل، أداة استشعار عمودي، أداة استشعار أفقي | ويتم تجاهل الإعدادات المفضّلة لوضع قفل التدوير، ويتم التعامل معه كما لو كان التدوير التلقائي نشطًا. لا تستخدم هذا إلا في الظروف الاستثنائية مع مراعاة تجربة المستخدم بعناية. |
يؤثر إيقاف عميل 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().
وينبغي ألا يفترض التطبيق أن الجهاز يحتوي على إلا كاميرا خلفية واحدة أو كاميرا أمامية واحدة فقط.
على سبيل المثال، إذا كان تطبيقك يتضمّن زرًّا للتبديل بين الكاميرا الأمامية والكاميرا الخلفية، قد يتوفّر لك أكثر من كاميرا أمامية أو خلفية واحدة للاختيار من بينها. ويجب عليك التعرّف على قائمة الكاميرات وفحص خصائص كل كاميرا وتحديد الكاميرات التي يتم عرضها للمستخدم.