تغييرات في سلوك Android 5.0

مستوى واجهة برمجة التطبيقات: 21

بالإضافة إلى الميزات والإمكانات الجديدة، يتضمّن الإصدار 5.0 من Android مجموعة متنوعة من التغييرات في النظام وتغييرات في سلوك واجهة برمجة التطبيقات. يُبرز هذا المستند بعض التغييرات الرئيسية التي يجب فهمها والأخذ بها في تطبيقاتك.

إذا سبق لك نشر تطبيق لنظام التشغيل Android، يُرجى العِلم أنّ تطبيقك قد يتأثر بهذه التغييرات في Android 5.0.

للحصول على نظرة عامة على ميزات المنصة الجديدة، يمكنك بدلاً من ذلك الاطّلاع على أهم الميزات في Android Lollipop.

الفيديوهات

Dev Byte: الميزات الجديدة في Android 5.0

Dev Byte: الإشعارات

Android Runtime (ART)

في Android 5.0، يحلّ نظام التشغيل ART محلّ Dalvik كنظام التشغيل التلقائي. تم طرح بيئة التشغيل ART في الإصدار 4.4 من Android على أساس تجريبي.

للحصول على نظرة عامة على الميزات الجديدة في ART، يُرجى الاطّلاع على مقالة لمحة عن تكنولوجيا ART. في ما يلي بعض الميزات الجديدة الرئيسية:

• التجميع المُسبَق (AOT)
• تحسين عملية جمع البيانات المهملة
• تحسينات على ميزة تصحيح الأخطاء

من المفترض أن تعمل معظم تطبيقات Android بدون أي تغييرات باستخدام ART. ومع ذلك، لا تعمل بعض التقنيات التي تعمل على Dalvik على ART. للحصول على معلومات عن المشاكل الأكثر أهمية، يُرجى الاطّلاع على مقالة التحقّق من سلوك التطبيق على "مُشغِّل Android للتطبيقات" (ART). يُرجى الانتباه بشكل خاص في الحالات التالية:

• يستخدم تطبيقك Java Native Interface ‏ (JNI) لتشغيل رمز C/C++.
• استخدام أدوات تطوير تنشئ رمزًا غير عادي (مثل بعض برامج التشويش)
• استخدام تقنيات غير متوافقة مع جمع القمامة المضغوط

الإشعارات

تأكَّد من أنّ إشعاراتك تراعي هذه التغييرات في الإصدار 5.0 من Android. لمزيد من المعلومات حول تصميم الإشعارات لنظام التشغيل Android 5.0 والإصدارات الأحدث، اطّلِع على دليل تصميم الإشعارات.

نمط التصميم المتعدد الأبعاد

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

• استخدِم setColor() لضبط لون تمييز في دائرة خلف صورة الرمز.
• عدِّل مواد العرض التي تتضمّن ألوانًا أو أزِلها. يتجاهل النظام كل القنوات غير الأبجدية في رموز الإجراءات وفي رمز الإشعار الرئيسي. عليك الافتراض أنّ هذه الرموز ستكون أبجدية فقط. يرسم النظام رموز الإشعارات باللون الأبيض ورموز الإجراءات باللون الرمادي الداكن.

الصوت والاهتزاز

إذا كنت تضيف حاليًا أصواتًا واهتزازات إلى إشعاراتك من خلال استخدام الفئات Ringtone أو MediaPlayer أو Vibrator، أزِل هذا الرمز برمجيًا كي تتمكّن المنظومة من عرض الإشعارات بشكل صحيح في وضع الأولوية. بدلاً من ذلك، استخدِم methods Notification.Builder لإضافة الأصوات والاهتزازات.

يؤدي ضبط الجهاز على RINGER_MODE_SILENT إلى دخول الجهاز في وضع الأولوية الجديد. يخرج الجهاز من وضع الصعوبة المنخفضة إذا ضبطته على RINGER_MODE_NORMAL أو RINGER_MODE_VIBRATE.

