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