تغييرات السلوك: التطبيقات التي تستهدف المستوى 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 والإصدارات الأحدث دائمًا أن تكون سياقات البيئة هذه متطابقة، ما يؤدي إلى إجراء التغييرات التالية في السلوك:

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

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