في السابق، كان نظام التشغيل Android يستخدم STREAM_MUSIC كالبث الرئيسي للتحكّم في مستوى الصوت على الأجهزة اللوحية. في الإصدار 5.0 من نظام التشغيل Android، أصبح الآن بث مستوى الصوت الرئيسي للهاتف والجهاز اللوحي موحّدًا، ويتم التحكّم فيه باستخدام STREAM_RING أو STREAM_NOTIFICATION.

مستوى ظهور شاشة القفل

تظهر الإشعارات الآن تلقائيًا على شاشة القفل الخاصة بالمستخدم في Android 5.0. يمكن للمستخدمين اختيار حماية المعلومات الحسّاسة من الظهور، وفي هذه الحالة، يُخفي النظام تلقائيًا النص الذي يعرضه الإشعار. ل تخصيص هذا الإشعار الذي تم إخفاء معلوماته، استخدِم setPublicVersion().

إذا كان الإشعار لا يحتوي على معلومات شخصية، أو إذا كنت تريد السماح بتشغيل الوسائط من الإشعار، يمكنك استدعاء الأسلوب setVisibility() وضبط مستوى مستوى ظهور الإشعار على VISIBILITY_PUBLIC.

تشغيل الوسائط

إذا كنت بصدد تنفيذ إشعارات تعرض حالة تشغيل الوسائط أو عناصر التحكّم في النقل، ننصحك باستخدام نموذج Notification.MediaStyle الجديد بدلاً من عنصر RemoteViews.RemoteView مخصّص. أيًا كان النهج الذي تختاره، احرص على ضبط مستوى ظهور الإشعار على VISIBILITY_PUBLIC حتى تتمكّن من الوصول إلى عناصر التحكّم من شاشة القفل. يُرجى العِلم أنّه اعتبارًا من الإصدار Android 5.0، لم يعُد النظام يعرض RemoteControlClient عنصرًا على شاشة القفل. لمزيد من المعلومات، يُرجى الاطّلاع على إذا كان تطبيقك يستخدم RemoteControlClient.

تنبيه

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

تشمل أمثلة الشروط التي قد تؤدي إلى عرض التنبيهات ما يلي:

• نشاط المستخدم في وضع ملء الشاشة (يستخدم التطبيق fullScreenIntent)
• الإشعار له أولوية عالية ويستخدم نغمات رنين أو اهتزازات

إذا كان تطبيقك يعرض الإشعارات في أيّ من هذه الحالات، تأكّد من عرض التنبيهات بشكل صحيح.

أدوات التحكّم في الوسائط وRemoteControlClient

تم إيقاف فئة RemoteControlClient نهائيًا. عليك التبديل إلى واجهة برمجة تطبيقات MediaSession الجديدة في أقرب وقت ممكن.

لا تعرض شاشات القفل في Android 5.0 عناصر التحكّم في وسائل النقل لجهاز MediaSession أو RemoteControlClient. بدلاً من ذلك، يمكن لتطبيقك توفير إمكانية التحكّم في تشغيل الوسائط من شاشة القفل من خلال إشعار. ويمنح ذلك تطبيقك مزيدًا من التحكّم في عرض أزرار الوسائط، مع تقديم تجربة متّسقة للمستخدمين على الأجهزة المقفلة والمُفتحة.

يقدّم نظام التشغيل Android 5.0 نموذج Notification.MediaStyle جديدًا لهذا الغرض. تعمل أداة Notification.MediaStyle على تحويل إجراءات الإشعارات التي أضفتها باستخدام Notification.Builder.addAction() إلى أزرار مدمجة في إشعارات تشغيل الوسائط في تطبيقك. نقْل رمز الجلسة إلى الأسلوب setSession() لإعلام النظام بأنّ هذا الإشعار يتحكّم في جلسة وسائط جارية.

احرص على ضبط مستوى ظهور الإشعار على VISIBILITY_PUBLIC لتمييز الإشعار على أنّه آمن للعرض على أي شاشة قفل (آمنة أو غير آمنة). لمزيد من المعلومات، يُرجى الاطّلاع على الإشعارات على شاشة القفل.

لعرض عناصر التحكّم في تشغيل الوسائط إذا كان تطبيقك قيد التشغيل على منصة Android TV أو Wear، نفِّذ فئة MediaSession. يجب أيضًا تنفيذ MediaSession إذا كان تطبيقك يحتاج إلى تلقّي أحداث buttons الوسائط على أجهزة Android.

