تغييرات السلوك: التطبيقات التي تستهدف المستوى 29 من واجهة برمجة التطبيقات أو الإصدارات الأحدث

يتضمّن نظام التشغيل Android 10 تغييرات محدّثة في سلوك النظام قد تؤثر في تطبيقك. تنطبق التغييرات المدرَجة في هذه الصفحة حصريًا على التطبيقات التي تستهدِف الإصدار 29 أو إصدار أحدث من واجهة برمجة التطبيقات. إذا كان تطبيقك يضبط targetSdkVersion على "29" أو أكثر، عليك تعديل تطبيقك لتفعيل هذه السلوكيات بشكلٍ سليم، حيثما ينطبق ذلك.

يُرجى أيضًا مراجعة قائمة التغييرات في السلوك التي تؤثر في جميع التطبيقات التي تعمل بنظام التشغيل Android 10.

تعديلات على القيود المفروضة على الواجهات غير المتوفرة في حزمة SDK

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

إذا لم تكن تستهدف Android 10 (المستوى 29 من واجهة برمجة التطبيقات)، قد لا تؤثر بعض هذه التغييرات في تطبيقك بشكل فوري. ومع أنّه يمكنك حاليًا استخدام بعض واجهات غير حزمة SDK (حسب مستوى واجهة برمجة التطبيقات المستهدَف في تطبيقك)، فإنّ استخدام أي طريقة أو حقل غير حزمة SDK ينطوي دائمًا على مخاطر عالية لتعطُّل تطبيقك.

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

لمزيد من المعلومات، اطّلِع على التعديلات على القيود المفروضة على الواجهات غير المتوفّرة في حزمة SDK في Android 10 والقيود المفروضة على الواجهات غير المتوفّرة في حزمة SDK.

الذاكرة المشتركة

غيّر Ashmem تنسيق خرائط Dalvik في ‎ /proc/<pid>/maps، مما أثر في التطبيقات التي تفكّر ملف الخرائط مباشرةً. على مطوّري التطبيقات اختبار تنسيق ‎ /proc/<pid>/maps على الأجهزة التي تعمل بالإصدار Android 10 أو إصدار أحدث وتحليله وفقًا لذلك إذا كان التطبيق يعتمد على تنسيقات ملفّات ‎dalvik map.

لا يمكن للتطبيقات التي تستهدف الإصدار 10 من Android استخدام ashmem (‎/dev/ashmem) مباشرةً، بل يجب أن تصل إلى الذاكرة المشتركة من خلال ASharedMemory class في حزمة NDK. بالإضافة إلى ذلك، لا يمكن للتطبيقات إجراء طلبات IOCTL مباشرةً إلى أوصاف ملفات ashmem الحالية، وبدلاً من ذلك، يجب استخدام فئة ASharedMemory في NDK أو واجهات برمجة التطبيقات Java في Android لإنشاء مناطق ذاكرة مشترَكة. يؤدي هذا التغيير إلى زيادة الأمان والصلابة عند العمل مع الذاكرة المشتركة، ما يؤدي إلى تحسين أداء Android وأمانه بشكل عام.

إزالة إذن التنفيذ للدليل الرئيسي للتطبيق

يُعد تنفيذ الملفات من الدليل الرئيسي للتطبيق القابل للكتابة مخالفة W^X. يجب ألا تحمِّل التطبيقات سوى الرمز الثنائي الذي تم تضمينه في ملف APK للتطبيق.

لا يمكن للتطبيقات غير الموثوق بها التي تستهدف الإصدار 10 من Android استخدام execve() مباشرةً على الملفات ضمن دليل التطبيق الرئيسي.

بالإضافة إلى ذلك، لا يمكن للتطبيقات التي تستهدف الإصدار 10 من Android تعديل الرمز البرمجي القابل للتنفيذ من الملفات التي تم فتحها باستخدام dlopen() في الذاكرة، ولا يمكنها التوقع أن يتم كتابة هذه التغييرات على القرص، لأنّه لا يمكن أن تتم ربط المكتبة PROT_EXEC من خلال ملف وصف قابل للكتابة. ويشمل ذلك أي ملف مشترَك (.so) يتضمّن عمليات إعادة تحديد موضع النص.

لا يقبل نظام التشغيل Android سوى ملفات OAT التي أنشأها النظام.

لم يعُد نظام التشغيل Android Runtime (ART) يستدعي dex2oat من عملية التطبيق. يعني هذا التغيير أنّ ART لن تقبل سوى ملفات OAT التي أنشأها النظام.

فرض صحة AOT في ART

في السابق، كان من الممكن أن يؤدي التحويل المُسبَق (AOT) الذي يُجريه Android Runtime (ART) إلى حدوث أعطال في وقت التشغيل إذا لم تكن بيئة classpath متطابقة في وقت التحويل المُسبَق ووقت التشغيل. يتطلّب الإصدار 10 من Android والإصدارات الأحدث دائمًا أن تكون سياقات البيئة هذه متطابقة، ما يؤدي إلى التغييرات التالية في السلوك:

• لا يتم تجميع أدوات تحميل الفئات المخصَّصة، أي محمّلات الفئات التي أنشأتها التطبيقات، على عكس أدوات تحميل الفئات من حزمة dalvik.system. ويعود السبب في ذلك إلى أنّه لا يمكن لـ ART معرفة تنفيذ البحث المخصّص عن الفئات أثناء التشغيل.
• يتم تجميع ملفات dex الثانوية، أي ملفات dex التي تحمّلها التطبيقات يدويًا والتي لا تكون في ملف APK الأساسي، باستخدام تقنية AOT في الخلفية. والسبب في ذلك هو أنّ تحويل المحتوى للمرة الأولى قد يكون مكلفًا جدًا، ما يؤدي إلى وقت استجابة غير مرغوب فيه قبل التنفيذ. يُرجى العلم أنّه بالنسبة إلى التطبيقات، يُنصح باستخدام ملفات APK المجزّأة والابتعاد عن ملفات APK الثانوية.
• يتم تنفيذ المكتبات المشتركة في Android (الإدخالان <library> و <uses-library> في ملف بيان Android) باستخدام التسلسل الهرمي المُختلف لتحميل الفئة عن التسلسل الهرمي المستخدَم في الإصدارات السابقة من النظام الأساسي.

تغييرات الأذونات لطلبات العرض ملء الشاشة

بالنسبة إلى التطبيقات التي تستهدف الإصدار 10 من نظام التشغيل Android أو الإصدارات الأحدث وتستخدم الإشعارات التي تتضمّن intents بملء الشاشة، يجب أن تطلب USE_FULL_SCREEN_INTENT إذنًا في ملف بيان التطبيق. هذا إذن عادي، وبالتالي يمنحه النظام تلقائيًا للتطبيق الذي يطلب الإذن.

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

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

التوافق مع الأجهزة القابلة للطي

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

عند تشغيل تطبيق على Android 10، تعمل الطريقتان onResume() و onPause() بشكل مختلف. عندما تظهر تطبيقات متعددة في الوقت نفسه في وضع "النوافذ المتعددة" أو وضع "العرض المتعدّد"، تكون جميع الأنشطة الرئيسية التي يمكن التركيز عليها في الحِزم المرئية في حالة الاستئناف، ولكن يتم التركيز على نشاط واحد فقط، وهو "أهم نشاط تم استئنافه". عند استخدام إصدارات أقدم من Android 10، يمكن استئناف activity واحد فقط في النظام في المرة الواحدة، ويتم إيقاف جميع الأنشطة المرئية الأخرى مؤقتًا.

لا تخلط بين "التركيز" ونشاط "أهم نشاط تم استئنافه". يحدّد النظام لأولويات الأنشطة استنادًا إلى الترتيب z-order لمنح الأولوية الأعلى للأنشطة التي تفاعل معها المستخدم مؤخرًا. يمكن إعادة عرض النشاط في المقدّمة، ولكن بدون التركيز عليه (على سبيل المثال، إذا كان مربّع إشعارات Android موسّعًا).

في الإصدار 10 من نظام التشغيل Android (المستوى 29 لواجهة برمجة التطبيقات) والإصدارات الأحدث، يمكنك الاشتراك في callback onTopResumedActivityChanged() لتلقّي إشعارات عندما يكتسب نشاطك أو يفقد الأولوية في قائمة التطبيقات التي تم استئناف تشغيلها. هذه الحالة هي ما يعادل حالة "استئناف" قبل Android 10، ويمكن أن تكون مفيدة كإشارة إلى ما إذا كان تطبيقك يستخدم موارد حصرية أو موارد فردية قد تحتاج إلى مشاركتها مع تطبيقات أخرى.

تم أيضًا تغيير سلوك سمة البيان resizeableActivity. إذا ضبط تطبيق قيمة resizeableActivity=false في Android 10 (المستوى 29 من واجهة برمجة التطبيقات) أو إصدار أحدث، قد يتم وضعه في وضع التوافق عند تغيير حجم الشاشة المتاح أو إذا تم نقل التطبيق من شاشة إلى أخرى.

يمكن للتطبيقات استخدام سمة android:minAspectRatio التي تم طرحها في Android 10 للإشارة إلى نسبة الشاشة التي يتوافق معها تطبيقك.

بدءًا من الإصدار 3.5، تتضمّن أداة المحاكي في Android Studio أجهزة افتراضية مقاس 7.3 بوصة و8 بوصة لاختبار الرمز البرمجي على شاشات أكبر حجمًا.

لمزيد من المعلومات، يُرجى الاطّلاع على مقالة تصميم تطبيقاتك للأجهزة القابلة للطي.