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

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

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

إدارة الطاقة

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

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

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

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

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

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

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

لقراءة أرقام الهواتف من حالة الهاتف، عليك تحديث تطبيقك لطلب التصاريح اللازمة استنادًا إلى حالة الاستخدام:

الوصول المحدود إلى معلومات الموقع الجغرافي وبيانات الاتصال بشبكة Wi-Fi

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

تنطبق أيضًا قيود مشابهة على الأسلوب getConnectionInfo() الذي يعرض عنصر WifiInfo يصف الاتصال الحالي بشبكة Wi-Fi. لا يمكنك استخدام methods (الإجراءات) الخاصة بهذا العنصر إلا لاسترداد قيم SSID وBSSID إذا كان التطبيق المُرسِل يملك الأذونات التالية:

  • ACCESS_FINE_LOCATION أو ACCESS_COARSE_LOCATION
  • ACCESS_WIFI_STATE

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

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

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

لم يعُد بث النظام 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. تم إيقاف إصدارات Bouncy Castle من هذه المَعلمات والعديد من الخوارزميات نهائيًا اعتبارًا من Android 9.

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

تغييرات أخرى

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

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

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

لم تعُد الملفات المشفّرة الآمنة على Android متاحة

يزيل نظام التشغيل Android 9 إمكانية استخدام الملفات المشفَّرة بأمان (ASEC) على Android نهائيًا.

