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

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

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

ملاحظة: بالإضافة إلى التغييرات الواردة في هذه الصفحة، يقدّم نظام التشغيل Android 10 عددًا كبيرًا من القيود والتغييرات المستندة إلى الخصوصية، ومن بينها ما يلي:

  • التخزين الفرعي
  • الوصول إلى الرقم التسلسلي لجهاز USB
  • إمكانية تمكين شبكة Wi-Fi وتعطيلها وتكوينها
  • أذونات تحديد الموقع الجغرافي لواجهات برمجة التطبيقات للاتصال

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

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

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

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

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

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

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

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

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

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

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

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

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

لا يقبل وقت تشغيل Android إلا ملفات OAT التي ينشئها النظام.

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

فرض صحة AOT في الأداة ART

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

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

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

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

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

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

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

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

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

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