getRecentTasks()

مع طرح ميزة مهام المستندات والنشاطات المتزامنة الجديدة في Android 5.0 (راجِع المستندات والنشاطات المتزامنة في شاشة "التطبيقات المستخدَمة مؤخرًا" أدناه)، تم إيقاف طريقة ActivityManager.getRecentTasks() نهائيًا لتحسين خصوصية المستخدم. للحفاظ على التوافق مع الإصدارات القديمة، لا تزال هذه الطريقة تعرض مجموعة فرعية صغيرة من بياناتها، بما في ذلك مهام التطبيق المُتصل وربما بعض المهام الأخرى غير الحسّاسة (مثل Home). إذا كان تطبيقك يستخدم هذه الطريقة لاسترداد مهام التطبيق، استخدِم getAppTasks() بدلاً من ذلك لاسترداد هذه المعلومات.

إتاحة الإصدار 64 بت في حِزم تطوير البرامج (NDK) لنظام Android

يتيح نظام Android 5.0 استخدام الأنظمة التي تعمل بإصدار 64 بت. يؤدي تحسين الإصدار 64 بت إلى زيادة مساحة العناوين وتحسين الأداء، مع مواصلة إتاحة التطبيقات الحالية 32 بت بالكامل. يُحسِّن التوافق مع الإصدار 64 بت أيضًا أداء مكتبة OpenSSL لتشفير البيانات. بالإضافة إلى ذلك، يقدّم هذا الإصدار واجهات برمجة تطبيقات NDK جديدة لمعالجة الوسائط، بالإضافة إلى إتاحة استخدام OpenGL ES 3.1 الأصلي.

لاستخدام ميزة التوافق مع الإصدار 64 بت المتوفّرة في Android 5.0، عليك تنزيل الإصدار 10c من NDK و تثبيته من صفحة Android NDK. يُرجى الرجوع إلى ملاحظات الإصدار للمراجعة 10c لمزيد من المعلومات عن التغييرات المهمة وإصلاحات الأخطاء في حزمة NDK.

الربط بخدمة

تتطلّب الآن الطريقة Context.bindService() Intent صريحًا، وتُعرِض استثناءً في حال تم تقديم هدف ضمني. لضمان أمان تطبيقك، استخدِم نية صريحة عند بدء Service أو ربطه، ولا تحدِّد فلاتر النية للخدمة.

WebView

يغيّر الإصدار 5.0 من Android السلوك التلقائي لتطبيقك.

• إذا كان تطبيقك يستهدف المستوى 21 أو أعلى من واجهة برمجة التطبيقات:
  • يحظر النظام المحتوى المختلط وملفات تعريف الارتباط التابعة لجهات خارجية تلقائيًا. للسماح بالمحتوى المختلط وملفات تعريف الارتباط التابعة لجهات خارجية، استخدِم الطريقتَين setMixedContentMode() وsetAcceptThirdPartyCookies() على التوالي.
  • يختار النظام الآن أجزاء من مستند HTML لرسمها بشكل ذكي. يساعد هذا السلوك التلقائي الجديد في تقليل مساحة التخزين وزيادة الأداء. إذا كنت تريد عرض المستند بأكمله في آنٍ واحد، أوقِف هذا التحسين من خلال استدعاء enableSlowWholeDocumentDraw().
• إذا كان تطبيقك يستهدف مستويات واجهة برمجة التطبيقات أقل من 21: يسمح النظام بالمحتوى المختلط وملفات تعريف الارتباط التابعة لجهات خارجية، ويعرض دائمًا المستند بأكمله في آنٍ واحد.

متطلّبات التفرد للأذونات المخصّصة

كما هو موضّح في النظرة العامة على الأذونات، يمكن لتطبيقات Android تحديد أذونات مخصّصة كوسيلة لإدارة الوصول إلى المكوّنات بطريقة خاصة بجهة التطوير، بدون استخدام أذونات النظام المحدّدة مسبقًا للمنصة. تحدِّد التطبيقات الأذونات المخصّصة في عناصر <permission> المُعلَن عنها في ملفات البيان.

