مستوى واجهة برمجة التطبيقات: 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++.
- تستخدم أدوات تطوير تنشئ رمزًا غير عادي (مثل بعض أدوات التشويش).
- وتستخدم تقنيات غير متوافقة مع ضغط مجموعة البيانات غير المرغوب فيها.
الإشعارات
تأكد من أن إشعاراتك تأخذ هذه التغييرات في الإصدار 5.0 من Android في الاعتبار. للاطّلاع على مزيد من المعلومات حول تصميم الإشعارات لنظام التشغيل Android 5.0 والإصدارات الأحدث، يمكنك مراجعة دليل تصميم الإشعارات.
نمط التصميم المتعدد الأبعاد
يتم رسم الإشعارات بنص داكن فوق خلفيات بيضاء (أو فاتحة جدًا) لتتناسب مع التطبيقات المصغّرة الجديدة ذات التصميم المتعدد الأبعاد. احرص على أن تظهر جميع الإشعارات بالشكل الصحيح باستخدام نظام الألوان الجديد. إذا كانت إشعاراتك تبدو غير صحيحة، فقم بإصلاحها:
- يمكنك استخدام
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) - الإشعار ذو أولوية عالية ويستخدم نغمات الرنين أو الاهتزازات.
إذا كان تطبيقك ينفّذ الإشعارات في أي من هذه السيناريوهات، تأكَّد من عرض إشعارات التنبيه بشكل صحيح.
عناصر التحكّم في الوسائط وRemoteControlClient
تم الآن إيقاف الصف RemoteControlClient نهائيًا. يُرجى الانتقال إلى واجهة برمجة التطبيقات MediaSession الجديدة في أقرب وقت ممكن.
لا تعرض شاشات القفل في Android 5.0 عناصر التحكم في النقل
لجهاز MediaSession أو
RemoteControlClient. بدلاً من ذلك، يمكن لتطبيقك توفير إمكانية التحكم
في تشغيل الوسائط من شاشة القفل عبر الإشعار. يمنح ذلك تطبيقك مزيدًا من التحكّم في طريقة عرض أزرار الوسائط، مع توفير تجربة متّسقة للمستخدمين على الأجهزة المقفلة وغير المقفلة.
يقدّم Android 5.0 نموذج Notification.MediaStyle جديدًا لهذا الغرض.
يحوّل Notification.MediaStyle إجراءات الإشعارات التي أضفتها باستخدام Notification.Builder.addAction() إلى أزرار مكثّفة مضمّنة في إشعارات تشغيل الوسائط في تطبيقك. مرِّر الرمز المميّز للجلسة إلى طريقة
setSession() لإعلام النظام بأنّ هذا الإشعار يتحكّم في
جلسة وسائط جارية.
تأكَّد من ضبط إذن الوصول إلى الإشعار على
VISIBILITY_PUBLIC
لوضع علامة على الإشعار بأنّه آمن لعرضه على أي شاشة قفل (سواء كانت آمنة أو غير ذلك). لمزيد من المعلومات، يُرجى الاطّلاع على إشعارات شاشة القفل.
لعرض عناصر التحكّم في تشغيل الوسائط إذا كان تطبيقك يعمل على نظام
تلفزيون Android أو
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 من صفحة NDK على Android. يُرجى الرجوع إلى ملاحظات الإصدار المراجعة 10c للاطلاع على مزيد من المعلومات حول التغييرات المهمة وإصلاحات الأخطاء لـ NDK.
الالتزام بخدمة
تتطلّب الطريقة Context.bindService() الآن استخدام Intent صريحًا،
وتطرح استثناءً إذا تم تحديد نية ضمنية.
لضمان أمان تطبيقك، استخدِم هدفًا صريحًا عند بدء تشغيل Service أو ربطه، ولا تُفصح عن فلاتر الأهداف للخدمة.
WebView
يغيّر Android 5.0 السلوك التلقائي لتطبيقك.
- إذا كان تطبيقك يستهدف المستوى 21 أو أعلى لواجهة برمجة التطبيقات:
- يحظر النظام
المحتوى المختلَط وملفات تعريف الارتباط التابعة لجهات خارجية تلقائيًا. للسماح بالمحتوى المختلط وملفات تعريف الارتباط التابعة لجهات خارجية، استخدِم الطريقتَين
setMixedContentMode()وsetAcceptThirdPartyCookies()على التوالي. - يختار النظام بذكاء أجزاءً من مستند HTML لرسمها. يساعد هذا السلوك التلقائي الجديد في تقليل تأثير الذاكرة
وتحسين الأداء. إذا كنت تريد
عرض المستند بأكمله في آنٍ واحد، أوقِف هذا التحسين من خلال طلب
enableSlowWholeDocumentDraw().
- يحظر النظام
المحتوى المختلَط وملفات تعريف الارتباط التابعة لجهات خارجية تلقائيًا. للسماح بالمحتوى المختلط وملفات تعريف الارتباط التابعة لجهات خارجية، استخدِم الطريقتَين
- إذا كان تطبيقك يستهدف مستويات أقل من 21 لواجهة برمجة تطبيقات: يسمح النظام بالمحتوى المختلط وملفات تعريف الارتباط التابعة لجهات خارجية، ويعرض دائمًا المستند بأكمله دفعة واحدة.
شرط التفرد للأذونات المخصّصة
كما هو موثق في النظرة العامة على الأذونات،
يمكن لتطبيقات Android تحديد الأذونات المخصصة كوسيلة لإدارة الوصول إلى المكوّنات بطريقة ملكية، بدون استخدام أذونات النظام المحددة مسبقًا للنظام الأساسي. تحدِّد التطبيقات الأذونات المخصّصة في عناصر
<permission> الموضَّحة في ملفات البيان.
هناك عدد صغير من السيناريوهات التي يكون فيها تحديد الأذونات المخصّصة نهجًا مشروعًا وآمنًا. ومع ذلك، قد لا يكون إنشاء أذونات مخصّصة ضروريًا في بعض الأحيان، ويمكن أن يؤدي إلى مخاطر محتملة للتطبيق بناءً على مستوى الحماية المخصّص للأذونات.
يشتمل الإصدار Android 5.0 على تغيير في السلوك لضمان أنّ تطبيقًا واحدًا فقط يمكنه تحديد إذن مخصّص معيّن، ما لم يتم توقيعه باستخدام المفتاح نفسه الذي تستخدمه التطبيقات الأخرى التي تحدّد الإذن.
التطبيقات التي تستخدم أذونات مخصَّصة مكرّرة
يمكن لأي تطبيق تحديد أي إذن مخصّص يريده، لذلك قد تؤدي عدة تطبيقات إلى تحديد الإذن المخصّص نفسه. على سبيل المثال، إذا كان تطبيقان يوفّران إمكانية مماثلة، قد يشتقان الاسم المنطقي نفسه لأذوناتهما المخصّصة. وقد تتضمّن التطبيقات أيضًا مكتبات عامة شائعة أو أمثلة على الرموز البرمجية تتضمّن تعريفات الأذونات المخصّصة نفسها.
في نظام التشغيل Android 4.4 والإصدارات الأقدم، تمكّن المستخدمون من تثبيت عدة تطبيقات من هذا النوع على جهاز معيّن، إلا أنّ النظام قد تم ضبط مستوى الحماية الذي حدّده التطبيق الذي تم تثبيته لأول مرة.
بدءًا من نظام التشغيل Android 5.0، يفرض النظام قيودًا جديدة على الأذونات المخصّصة للتطبيقات التي تم توقيعها باستخدام مفاتيح مختلفة. أصبح الآن بإمكان تطبيق واحد فقط على الجهاز تحديد إذن مخصّص معيّن (على النحو الذي يتم تحديده من خلال اسمه)، إلا إذا كان التطبيق الآخر الذي يحدّد الإذن موقَّعًا باستخدام المفتاح نفسه. وإذا حاول المستخدم تثبيت تطبيق بإذن مخصَّص مكرّر ولم يتم توقيعه باستخدام المفتاح نفسه المستخدَم في التطبيق المحلي الذي يحدّد الإذن، سيحظر النظام عملية التثبيت.
اعتبارات تطبيقك
في نظام التشغيل Android 5.0 والإصدارات الأحدث، يمكن للتطبيقات مواصلة تحديد أذوناتها المخصّصة كما في السابق وطلب أذونات مخصّصة من التطبيقات الأخرى باستخدام آلية <uses-permission>. ومع ذلك، في ظل المتطلبات الجديدة التي تم توفيرها في Android 5.0، يجب تقييم التأثيرات المحتملة على تطبيقك بعناية.
إليك بعض النقاط التي يجب مراعاتها:
- هل يذكر تطبيقك أي عناصر
<permission>في ملف البيان؟ إذا كان الأمر كذلك، هل هي ضرورية فعلاً لأداء التطبيق أو الخدمة بشكل مناسب؟ أو يمكنك استخدام إذن تلقائي للنظام بدلاً من ذلك؟ - في حال توفُّر عناصر
<permission>في التطبيق، هل تعرف مصدر هذه العناصر؟ - هل تريد فعلاً أن تطلب التطبيقات الأخرى أذوناتك المخصّصة من خلال
<uses-permission>؟ - هل تستخدم نصًا نموذجيًا أو رمزًا برمجيًا كمثال في تطبيقك يتضمن عناصر
<permission>؟ هل عناصر الأذونات هذه ضرورية فعلاً؟ - هل تستخدم أذوناتك المخصّصة أسماءً بسيطة أو تستند إلى عبارات شائعة قد تشاركها تطبيقات أخرى؟
عمليات التثبيت والتحديثات الجديدة
كما ذكرنا أعلاه، لن تتأثر عمليات التثبيت الجديدة لتطبيقك وتحديثاته على الأجهزة التي تعمل بنظام التشغيل Android 4.4 أو الإصدارات الأقدم، ولم يحدث أي تغيير في السلوك. بالنسبة إلى عمليات التثبيت والتحديثات الجديدة على الأجهزة التي تعمل بالإصدار 5.0 من نظام التشغيل Android أو الإصدارات الأحدث، يمنع النظام تثبيت تطبيقك إذا كان يحدد إذنًا مخصّصًا سبق أن حدّده تطبيق حالي.
عمليات التثبيت الحالية التي تتضمّن تحديث نظام Android 5.0
إذا كان تطبيقك يستخدم أذونات مخصّصة ويتم توزيعه وتثبيته على نطاق واسع، من المُحتمَل أن يتأثر بذلك عندما يتلقّى المستخدمون تحديثًا لأجهزتهم إلى الإصدار Android 5.0. بعد تثبيت تحديث النظام، يعيد النظام التحقّق من التطبيقات المثبّتة، بما في ذلك التحقّق من الأذونات المخصّصة لها. إذا حدّد تطبيقك إذنًا مخصّصًا سبق أن تم تحديده من خلال تطبيق آخر سبق وتم التحقّق منه، ولم يتم توقيع تطبيقك باستخدام مفتاح التطبيق الآخر، لن يُعيد النظام تثبيت تطبيقك.
الفيديوهات المقترَحة
على الأجهزة التي تعمل بالإصدار 5.0 من نظام التشغيل Android أو الإصدارات الأحدث، ننصحك بفحص تطبيقك فورًا وإجراء أي تعديلات مطلوبة ونشر الإصدار المحدَّث في أقرب وقت ممكن للمستخدمين.
- إذا كنت تستخدم أذونات مخصّصة في تطبيقك، يُرجى مراعاة مصدرها
وما إذا كنت بحاجة إليها فعلاً. أزِل جميع عناصر
<permission>من تطبيقك، ما لم تكن متأكّدًا من أنّها مطلوبة لأداء التطبيق بشكل مناسب. - ننصحك باستبدال الأذونات المخصّصة بأذونات تلقائية للنظام كلما أمكن.
- إذا كان تطبيقك يتطلّب أذونات مخصّصة، عليك إعادة تسمية الأذونات المخصَّصة لتصبح فريدة لتطبيقك، مثلاً من خلال إلحاقها باسم الحزمة الكاملة لتطبيقك.
- إذا كانت لديك مجموعة من التطبيقات موقَّعة باستخدام مفاتيح مختلفة وكانت التطبيقات
تصل إلى مكوِّن مشترك عن طريق إذن مخصّص، تأكَّد من تحديد
الإذن المخصّص مرة واحدة فقط في المكوِّن المشترَك. على التطبيقات التي تستخدم المكوِّن المشترَك ألا تحدِّد الإذن المخصّص بنفسها، بل يجب بدلاً من ذلك طلب الوصول من خلال آلية
<uses-permission>. - إذا كانت لديك حزمة من التطبيقات موقَّعة باستخدام المفتاح نفسه، يمكن لكل تطبيق تحديد الأذونات المخصَّصة نفسها اللازمة لأنّ النظام يسمح بتثبيت التطبيقات بالطريقة المعتادة.
تغييرات الإعدادات التلقائية لطبقة النقل الآمنة (TLS)/طبقة المقابس الآمنة (SSL)
يقدّم نظام التشغيل Android 5.0 تغييرات في الإعدادات التلقائية لطبقة النقل الآمنة (TLS)/طبقة المقابس الآمنة (SSL) التي تستخدمها التطبيقات لعدد زيارات بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL) الأخرى:
- تم تفعيل بروتوكولَي TLSv1.2 وTLSv1.1 الآن،
- تم تفعيل مجموعات رموز AES-GCM (AEAD) الآن،
- تم الآن إيقاف مجموعات تشفير MD5 و3DES والتصدير والمفتاح الثابت في ECDH،
- يُفضَّل استخدام مجموعات تشفير السرية الأمامية (ECDHE وDHE).
قد تؤدي هذه التغييرات إلى حدوث أعطال في اتصال HTTPS أو بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) في عدد قليل من الحالات المذكورة أدناه.
تجدر الإشارة إلى أنّ برنامج Security ProviderInstaller من "خدمات Google Play" يعرض هذه التغييرات في إصدارات نظام التشغيل Android الأساسيّة وصولاً إلى الإصدار 2.3 من Android.
لا يتوافق الخادم مع أي من مجموعات الرموز المفعَّلة.
على سبيل المثال، قد يدعم الخادم مجموعات رموز خوارزمية 3DES أو MD5 فقط. والحل المفضَّل هو تحسين ضبط الخادم لإتاحة مجموعات رموز وبروتوكولات أكثر تطوّرًا وأكثر حداثة. من الناحية المثالية، يجب تفعيل TLSv1.2 وAES-GCM، كما يجب تفعيل مجموعات رموز السرية لإعادة التوجيه (ECDHE وDHE) وتفضيلها.
كخيار بديل، يمكنك تعديل التطبيق لاستخدام طبقة المقابس الآمنة (SSLSocket أسعار) مخصَّصة للاتصال بالخادم. يجب تصميم المصنع لإنشاء مثيلات SSLSocket التي تحتوي على بعض مجموعات الرموز التي يتطلبها الخادم مفعّلة بالإضافة إلى مجموعات الرموز التلقائية.
يضع التطبيق افتراضات خاطئة حول مجموعات الرموز المستخدمة للاتصال بالخادم
على سبيل المثال، تحتوي بعض التطبيقات على دالة X509TrustManager مخصّصة لإيقافها لأنّها تتوقّع أن تكون مَعلمة authType هي RSA، ولكنّها ستصادف ECDHE_RSA أو DHE_RSA.
لا يقبل الخادم بروتوكول أمان طبقة النقل (TLS) الإصدار 1.1 أو الإصدار 1.2 من بروتوكول أمان طبقة النقل (TLS) أو إضافات بروتوكول أمان طبقة النقل (TLS) الجديدة.
على سبيل المثال، تم عن طريق الخطأ رفض تأكيد اتصال بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) مع أحد الخوادم أو يتم منعها عن طريق الخطأ. الحل المفضّل هو ترقية الخادم ليتوافق مع بروتوكول أمان طبقة النقل (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) هذا، وسيتمكن التطبيق الذي أطلق الهدف من قراءة هذا الملف، حتى إذا كان التطبيق في الملف الشخصي الآخر.
تمت إزالة إتاحة تطبيق شاشة القفل المصغّر.
يوقف الإصدار 5.0 من نظام التشغيل Android إمكانية استخدام تطبيقات مصغّرة لشاشة القفل، ويواصل إتاحة التطبيقات المصغّرة على الشاشة الرئيسية.