في الإصدار 2.2 من Android (المستوى 8 لواجهة برمجة التطبيقات)، قدّم Android شهادات ASEC لتفعيل وظائف التثبيت على بطاقة SD. في الإصدار 6.0 من نظام التشغيل Android (المستوى 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 وتحليله للمناطق مثل "التوقيت العالمي المنسَّق" و"Etc/التوقيت العالمي المنسَّق" و"التوقيت العالمي المنسَّق" و"Etc/التوقيت العالمي المنسَّق" و "Zulu".

    • يستخدم java.text.SimpleDateFormat الآن ICU لتوفير أسماء معروضة للتوقيت العالمي المنسق (UTC) أو التوقيت العالمي (GMT)، ويعني ذلك ما يلي:
      • يؤدي تنسيق zzzz إلى إنشاء سلسلة طويلة مترجَمة لعدة لغات. في السابق، كان يتم عرض "التوقيت العالمي المنسق" للتوقيت العالمي المنسق وسلاسل مثل "التوقيت العالمي المنسق+00:00" للتوقيت العالمي المنسق.
      • عند تحليل zzzz، يتم التعرّف على سلاسل مثل "التوقيت العميق التنسيقي" و "توقيت غرينتش".
      • قد تواجه التطبيقات مشاكل في التوافق إذا كانت تفترض أنّه يتم عرض "التوقيت العالمي المنسَّق" أو "التوقيت العالمي المنسَّق+00:00" لأجل zzzz بجميع اللغات.
    • تغيّر سلوك java.text.DateFormatSymbols.getZoneStrings():
      • كما هو الحال مع SimpleDateFormat، أصبح للتوقيت العالمي المنسق وتوقيت غرينتش الآن اسمان طويلان. تصبح صيغ التوقيت الصيفي لأسماء المناطق الزمنية لمنطقة التوقيت العالمي المنسق (UTC)، مثل "التوقيت العالمي المنسق" و"Etc/التوقيت العالمي المنسق" و "زولو"، هي توقيت غرينيتش +00:00، وهو البديل العادي عندما لا تتوفّر أسماء، بدلاً من السلسلة الثابتة UTC.
      • يتم التعرّف بشكل صحيح على بعض أرقام تعريف المناطق على أنّها مرادفات لمناطق أخرى، حتى يعثر Android على سلاسل أرقام تعريف مناطق قديمة، مثل Eire، والتي لم يكن بالإمكان تحديد هويتها في السابق.
    • لم تعُد المنطقة Asia/Hanoi معتمَدة. لهذا السبب، لا تعرض 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 وبنية الفئات. تساعد هذه التغييرات المطوّرين في استخدام واجهات برمجة التطبيقات المتاحة للجميع والمتوافقة مع إطار العمل، كما توفّر التغييرات أيضًا المزيد من المرونة في إنشاء الاختبار وإجرائه باستخدام مكتبات تابعة لجهات خارجية أو منطق مخصّص.

المكتبات التي تمّت إزالتها من إطار العمل

يعيد نظام التشغيل Android 9 تنظيم الفئات المستندة إلى JUnit في ثلاث مكتبات: android.test.base وandroid.test.runner وandroid.test.mock. يتيح لك هذا التغيير إجراء اختبارات على إصدار JUnit الذي يعمل بشكل أفضل مع تبعيات مشروعك. قد يختلف هذا الإصدار من JUnit عن الإصدار الذي يوفّره android.jar.

لمعرفة مزيد من المعلومات عن كيفية تنظيم الفصول المستندة إلى JUnit في مكتبات الاختبار هذه، بالإضافة إلى كيفية إعداد مشروع تطبيقك لكتابة الاختبارات وتنفيذها، اطّلِع على مقالة إعداد مشروع لاختبار Android.

تغييرات في إصدار مجموعة الاختبار

تمّت إزالة الطريقة 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() أو أسلوب NewStringUTF() JNI.

إثبات ملكية اسم المضيف باستخدام شهادة

يصف معيار 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 والإصدارات الأحدث، يتم الاحتفاظ بعلامة المقبس عند إرسالها إلى عملية أخرى باستخدام واجهة برمجة التطبيقات binder IPC. يمكن أن يؤثر هذا التغيير في إحصاءات عدد زيارات الشبكة، مثلاً عند استخدام queryDetailsForUidTag().

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

الكمية المسجّلة من وحدات البايت المتاحة في المقبس

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

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

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

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

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

لم تعُد الملفات في مجلد xt_qtaguid متاحة للتطبيقات

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

تستمر واجهات برمجة التطبيقات المتاحة للجميع التي تعتمد على هذين الملفَّين، TrafficStats و NetworkStatsManager، في العمل على النحو المطلوب. ومع ذلك، قد لا تعمل وظائف cutils غير المتوافقة، مثل qtaguid_tagSocket()، على النحو المتوقّع أو قد لا تعمل على الإطلاق على أجهزة مختلفة.

تم الآن فرض شرط FLAG_ACTIVITY_NEW_TASK

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

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

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

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

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

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

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

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

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

اتجاه الشاشة السُلوك
غير محدّد، مستخدِم في وضع "التدوير التلقائي" و"قفل التدوير"، يمكن عرض "النشاط" في الوضع العمودي أو الأفقي (والعكس). من المتوقّع أن تتيح تنسيقات الوضعَين العمودي والأفقي.
userLandscape في وضعَي "التدوير التلقائي" و"قفل التدوير"، يمكن عرض "النشاط" إما في الوضع الأفقي أو الوضع الأفقي العكسي. من المتوقّع أن تتوفّر التنسيقات الأفقية فقط.
userPortrait في وضعَي "التدوير التلقائي" و"قفل التدوير"، يمكن عرض "النشاط" إما بالوضع العمودي أو بالوضع العمودي العكسي. من المتوقّع أن تتوفّر التنسيقات العمودية فقط.
fullUser في وضع "التدوير التلقائي" و"قفل التدوير"، يمكن عرض "النشاط" في الوضع العمودي أو الأفقي (والعكس). من المفترض أن تتيح هذه التطبيقات تنسيقَي الوضع العمودي والأفقي.

سيحصل مستخدمو ميزة "قفل التدوير" على خيار قفل الوضع العمودي العكسي، غالبًا بزاوية 180 درجة.
sensor, fullSensor, sensorPortrait, sensorLandscape يتم تجاهل الإعداد المفضّل لوضع قفل دوران الشاشة ويتم التعامل معه كما لو كان وضع "التدوير التلقائي" مفعّلاً. لا تستخدِم هذا الإجراء إلا في حالات استثنائية مع مراعاة تجربة المستخدم بعناية فائقة.

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

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

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

إدراج الكاميرات

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

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