هناك عدد قليل من السيناريوهات التي يكون فيها تحديد الأذونات المخصّصة هو منهجًا مشروعًا وآمنًا. ومع ذلك، قد لا يكون إنشاء أذونات مخصّصة ضروريًا في بعض الأحيان، وقد يشكّل حتى خطرًا محتمَلاً على التطبيق، استنادًا إلى مستوى الحماية المحدّد للأذونات.

يتضمّن الإصدار 5.0 من نظام التشغيل Android تغييرًا في السلوك لضمان أنّه لا يمكن إلّا لتطبيق واحد تحديد إذن مخصّص معيّن، ما لم يتم توقيعه باستخدام المفتاح نفسه المستخدَم في التطبيقات الأخرى التي تحدّد الإذن.

التطبيقات التي تستخدم أذونات مخصّصة مكرّرة

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

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

بدءًا من الإصدار 5.0 من Android، يفرض النظام قيودًا جديدة على أذونات التطبيقات المخصّصة التي تم توقيعها بمفاتيح مختلفة. يمكن الآن لتطبيق واحد فقط على الجهاز تحديد إذن مخصّص معيّن (على النحو الذي يحدّده اسمه)، ما لم يتم توقيع التطبيق الآخر الذي يحدّد الإذن باستخدام المفتاح نفسه. إذا حاول المستخدم تثبيت تطبيق يتضمّن إذنًا مخصّصًا مكرّرًا ولم يتم توقيعه باستخدام المفتاح نفسه المستخدَم في التطبيق المُقيم الذي يحدِّد الإذن، يحظر النظام عملية التثبيت.

اعتبارات بشأن تطبيقك

في الإصدار 5.0 من نظام التشغيل Android والإصدارات الأحدث، يمكن للتطبيقات مواصلة تحديد أذونات المخصّصة الخاصة بها كما في السابق وطلب أذونات مخصّصة من تطبيقات أخرى من خلال آلية <uses-permission>. ومع ذلك، مع ال requirement الجديد الذي تم تقديمه في Android 5.0، عليك تقييم الآثار المحتملة على تطبيقك بعناية.

في ما يلي بعض النقاط التي يجب أخذها في الاعتبار:

• هل يعلن تطبيقك عن أي عناصر <permission> في بيانه؟ إذا كان الأمر كذلك، هل هذه البيانات ضرورية فعلاً لتشغيل تطبيقك أو خدمتك بشكل سليم؟ أو هل يمكنك استخدام إذن تلقائي للنظام بدلاً من ذلك؟
• إذا كان لديك عناصر <permission> في تطبيقك، هل تعرف مصدر هذه العناصر؟
• هل تريد أن تطلب التطبيقات الأخرى أذوناتك المخصّصة من خلال <uses-permission>؟
• هل تستخدم نموذجًا أو رمزًا نموذجيًا في تطبيقك يتضمّن عناصر <permission>؟ هل عناصر الأذونات هذه ضرورية فعلاً؟
• هل تستخدم أذوناتك المخصّصة أسماء بسيطة أو تستند إلى عبارات شائعة قد تشترك فيها تطبيقات أخرى؟

عمليات التثبيت والتحديثات الجديدة

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

عمليات التثبيت الحالية التي تتضمّن تحديث نظام Android 5.0

إذا كان تطبيقك يستخدم أذونات مخصّصة وكان موزّعًا ومُثبَّتًا على نطاق واسع، من المحتمل أن يتأثّر عندما يتلقّى المستخدمون تحديثًا لنظام التشغيل Android 5.0. بعد تثبيت تحديث النظام، يُعيد النظام التحقّق من صحة التطبيقات المثبَّتة، بما في ذلك التحقّق من أذوناتها المخصّصة. إذا كان تطبيقك يحدِّد إذنًا مخصّصًا سبق أن حدَّده تطبيق آخر تم التحقّق منه، ولم يتم توقيع تطبيقك باستخدام المفتاح نفسه المستخدَم في التطبيق الآخر، لا يعيد النظام تثبيت تطبيقك.

الاقتراحات

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

