مستوى واجهة برمجة التطبيقات: 21
إلى جانب الميزات والإمكانات الجديدة، يشتمل Android 5.0 على مجموعة متنوعة من تغييرات النظام والتغييرات في سلوك واجهة برمجة التطبيقات. يسلط هذا المستند الضوء على بعض التغييرات الرئيسية التي يجب أن تفهمها وتراعيها في تطبيقاتك.
إذا سبق لك نشر تطبيق لنظام التشغيل Android، يُرجى العلم أن تطبيقك قد يتأثر بهذه التغييرات في الإصدار Android 5.0.
للحصول على نظرة عالية المستوى على الميزات الجديدة للنظام الأساسي، يمكنك بدلاً من ذلك الاطّلاع على أبرز ميزات Android Lollipop.
الفيديوهات الطويلة
Dev Byte: الميزات الجديدة في Android 5.0
حزمة مطوّري البرامج: الإشعارات
وقت تشغيل Android (ART)
في Android 5.0، يحل وقت تشغيل ART محل Dalvik كإعداد افتراضي للنظام الأساسي. تم تقديم وقت تشغيل ART في Android 4.4 على أساس تجريبي.
لإلقاء نظرة عامة على الميزات الجديدة في أداة ART، راجع نقدّم لك ART. في ما يلي بعض الميزات الرئيسية الجديدة:
- المحتوى المجمّع مسبقًا (AOT)
- تحسين عملية جمع البيانات غير الصالحة (GC)
- دعم محسّن لتصحيح الأخطاء
من المفترض أن تعمل معظم تطبيقات Android بدون أي تغييرات بموجب ART. ومع ذلك، فإن بعض الأساليب التي تعمل على Dalvik لا تعمل على ART. للحصول على معلومات حول أهم المشاكل، راجِع التحقق من سلوك التطبيق في وقت تشغيل Android (ART). يجب الانتباه بشكل خاص في الحالات التالية:
- يستخدم تطبيقك الواجهة الأصلية للغة Java (JNI) لتشغيل ترميز C/C++.
- استخدام أدوات تطوير تنشئ رمزًا غير عادي (مثل بعض أدوات التشويش).
- ولكنك تستخدم تقنيات غير متوافقة مع ضغط مجموعة البيانات المهملة.
الإشعارات
تأكد من أن إشعاراتك تأخذ تغييرات Android 5.0 هذه في الاعتبار. للاطّلاع على مزيد من المعلومات حول تصميم إشعاراتك للإصدار 5.0 من نظام التشغيل Android والإصدارات الأحدث، يمكنك مراجعة دليل تصميم الإشعارات.
نمط التصميم المتعدد الأبعاد
ويتم رسم الإشعارات بنص داكن فوق خلفيات بيضاء (أو فاتحة جدًا) لتتناسب مع التطبيقات المصغّرة الجديدة للتصميم المتعدد الأبعاد. احرص على أن تظهر كل الإشعارات بشكل صحيح باستخدام نظام الألوان الجديد. إذا بدت إشعاراتك غير صحيحة، فأصلحها:
- يمكنك استخدام
setColor()لتحديد لون تمييز في دائرة خلف صورة الرمز. - عدِّل مواد العرض التي تتضمّن ألوانًا أو أزِلها. يتجاهل النظام جميع القنوات التي ليست ألفا في رموز الإجراءات وفي رمز الإشعار الرئيسي. ويجب أن تفترض أنّ هذه الرموز ستكون في إصدار أولي فقط. يرسم النظام رموز الإشعارات باللون الأبيض، ورموز إجراءات باللون الرمادي الداكن.
الصوت والاهتزاز
إذا كنت تضيف حاليًا أصواتًا واهتزازات إلى الإشعارات من خلال
استخدام فئات Ringtone أو MediaPlayer
أو Vibrator، عليك إزالة هذا الرمز حتى يتمكن
النظام من تقديم الإشعارات بشكل صحيح في
وضع الأولوية. بدلاً من ذلك، يمكنك استخدام طرق
Notification.Builder لإضافة الأصوات
والاهتزاز.
ضبط الجهاز على RINGER_MODE_SILENT يؤدي إلى
إدخال الجهاز في وضع الأولوية الجديد. سيترك الجهاز وضع الأولوية
عند ضبطه على
RINGER_MODE_NORMAL أو
RINGER_MODE_VIBRATE.
في السابق، كان نظام Android يستخدم STREAM_MUSIC
كالبث الرئيسي للتحكّم في مستوى الصوت على الأجهزة اللوحية. في الإصدار Android 5.0، تم الآن توحيد بث مستوى الصوت الرئيسي لكل من الهواتف والأجهزة اللوحية، ويتم التحكّم فيه من خلال STREAM_RING أو STREAM_NOTIFICATION.
ظهور شاشة القفل
تظهر الإشعارات الآن بشكلٍ تلقائي على شاشة القفل للمستخدم في الإصدار Android 5.0.
يمكن للمستخدمين اختيار حماية المعلومات الحساسة من الكشف عنها، وفي هذه الحالة
يعمل النظام تلقائيًا على إخفاء النص الذي يعرضه الإشعار. لتخصيص هذا الإشعار، يمكنك استخدام
setPublicVersion().
إذا لم يتضمّن الإشعار أي معلومات شخصية، أو إذا كنت تريد السماح بالتحكّم في تشغيل الوسائط في الإشعار، اتّصِل بالطريقة
setVisibility()
واضبط مستوى رؤية الإشعار على
VISIBILITY_PUBLIC.
تشغيل الوسائط
إذا كنت تنفّذ الإشعارات التي تعرض حالة تشغيل الوسائط أو عناصر التحكم في النقل، يمكنك استخدام نموذج Notification.MediaStyle الجديد بدلاً من عنصر RemoteViews.RemoteView مخصّص. وأيًا كان الأسلوب الذي
تختاره، تأكد من ضبط مستوى رؤية الإشعار على
VISIBILITY_PUBLIC بحيث
يمكن الوصول إلى عناصر التحكم من شاشة القفل. تجدر الإشارة إلى أنّه بدءًا من نظام التشغيل Android 5.0، لن يعرض النظام عناصر RemoteControlClient على شاشة القفل. وللحصول على مزيد من المعلومات،
يمكنك الاطّلاع على المقالة
في حال كان تطبيقك يستخدم RemoteControlClient.
تنبيه
قد تظهر الإشعارات الآن في نافذة عائمة صغيرة (تسمى أيضًا بالإشعار التنبيه) عندما يكون الجهاز نشطًا (أي عندما يكون الجهاز مفتوحًا وشاشته قيد التشغيل). تبدو هذه الإشعارات مشابهة للشكل المكثّف من الإشعار، باستثناء أنّ إشعار الإشعار يعرض أيضًا أزرار الإجراءات. يمكن للمستخدمين اتخاذ إجراء بناءً على إشعار تنبيه أو رفضه بدون مغادرة التطبيق الحالي.
تشمل أمثلة الحالات التي قد تؤدي إلى ظهور إشعارات تنبيه:
- يكون نشاط المستخدم في وضع ملء الشاشة (يستخدم التطبيق
fullScreenIntent) - يتمتع الإشعار بأولوية عالية ويستخدم نغمات رنين أو اهتزازات
إذا كان تطبيقك ينفّذ الإشعارات تحت أي من هذه السيناريوهات، تأكد من عرض إشعارات التنبيه بشكل صحيح.
Media Control and 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 إذا كان تطبيقك يحتاج إلى تلقّي أحداث أزرار
الوسائط على أجهزة Android.
getRecentTasks()
مع طرح ميزة مهام الأنشطة
والمستندات المتزامنة الجديدة في نظام التشغيل Android 5.0 (راجع المستندات
والأنشطة المتزامنة في شاشة الأجهزة الحديثة أدناه)،
تم إيقاف طريقة ActivityManager.getRecentTasks() لتحسين خصوصية
المستخدم. للتوافق مع الأنظمة القديمة، لا تزال هذه الطريقة تعرض مجموعة فرعية صغيرة من بياناته، بما في ذلك المهام الخاصة بتطبيق الاتصال وربما بعض المهام الأخرى
غير الحساسة (مثل المنزل). إذا كان تطبيقك يستخدم هذه الطريقة لاسترداد
مهامه الخاصة، استخدِم getAppTasks() بدلاً من ذلك لاسترداد هذه المعلومات.
دعم 64 بت في NDK على Android
يقدم Android 5.0 توافقًا مع أنظمة الإصدار 64 بت. يعمل التحسين 64 بت على زيادة مساحة العنوان وتحسين الأداء، مع مواصلة التوافق مع التطبيقات الحالية بنظام 32 بت بشكل كامل. ويحسّن توافق الإصدار 64 بت أيضًا أداء OpenSSL للتشفير. بالإضافة إلى ذلك، يقدّم هذا الإصدار واجهات برمجة تطبيقات NDK للوسائط المحلية، فضلاً عن الإصدار 3.1 من OpenGL ES (GLES) الأصلي.
لاستخدام إصدار 64 بت المتوفّر في Android 5.0، عليك تنزيل وتثبيت NDK Revision 10c من صفحة Android NDK. يمكنك الرجوع إلى ملاحظات الإصدار Revision 10c للحصول على مزيد من المعلومات عن التغييرات المهمة وإصلاحات الأخطاء التي تم إجراؤها على NDK.
الالتزام بخدمة
تتطلّب الطريقة Context.bindService() الآن استخدام Intent صريحًا،
وتطرح استثناءً إذا تم تحديد نية ضمنية.
لضمان أمان تطبيقك، استخدِم هدفًا صريحًا عند بدء تشغيل Service أو ربطه، ولا تُفصِح عن فلاتر الأهداف للخدمة.
WebView
يغيّر Android 5.0 السلوك التلقائي لتطبيقك.
- إذا كان تطبيقك يستهدف المستوى 21 من واجهة برمجة التطبيقات أو المستويات الأعلى:
- يحظر النظام
المحتوى المختلَط وملفات تعريف الارتباط التابعة لجهات خارجية تلقائيًا. للسماح بالمحتوى المختلَط وملفات تعريف الارتباط التابعة لجهات خارجية، استخدِم الطريقتَين
setMixedContentMode()وsetAcceptThirdPartyCookies()على التوالي. - يختار النظام الآن بشكل ذكي أجزاء من مستند HTML لرسمها. يساعد هذا السلوك التلقائي الجديد في تقليل تأثير الذاكرة وتحسين الأداء. إذا كنت تريد
عرض المستند بأكمله في آنٍ واحد، يجب إيقاف هذا التحسين عن طريق طلب
enableSlowWholeDocumentDraw().
- يحظر النظام
المحتوى المختلَط وملفات تعريف الارتباط التابعة لجهات خارجية تلقائيًا. للسماح بالمحتوى المختلَط وملفات تعريف الارتباط التابعة لجهات خارجية، استخدِم الطريقتَين
- إذا كان تطبيقك يستهدف مستويات أقل من 21 لواجهة برمجة التطبيقات: يسمح النظام بالمحتوى المختلَط وملفات تعريف الارتباط التابعة لجهات خارجية، ويعرض دائمًا المستند بأكمله في الوقت نفسه.
متطلبات التفرّد للأذونات المخصَّصة
كما هو موثق في النظرة العامة على الأذونات، يمكن لتطبيقات Android تحديد الأذونات المخصصة كوسيلة لإدارة الوصول إلى المكوّنات بطريقة خاصة، بدون استخدام أذونات النظام المحددة مسبقًا للنظام الأساسي. تحدِّد التطبيقات الأذونات المخصَّصة في عناصر
<permission> التي تم تضمينها في ملفات البيان.
هناك عدد قليل من السيناريوهات التي يكون فيها تحديد الأذونات المخصَّصة أسلوبًا مشروعًا وآمنًا. ومع ذلك، قد لا يكون إنشاء أذونات مخصّصة في بعض الأحيان ضروريًا، بل يمكن أن يشكّل خطرًا محتملاً على التطبيق، وذلك بناءً على مستوى الحماية المخصّص للأذونات.
يتضمن الإصدار Android 5.0 تغييرًا في السلوك لضمان منح تطبيق واحد فقط إذنًا مخصّصًا، ما لم يتم توقيعه باستخدام المفتاح نفسه الذي تستخدمه التطبيقات الأخرى التي تحدّد الإذن.
التطبيقات التي تستخدم أذونات مُخصَّصة مكرّرة
ويمكن لأي تطبيق تحديد أي إذن مخصّص يريده، لذا قد تتعرّف تطبيقات متعددة على الإذن المخصّص نفسه. على سبيل المثال، إذا كان تطبيقان يوفّران إمكانية مماثلة، قد يحصلان على الاسم المنطقي نفسه لأذوناتهما المخصّصة. وقد تدمج التطبيقات أيضًا مكتبات عامة شائعة أو أمثلة على رموز تتضمن تعريفات الأذونات المخصَّصة نفسها.
في الإصدار 4.4 من نظام التشغيل Android والإصدارات الأقدم، تمكّن المستخدمون من تثبيت عدة تطبيقات من هذا النوع على جهاز معيّن، إلا أنّ النظام حدّد مستوى الحماية الذي حدّده أول تطبيق تم تثبيته.
بدءًا من نظام التشغيل Android 5.0، يفرض النظام قيودًا جديدة على مستوى التفرُّد على الأذونات المخصَّصة للتطبيقات التي تم توقيعها باستخدام مفاتيح مختلفة. الآن، يمكن لتطبيق واحد فقط على الجهاز تحديد إذن مخصّص معيّن (على النحو الذي يحدّده اسمه)، ما لم يوقِّع التطبيق الآخر الذي يحدّد الإذن باستخدام المفتاح نفسه. إذا حاول المستخدم تثبيت تطبيق باستخدام إذن مخصَّص مكرّر ولم يوقِّع على المفتاح نفسه مثل التطبيق المقيم الذي يُحدِّد الإذن، سيحظر النظام عملية التثبيت.
اعتبارات تطبيقك
في نظام التشغيل Android 5.0 والإصدارات الأحدث، يمكن للتطبيقات مواصلة تحديد أذوناتها المخصّصة تمامًا كما في السابق وطلب أذونات مخصّصة من التطبيقات الأخرى من خلال آلية <uses-permission>. ومع المتطلبات الجديدة التي تم تقديمها في Android 5.0، عليك تقييم التأثيرات المحتملة على تطبيقك بعناية.
فيما يلي بعض النقاط التي يجب وضعها في الاعتبار:
- هل يذكر تطبيقك في بيانه أي عناصر من
<permission>؟ إذا كان الأمر كذلك، هل هي ضرورية فعلاً لأداء التطبيق أو الخدمة بشكل مناسب؟ أو هل يمكنك استخدام إذن تلقائي للنظام بدلاً من ذلك؟ - إذا كان لديك عناصر
<permission>في تطبيقك، هل تعرف من أين كانت هذه العناصر؟ - هل تريد فعلاً أن تطلب التطبيقات الأخرى أذوناتك المخصّصة من خلال
<uses-permission>؟ - هل تستخدم نصًا نموذجيًا أو نموذجًا لرمز في تطبيقك يتضمّن عناصر
<permission>؟ هل عناصر الأذونات هذه ضرورية فعلاً؟ - هل تستخدم أذوناتك المخصّصة أسماء بسيطة أو تستند إلى عبارات شائعة قد تشاركها التطبيقات الأخرى؟
عمليات التثبيت والتحديثات الجديدة
كما ذكرنا أعلاه، لن تتأثر عمليات التثبيت والتحديثات الجديدة لتطبيقك على الأجهزة التي تعمل بالإصدار 4.4 من نظام التشغيل Android أو الإصدارات الأقدم وليس هناك أي تغيير في السلوك. بالنسبة إلى عمليات التثبيت والتحديثات الجديدة على الأجهزة التي تعمل بالإصدار 5.0 من نظام التشغيل Android أو الإصدارات الأحدث، يمنع النظام تثبيت تطبيقك إذا كان يحدد إذنًا مخصّصًا سبق أن تم تحديده من خلال تطبيق حالي.
عمليات التثبيت الحالية مع تحديث نظام Android 5.0
إذا كان تطبيقك يستخدم أذونات مخصّصة ويتم توزيعه وتثبيته على نطاق واسع، من المُحتمَل أن يتأثر بذلك عندما يتلقّى المستخدمون تحديثات لأجهزتهم إلى الإصدار Android 5.0. بعد تثبيت تحديث النظام، يعيد النظام التحقّق من التطبيقات المثبّتة، بما في ذلك التحقّق من أذوناتها المخصّصة. إذا حدّد تطبيقك إذنًا مخصّصًا سبق أن تم تحديده من خلال تطبيق آخر سبق أن تم إثبات ملكيته، ولم يوقِّع تطبيقك باستخدام المفتاح نفسه الذي يستخدمه التطبيق الآخر، لن يُعيد النظام تثبيت تطبيقك.
الفيديوهات المقترَحة
على الأجهزة التي تعمل بالإصدار 5.0 من نظام التشغيل Android أو الإصدارات الأحدث، ننصح بفحص تطبيقك على الفور وإجراء أي تعديلات مطلوبة ونشر الإصدار المحدّث في أقرب وقت ممكن للمستخدمين.
- إذا كنت تستخدم أذونات مخصّصة في تطبيقك، يُرجى مراعاة مصدرها
وما إذا كنت بحاجة إليها فعلاً. أزِل جميع عناصر
<permission>من تطبيقك، ما لم تكن متأكدًا من أنّها مطلوبة لتشغيل تطبيقك على نحو سليم. - ننصحك باستبدال الأذونات المخصّصة بأذونات تلقائية للنظام متى أمكن.
- إذا كان تطبيقك يتطلّب أذونات مخصّصة، يجب إعادة تسمية أذوناتك المخصّصة لتصبح فريدة لتطبيقك، مثلاً من خلال إلحاقها باسم الحزمة الكامل لتطبيقك.
- إذا كانت لديك مجموعة من التطبيقات موقَّعة باستخدام مفاتيح مختلفة وكانت التطبيقات
تصل إلى مكوّن مشترك باستخدام إذن مخصّص، تأكَّد من تحديد
الإذن المخصّص مرة واحدة فقط في المكوِّن المشترَك. يجب ألا تحدّد التطبيقات التي
تستخدم المكوِّن المشترك الإذن المخصّص بنفسها،
ولكن يجب أن تطلب الوصول من خلال آلية
<uses-permission>بدلاً من ذلك. - إذا كانت لديك مجموعة من التطبيقات موقَّعة باستخدام المفتاح نفسه، يمكن لكل تطبيق تحديد الأذونات المخصَّصة نفسها حسب الحاجة إلى أنّ النظام يسمح بتثبيت التطبيقات بالطريقة المعتادة.
تغييرات الإعدادات التلقائية لطبقة النقل الآمنة/طبقة المقابس الآمنة
يقدم Android 5.0 تغييرات في الإعدادات التلقائية لبروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة التي تستخدمها التطبيقات لعدد زيارات HTTPS وحركة بيانات طبقة النقل الآمنة (TLS)/طبقة المقابس الآمنة الأخرى:
- تم تفعيل بروتوكول TLSv1.2 وTLSv1.1 الآن،
- مجموعات رموز AES-GCM (AEAD) مفعّلة الآن،
- تم الآن إيقاف مجموعات رموز MD5 و3DES والتصدير وتشفير ECDH للمفتاح الثابت،
- يُفضَّل استخدام مجموعات رموز السرية الأمامية (ECDHE وDHE).
قد تؤدي هذه التغييرات إلى حدوث أعطال في اتصال HTTPS أو بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) في عدد قليل من الحالات الواردة أدناه.
وتجدر الإشارة إلى أن مقدم خدمات الأمان من "خدمات Google Play" يعرض هذه التغييرات حاليًا في جميع إصدارات نظام Android الأساسي للرجوع إلى الإصدار 2.3 من Android.
لا يتيح الخادم أي مجموعة من مجموعات الرموز المفعّلة.
على سبيل المثال، قد يدعم الخادم مجموعات رموز خوارزمية الترميز 3DES أو MD5 فقط. والحلّ المفضّل هو تحسين إعدادات الخادم لتفعيل مجموعات رموز وبروتوكولات ترميز أقوى وأحدث. من الناحية المثالية، يجب تفعيل TLSv1.2 وAES-GCM وتفعيل مجموعات رموز "إعادة توجيه السرية" (ECDHE، وDHE) وتفضيلها.
ويمكنك بدلاً من ذلك تعديل التطبيق لاستخدام SSLSocketتصنيع مخصَّص للتواصل مع الخادم. يجب أن يتم تصميم المصنع لإنشاء مثيلات SSLSocket التي تتضمن بعض مجموعات الرموز التي يطلبها الخادم بالإضافة إلى مجموعات الرموز التلقائية.
التطبيق يضع افتراضات خاطئة حول مجموعات الرموز المستخدمة للاتصال بالخادم
على سبيل المثال، تحتوي بعض التطبيقات على X509TrustManager المخصّص الذي يتعطل لأنّه يتوقع أن تكون مَعلمة authType RSA، ولكنّها تواجه ECDHE_RSA أو DHE_RSA.
الخادم لا يسمح بإضافات TLSv1.1 أو TLSv1.2 أو إضافات TLS الجديدة
على سبيل المثال، تم رفض تأكيد اتصال بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة مع الخادم عن طريق الخطأ أو يتم إيقاف هذه العملية عن طريق الخطأ. الحل المفضّل هو ترقية الخادم ليتوافق مع بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL). وسيؤدي ذلك إلى جعل الخادم يتفاوض بنجاح بين هذه البروتوكولات الأحدث أو يتفاوض بشأن بروتوكول TLSv1 أو البروتوكولات الأقدم ويتجاهل إضافات بروتوكول أمان طبقة النقل (TLS) التي لا يفهمها. في بعض الحالات، قد يتم إيقاف TLSv1.1 وTLSv1.2 على الخادم كإجراء مؤقت إلى أن تتم ترقية برنامج الخادم.
ويمكنك بدلاً من ذلك تعديل التطبيق لاستخدام SSLSocketتصنيع مخصَّص للتواصل مع الخادم. يجب أن يتم تصميم المصنع لإنشاء مثيلات طبقة المقابس الآمنة (SSLSocket) مع تفعيل البروتوكولات التي تتوافق مع الخادم بشكل صحيح.
إتاحة الملفات الشخصية المُدارة
يمكن لمشرفي الجهاز إضافة ملف شخصي مُدار إلى الجهاز. ويملك المشرف هذا الملف الشخصي، ما يمنحه إمكانية التحكم في الملف الشخصي المُدار، مع ترك الملف الشخصي للمستخدم ومساحة التخزين الخاصة به تحت سيطرة المستخدم. يمكن أن يؤثر هذا التغيير في سلوك تطبيقك الحالي بالطرق التالية.
التعامل مع الأهداف
ويمكن لمشرفي الجهاز تقييد الوصول إلى تطبيقات النظام من
الملف الشخصي المُدار. في هذه الحالة، إذا أطلق تطبيق هدفًا من الملف الشخصي المُدار الذي يعالجه هذا التطبيق عادةً، ولا يتوفّر معالج مناسب للغرض في الملف الشخصي المُدار،
يسبّب الغرض استثناءً. على سبيل المثال، يمكن لمشرف الجهاز منع التطبيقات في الملف الشخصي المُدار من الوصول إلى تطبيق الكاميرا للنظام. إذا كان تطبيقك يعمل في الملف الشخصي المُدار
وتستدعى الرقم startActivityForResult() لصالح MediaStore.ACTION_IMAGE_CAPTURE، ولا يتوفّر أي تطبيق في الملف الشخصي المُدار
يمكنه التعامل مع الغرض، سيؤدي ذلك إلى ظهور ActivityNotFoundException.
يمكنك منع ذلك عن طريق التحقق من وجود معالج واحد على الأقل لأي غرض
قبل تنشيطه. للتحقق من وجود معالج صالح، يمكنك استدعاء Intent.resolveActivity(). يمكنك الاطّلاع على مثال لتنفيذ ذلك في القسم التقاط صور
ببساطة: التقاط صورة باستخدام تطبيق الكاميرا.
مشاركة الملفات بين الملفات الشخصية
لكل ملف شخصي مساحة تخزين خاصة به للملفات. ونظرًا لأن معرف الموارد المنتظم (URI) للملف يشير إلى موقع معين في تخزين الملفات، فهذا يعني أن معرف الموارد المنتظم (URI) للملف الشخصي غير صالح على الملف الشخصي الآخر. لا تُعد هذه في العادة مشكلة بالنسبة إلى التطبيق، الذي لا يصل عادةً إلى الملفات التي ينشئها سوى. ومع ذلك، إذا أرفق أحد التطبيقات ملفًا في هدف، فليس من الآمن إرفاق معرّف URI للملف، لأنه في بعض الحالات، قد يتم التعامل مع الغرض على الملف الشخصي الآخر. على سبيل المثال، قد يحدد مشرف الجهاز أن أحداث التقاط الصور يجب التعامل معها بواسطة تطبيق الكاميرا في الملف الشخصي. إذا تم تنشيط الغرض من خلال تطبيق في الملف الشخصي المُدار، يجب أن تكون الكاميرا قادرة على كتابة الصورة في موقع يمكن لتطبيقات الملف الشخصي المُدار قراءته.
حرصًا على الأمان، عندما تحتاج إلى إرفاق ملف ببنية قد تعبر من ملف شخصي إلى ملف آخر، يجب إنشاء واستخدام معرّف الموارد المنتظم (URI) للمحتوى للملف. لمزيد من المعلومات حول مشاركة الملفات باستخدام معرفات الموارد المنتظمة (URI) للمحتوى، راجع مشاركة الملفات.
على سبيل المثال، قد يسمح مشرف الجهاز بمعالجة ACTION_IMAGE_CAPTURE من خلال الكاميرا في الملف الشخصي. يجب أن يحتوي EXTRA_OUTPUT لغرض التنشيط على معرّف موارد منتظم (URI)
للمحتوى يحدد مكان تخزين الصورة. يستطيع تطبيق الكاميرا كتابة الصورة في الموقع المحدد من خلال معرف الموارد المنتظم (URI) هذا، وسيتمكن التطبيق الذي أطلق الغرض من قراءة هذا الملف، حتى إذا كان التطبيق في الملف الشخصي الآخر.
تمت إزالة دعم التطبيق المصغّر لشاشة القفل.
يلغي Android 5.0 التوافق مع التطبيقات المصغّرة لشاشة القفل، ويواصل إتاحة الأدوات على الشاشة الرئيسية.