• إذا كنت تستخدم أذونات مخصّصة في تطبيقك، ننصحك بالتفكير في مصدرها وما إذا كنت بحاجة إليها فعلاً. أزِل من تطبيقك كل عناصر <permission>، ما لم تكن متأكّدًا من أنّها مطلوبة لتشغيل تطبيقك بشكل سليم.
• ننصحك باستبدال أذوناتك المخصّصة بأذونات النظام التلقائية كلما أمكن ذلك.
• إذا كان تطبيقك يتطلّب أذونات مخصّصة، عليك إعادة تسمية أذوناتك المخصّصة لتكون فريدة لتطبيقك، مثلاً من خلال إلحاقها باسم الحزمة بالكامل لتطبيقك.
• إذا كانت لديك مجموعة من التطبيقات موقَّعة بمفاتيح مختلفة وكانت التطبيقات تصل إلى مكوّن مشترَك من خلال إذن مخصّص، تأكَّد من تحديد الإذن المخصّص مرة واحدة فقط في المكوّن المشترَك. على التطبيقات التي تستخدم المكوّن المشترَك عدم تحديد الإذن المخصّص بنفسها، بل يجب أن تطلب الوصول من خلال آلية <uses-permission>.
• إذا كانت لديك مجموعة من التطبيقات موقَّعة باستخدام المفتاح نفسه، يمكن لكل تطبيق تحديد الأذونات المخصّصة نفسها حسب الحاجة ، ويسمح النظام بتثبيت التطبيقات بالطريقة المعتادة.

تغييرات الإعدادات التلقائية لبروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL)

يُجري نظام التشغيل Android 5.0 تغييرات على الإعدادات التلقائية لبروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) التي تستخدمها التطبيقات في ما يتعلّق ببروتوكول HTTPS وعمليات نقل البيانات الأخرى التي تستخدم بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة:

• تم تفعيل بروتوكولَي TLSv1.2 وTLSv1.1.
• تم تفعيل مجموعات رموز التشفير AES-GCM (AEAD) الآن.
• تم إيقاف مجموعات رموز التشفير MD5 و3DES ومجموعة رموز التشفير ECDH للمفتاح الثابت ومجموعة رموز التشفير للتصدير.
• يُفضّل استخدام مجموعات رموز سرية مفاتيح الجلسات المستقبلية (ECDHE وDHE).

قد تؤدي هذه التغييرات إلى انقطاع الاتصال عبر HTTPS أو TLS/SSL في عدد صغير من الحالات المُدرَجة أدناه.

يُرجى العِلم أنّ فئة ProviderInstaller الأمنية من "خدمات Google Play" تقدّم هذه التغييرات على جميع إصدارات نظام Android الأساسي، بدءًا من الإصدار 2.3.

لا يدعم الخادم أيًا من مجموعات التشفير المفعَّلة.

على سبيل المثال، قد لا يتوافق الخادم إلا مع مجموعات التشفير 3DES أو MD5. المعالجة المفضّلة هي تحسين إعدادات الخادم لتفعيل مجموعات الرموز البرمجية والبروتوكولات الأكثر فعالية وحداثة. من الأفضل تفعيل بروتوكول TLSv1.2 وAES-GCM، ويجب تفعيل مجموعات ترميز "السرية المستقبلية" (ECDHE وDHE) واستخدامها كخيار مفضّل.

هناك بديل وهو تعديل التطبيق لاستخدام SSLSocketFactory مخصّص ل التواصل مع الخادم. يجب تصميم المصنع لإنشاء مثيلات SSLSocket التي تم فيها تفعيل بعض مجموعات التشفير المطلوبة من الخادم بالإضافة إلى مجموعات التشفير التلقائية.

يُجري التطبيق افتراضات خاطئة حول مجموعات التشفير المستخدَمة للاتصال بالخادم.

على سبيل المثال، تحتوي بعض التطبيقات على فئة X509TrustManager مخصّصة تتعذّر إدارتها لأنّها تتوقع أن تكون مَعلمة authType هي RSA، ولكنّها تواجه ECDHE_RSA أو DHE_RSA.

لا يقبل الخادم الإصدار 1.1 من بروتوكول أمان طبقة النقل (TLS) أو الإصدار 1.2 أو الإضافات الجديدة لبروتوكول أمان طبقة النقل (TLS).

على سبيل المثال، يتم رفض تأكيد الاتصال بطبقة النقل الآمنة (TLS)/طبقة المقابس الآمنة (SSL) مع الخادم عن طريق الخطأ أو يتوقّف. إنّ الحلّ المفضّل هو ترقية الخادم بما يتوافق مع بروتوكول أمان طبقة النقل (TLS)/بروتوكول طبقة المقابس الآمنة (SSL). سيؤدي ذلك إلى نجاح الخادم في التفاوض بشأن هذه البروتوكولات الأحدث أو التفاوض بشأن بروتوكول TLSv1 أو البروتوكولات الأقدم وتجاهل إضافات TLS التي لا يفهمها. في بعض الحالات، قد يكون إيقاف بروتوكولَي TLSv1.1 وTLSv1.2 على الخادم إجراءً مؤقتًا إلى أن يتم ترقية برنامج الخادم.

هناك بديل وهو تعديل التطبيق لاستخدام SSLSocketFactory مخصّص ل التواصل مع الخادم. يجب تصميم المصنع لإنشاء مثيلات SSLSocket مع تفعيل البروتوكولات التي يتوافق معها الخادم بشكل صحيح فقط.

إتاحة الملفات الشخصية المُدارة

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

التعامل مع المقاصد

يمكن لمشرفي الجهاز حظر الوصول إلى تطبيقات النظام من الملف الشخصي المُدار. في هذه الحالة، إذا أطلق تطبيق نية من الملف الشخصي المُدار كان من المفترض أن يعالجها هذا التطبيق، ولم يكن هناك معالِج مناسب للنية في الملف الشخصي المُدار، سيؤدي ذلك إلى حدوث استثناء. على سبيل المثال، يمكن لمدير الجهاز منع التطبيقات في الملف الشخصي المُدار من الوصول إلى تطبيق كاميرا النظام. إذا كان تطبيقك قيد التشغيل على الملف الشخصي المُدار ويطلب startActivityForResult() من أجل MediaStore.ACTION_IMAGE_CAPTURE، ولم يكن هناك تطبيق على الملف الشخصي المُدار يمكنه معالجة النية، سيؤدي ذلك إلى حدوث ActivityNotFoundException.

يمكنك منع حدوث ذلك من خلال التحقّق مما إذا كان هناك معالِج واحد على الأقل لأي نية قبل تشغيلها. للتحقّق من توفّر معالِج صالح، يُرجى الاتصال على Intent.resolveActivity(). يمكنك الاطّلاع على مثال على ذلك في مقالة التقاط الصور ببساطة: التقاط صورة باستخدام تطبيق "الكاميرا".

مشاركة الملفات بين الملفات الشخصية

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

لضمان الأمان، عند الحاجة إلى إرفاق ملف بطلب قد ينتقل من ملف شخصي إلى ملف آخر، يجب إنشاء معرِّف موارد منتظم (URI) للمحتوى واستخدامه للملف. لمزيد من المعلومات حول مشاركة الملفات باستخدام معرّفات الموارد المنتظمة (URI) للمحتوى، يُرجى الاطّلاع على مقالة مشاركة الملفات. على سبيل المثال، قد يسمح مشرف الجهاز باستخدام ACTION_IMAGE_CAPTURE من خلال الكاميرا في الملف الشخصي. يجب أن يحتوي EXTRA_OUTPUT لهدف التفعيل على محتوى عنوان URL يحدّد مكان تخزين الصورة. يمكن لتطبيق الكاميرا كتابة الصورة في الموقع المحدَّد من خلال عنوان URI هذا، وسيكون بإمكان التطبيق الذي بدأ النية قراءة هذا الملف، حتى إذا كان التطبيق مثبَّتًا على الملف الشخصي الآخر.

إزالة إمكانية استخدام التطبيقات المصغّرة على شاشة القفل

يزيل نظام التشغيل Android 5.0 إمكانية استخدام التطبيقات المصغّرة على شاشة القفل، ولكنه يواصل السماح باستخدام التطبيقات المصغّرة على الشاشة الرئيسية.