تغییرات رفتار اندروید 5.0

سطح API: 21

اندروید 5.0 همراه با ویژگی ها و قابلیت های جدید، شامل تغییرات سیستمی و تغییرات رفتاری API می شود. این سند برخی از تغییرات کلیدی را که باید درک کنید و در برنامه‌هایتان حساب کنید، برجسته می‌کند.

اگر قبلاً برنامه‌ای برای اندروید منتشر کرده‌اید، توجه داشته باشید که ممکن است برنامه شما تحت تأثیر این تغییرات در Android 5.0 قرار گیرد.

برای نگاهی سطح بالا به ویژگی‌های پلتفرم جدید، به جای آن به نکات برجسته Android Lollipop مراجعه کنید.

ویدیوها

Dev Byte: چیزهای جدید در اندروید 5.0

Dev Byte: اعلان ها

Android Runtime (ART)

در اندروید 5.0، زمان اجرا ART جایگزین Dalvik به عنوان پیش فرض پلتفرم می شود. زمان اجرا ART در اندروید 4.4 به صورت آزمایشی معرفی شد.

برای مروری بر ویژگی‌های جدید ART، به معرفی ART مراجعه کنید. برخی از مهمترین ویژگی های جدید عبارتند از:

• تدوین پیش از زمان (AOT).
• بهبود جمع آوری زباله (GC)
• پشتیبانی از اشکال زدایی بهبود یافته

اکثر برنامه های اندروید باید بدون هیچ تغییری تحت ART کار کنند. با این حال، برخی از تکنیک هایی که روی Dalvik کار می کنند، روی ART کار نمی کنند. برای کسب اطلاعات در مورد مهمترین مسائل، به تأیید رفتار برنامه در زمان اجرای Android (ART) مراجعه کنید. توجه ویژه ای داشته باشید اگر:

• برنامه شما از رابط بومی جاوا (JNI) برای اجرای کد C/C++ استفاده می‌کند.
• شما از ابزارهای توسعه ای استفاده می کنید که کدهای غیر استاندارد تولید می کنند (مانند برخی از مبهم ها).
• شما از تکنیک هایی استفاده می کنید که با جمع آوری زباله های فشرده ناسازگار است.

اطلاعیه ها

مطمئن شوید که اعلان‌های شما این تغییرات اندروید ۵.۰ را در نظر گرفته است. برای کسب اطلاعات بیشتر در مورد طراحی اعلان‌های خود برای 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 کنترل می‌شود.

قابلیت رویت صفحه قفل

به طور پیش فرض، اعلان ها اکنون در صفحه قفل کاربر در اندروید 5.0 ظاهر می شوند. کاربران می توانند انتخاب کنند که از اطلاعات حساس در برابر افشا شدن محافظت کنند، در این صورت سیستم به طور خودکار متن نمایش داده شده توسط اعلان را ویرایش می کند. برای سفارشی کردن این اعلان ویرایش شده، از setPublicVersion() استفاده کنید.

اگر اعلان حاوی اطلاعات شخصی نیست، یا اگر می‌خواهید امکان کنترل پخش رسانه در اعلان را فراهم کنید، روش setVisibility() را فراخوانی کنید و سطح نمایان بودن اعلان را روی VISIBILITY_PUBLIC تنظیم کنید.

پخش رسانه

اگر اعلان‌هایی را اجرا می‌کنید که وضعیت پخش رسانه یا کنترل‌های انتقال را ارائه می‌دهند، به جای یک شی RemoteViews.RemoteView ، از الگوی جدید Notification.MediaStyle استفاده کنید. هر رویکردی را که انتخاب می‌کنید، مطمئن شوید که قابلیت مشاهده اعلان را روی VISIBILITY_PUBLIC تنظیم کرده‌اید تا کنترل‌های شما از صفحه قفل قابل دسترسی باشد. توجه داشته باشید که با شروع اندروید 5.0، سیستم دیگر اشیاء RemoteControlClient را در صفحه قفل نشان نمی دهد. برای اطلاعات بیشتر، ببینید آیا برنامه شما از RemoteControlClient استفاده می کند .

اطلاعیه سرآغاز

وقتی دستگاه فعال است (یعنی قفل دستگاه باز است و صفحه نمایش آن روشن است)، اعلان ها ممکن است اکنون در یک پنجره کوچک شناور ظاهر شوند (که به آن اعلان heads-up نیز گفته می شود). این اعلان‌ها شبیه به شکل فشرده اعلان شما به نظر می‌رسند، با این تفاوت که اعلان heads-up دکمه‌های عمل را نیز نشان می‌دهد. کاربران می‌توانند بدون خروج از برنامه فعلی، روی یک اعلان heads-up عمل کنند یا آن را رد کنند.

نمونه‌هایی از شرایطی که ممکن است باعث ایجاد اعلان‌های هدآپ شوند عبارتند از:

• فعالیت کاربر در حالت تمام صفحه است (برنامه از fullScreenIntent استفاده می کند)
• اعلان دارای اولویت بالایی است و از آهنگ های زنگ یا لرزش استفاده می کند

اگر برنامه شما اعلان‌ها را تحت هر یک از این سناریوها پیاده‌سازی می‌کند، مطمئن شوید که اعلان‌های heads-up به درستی ارائه شده‌اند.

کنترل رسانه و RemoteControlClient

کلاس RemoteControlClient اکنون منسوخ شده است. در اسرع وقت به MediaSession API جدید بروید.

صفحه‌های قفل در Android 5.0 کنترل‌های انتقال را برای MediaSession یا RemoteControlClient شما نشان نمی‌دهند. در عوض، برنامه شما می‌تواند از طریق یک اعلان، کنترل پخش رسانه را از صفحه قفل ارائه کند. این به برنامه شما کنترل بیشتری بر روی نمایش دکمه‌های رسانه می‌دهد و در عین حال تجربه‌ای ثابت برای کاربران در دستگاه‌های قفل‌شده و قفل‌شده ارائه می‌دهد.

اندروید 5.0 یک قالب جدید Notification.MediaStyle را برای این منظور معرفی می کند. Notification.MediaStyle اقدامات اعلان‌هایی را که با Notification.Builder.addAction() اضافه کرده‌اید به دکمه‌های فشرده‌ای که در اعلان‌های پخش رسانه برنامه‌تان تعبیه شده است، تبدیل می‌کند. رمز جلسه خود را به متد setSession() ارسال کنید تا به سیستم اطلاع دهید که این اعلان یک جلسه رسانه در حال انجام را کنترل می کند.

مطمئن شوید که قابلیت مشاهده اعلان را روی VISIBILITY_PUBLIC تنظیم کرده اید تا اعلان را به عنوان ایمن برای نمایش در هر صفحه قفل (ایمن یا غیر ایمن) علامت گذاری کنید. برای اطلاعات بیشتر، به اعلان‌های صفحه قفل مراجعه کنید.

اگر برنامه شما در Android TV یا Wear در حال اجرا است، برای نمایش کنترل‌های پخش رسانه، کلاس MediaSession را اجرا کنید. اگر برنامه شما نیاز به دریافت رویدادهای دکمه رسانه در دستگاه‌های اندرویدی دارد، باید MediaSession نیز پیاده‌سازی کنید.

getRecentTasks()

با معرفی ویژگی جدید اسناد همزمان و وظایف فعالیت‌ها در Android 5.0 (به اسناد و فعالیت‌های همزمان در صفحه اخیر زیر مراجعه کنید)، روش ActivityManager.getRecentTasks() اکنون برای بهبود حریم خصوصی کاربر منسوخ شده است. برای سازگاری با عقب، این روش هنوز هم زیر مجموعه کوچکی از داده های خود، از جمله وظایف خود برنامه فراخوانی و احتمالاً برخی از وظایف غیر حساس دیگر (مانند Home) را برمی گرداند. اگر برنامه شما از این روش برای بازیابی وظایف خود استفاده می کند، به جای آن از getAppTasks() برای بازیابی آن اطلاعات استفاده کنید.

پشتیبانی 64 بیتی در اندروید NDK

اندروید 5.0 از سیستم های 64 بیتی پشتیبانی می کند. بهبود 64 بیتی فضای آدرس را افزایش می دهد و عملکرد را بهبود می بخشد، در حالی که همچنان از برنامه های 32 بیتی موجود به طور کامل پشتیبانی می کند. پشتیبانی 64 بیتی همچنین عملکرد OpenSSL را برای رمزنگاری بهبود می بخشد. علاوه بر این، این نسخه APIهای NDK رسانه های بومی جدید و همچنین پشتیبانی بومی OpenGL ES (GLES) 3.1 را معرفی می کند.

برای استفاده از پشتیبانی 64 بیتی ارائه شده در اندروید 5.0، نسخه NDK 10c را از صفحه Android NDK دانلود و نصب کنید. برای اطلاعات بیشتر در مورد تغییرات مهم و رفع اشکال در NDK، به یادداشت‌های انتشار نسخه 10c مراجعه کنید.

اتصال به یک سرویس

متد Context.bindService() اکنون به یک Intent صریح نیاز دارد و اگر یک intent ضمنی به آن داده شود یک استثنا ایجاد می کند. برای اطمینان از ایمن بودن برنامه خود، هنگام شروع یا اتصال Service خود از یک هدف صریح استفاده کنید و فیلترهای هدف را برای سرویس اعلام نکنید.

WebView

Android 5.0 رفتار پیش‌فرض برنامه شما را تغییر می‌دهد.

• اگر برنامه شما سطح API 21 یا بالاتر را هدف قرار می دهد:
  • سیستم به طور پیش فرض محتوای ترکیبی و کوکی های شخص ثالث را مسدود می کند. برای مجاز کردن محتوای ترکیبی و کوکی‌های شخص ثالث، به ترتیب از متدهای setMixedContentMode() و setAcceptThirdPartyCookies() استفاده کنید.
  • اکنون سیستم به صورت هوشمند بخش هایی از سند HTML را برای ترسیم انتخاب می کند. این رفتار پیش فرض جدید به کاهش ردپای حافظه و افزایش عملکرد کمک می کند. اگر می‌خواهید کل سند را به یکباره رندر کنید، این بهینه‌سازی را با فراخوانی enableSlowWholeDocumentDraw() غیرفعال کنید.
• اگر برنامه شما سطوح API کمتر از 21 را هدف قرار می‌دهد: سیستم محتوای ترکیبی و کوکی‌های شخص ثالث را مجاز می‌کند و همیشه کل سند را به یکباره ارائه می‌کند.

الزامات منحصر به فرد برای مجوزهای سفارشی

همانطور که در نمای کلی مجوزها مستند شده است، برنامه های Android می توانند مجوزهای سفارشی را به عنوان ابزاری برای مدیریت دسترسی به اجزاء به روشی اختصاصی، بدون استفاده از مجوزهای سیستمی از پیش تعریف شده پلت فرم تعریف کنند. برنامه ها مجوزهای سفارشی را در عناصر <permission> اعلام شده در فایل های مانیفست خود تعریف می کنند.

تعداد کمی از سناریوها وجود دارد که در آن تعریف مجوزهای سفارشی یک رویکرد قانونی و ایمن است. با این حال، ایجاد مجوزهای سفارشی گاهی اوقات غیر ضروری است و بسته به سطح حفاظتی که به مجوزها اختصاص داده می شود، حتی می تواند خطرات احتمالی را برای یک برنامه ایجاد کند.

Android 5.0 شامل یک تغییر رفتار است تا اطمینان حاصل شود که فقط یک برنامه می‌تواند مجوز سفارشی معین را تعریف کند، مگر اینکه با کلیدی مشابه با سایر برنامه‌هایی که مجوز را تعیین می‌کنند امضا شده باشد.

برنامه هایی که از مجوزهای سفارشی تکراری استفاده می کنند

هر برنامه‌ای می‌تواند هر مجوز سفارشی را که می‌خواهد تعریف کند، بنابراین ممکن است چندین برنامه یک مجوز سفارشی را تعریف کنند . به عنوان مثال، اگر دو برنامه قابلیت مشابهی را ارائه دهند، ممکن است نام منطقی یکسانی را برای مجوزهای سفارشی خود دریافت کنند. برنامه‌ها همچنین ممکن است کتابخانه‌های عمومی رایج یا نمونه‌های کدی را که خود شامل همان تعاریف مجوز سفارشی می‌شوند، ترکیب کنند.

در اندروید 4.4 و نسخه‌های قبلی، کاربران می‌توانستند چندین برنامه از این قبیل را روی یک دستگاه معین نصب کنند، اگرچه سیستم سطح حفاظتی را که توسط اولین برنامه نصب‌شده مشخص شده بود، اختصاص می‌داد.

با شروع اندروید 5.0، سیستم محدودیت منحصر به فرد جدیدی را در مجوزهای سفارشی برای برنامه هایی که با کلیدهای مختلف امضا شده اند اعمال می کند. اکنون فقط یک برنامه در یک دستگاه می‌تواند یک مجوز سفارشی معین (که با نام آن مشخص می‌شود) تعریف کند، مگر اینکه برنامه دیگری که مجوز را تعریف می‌کند با همان کلید امضا شده باشد. اگر کاربر سعی کند برنامه ای را با مجوز سفارشی تکراری نصب کند و با همان کلید برنامه مقیمی که مجوز را تعریف می کند امضا نشود، سیستم نصب را مسدود می کند.

ملاحظاتی برای برنامه شما

در Android نسخه 5.0 و جدیدتر، برنامه‌ها می‌توانند مانند گذشته مجوزهای سفارشی خود را تعریف کنند و از طریق مکانیسم <uses-permission> از سایر برنامه‌ها مجوزهای سفارشی درخواست کنند. با این حال، با نیاز جدید معرفی شده در اندروید 5.0، باید تأثیرات احتمالی روی برنامه خود را به دقت ارزیابی کنید.

در اینجا چند نکته وجود دارد که باید در نظر گرفته شود:

• آیا برنامه شما عناصر <permission> را در مانیفست خود اعلام می کند؟ اگر چنین است، آیا آنها واقعاً برای عملکرد مناسب برنامه یا سرویس شما ضروری هستند؟ یا می توانید به جای آن از یک مجوز پیش فرض سیستم استفاده کنید؟
• اگر عناصر <permission> در برنامه خود دارید، آیا می دانید از کجا آمده اند؟
• آیا واقعاً قصد دارید که سایر برنامه‌ها مجوزهای سفارشی شما را از طریق <uses-permission> درخواست کنند؟
• آیا از boilerplate یا کد نمونه ای در برنامه خود استفاده می کنید که شامل عناصر <permission> است؟ آیا آن عناصر مجوز واقعا ضروری هستند؟
• آیا مجوزهای سفارشی شما از نام‌هایی استفاده می‌کنند که ساده یا مبتنی بر اصطلاحات رایجی هستند که سایر برنامه‌ها ممکن است به اشتراک بگذارند؟

نصب ها و به روز رسانی های جدید

همانطور که در بالا ذکر شد، برای نصب‌ها و به‌روزرسانی‌های جدید برنامه شما در دستگاه‌های دارای اندروید 4.4 یا نسخه‌های قدیمی‌تر تأثیری نمی‌گذارد و هیچ تغییری در رفتار وجود ندارد. برای نصب‌ها و به‌روزرسانی‌های جدید در دستگاه‌های دارای Android نسخه 5.0 یا بالاتر، اگر یک مجوز سفارشی که قبلاً توسط یک برنامه مقیم موجود تعریف شده باشد، سیستم از نصب برنامه شما جلوگیری می‌کند .

نصب‌های موجود با به‌روزرسانی سیستم Android 5.0

اگر برنامه شما از مجوزهای سفارشی استفاده می کند و به طور گسترده توزیع و نصب شده است، این احتمال وجود دارد که وقتی کاربران دستگاه های خود را به Android 5.0 به روز می کنند، تحت تأثیر قرار گیرد. پس از نصب به‌روزرسانی سیستم، سیستم برنامه‌های نصب‌شده را از جمله مجوزهای سفارشی آنها را بررسی می‌کند. اگر برنامه شما یک مجوز سفارشی تعریف می کند که قبلاً توسط برنامه دیگری که قبلاً تأیید شده است تعریف شده است و برنامه شما با همان کلید برنامه دیگر امضا نشده است، سیستم برنامه شما را مجدداً نصب نمی کند .

توصیه ها

در دستگاه‌های دارای Android نسخه 5.0 یا بالاتر، توصیه می‌کنیم فوراً برنامه خود را بررسی کنید، تنظیمات لازم را انجام دهید و نسخه به‌روز شده را در اسرع وقت برای کاربران خود منتشر کنید.

• اگر از مجوزهای سفارشی در برنامه خود استفاده می کنید، منشا آنها و اینکه آیا واقعاً به آنها نیاز دارید را در نظر بگیرید. همه عناصر <permission> را از برنامه خود حذف کنید، مگر اینکه مطمئن باشید که برای عملکرد مناسب برنامه شما لازم است.
• در صورت امکان، مجوزهای سفارشی خود را با مجوزهای پیش فرض سیستم جایگزین کنید.
• اگر برنامه شما به مجوزهای سفارشی نیاز دارد، نام مجوزهای سفارشی خود را به گونه ای تغییر دهید که برای برنامه شما منحصر به فرد باشد، مثلاً آنها را به نام بسته کامل برنامه خود اضافه کنید.
• اگر مجموعه‌ای از برنامه‌ها را دارید که با کلیدهای مختلف امضا شده‌اند و برنامه‌ها با استفاده از مجوز سفارشی به یک مؤلفه مشترک دسترسی دارند، مطمئن شوید که مجوز سفارشی فقط یک بار در مؤلفه مشترک تعریف شده است. برنامه‌هایی که از مؤلفه مشترک استفاده می‌کنند نباید مجوز سفارشی را خودشان تعریف کنند، بلکه باید از طریق مکانیسم <uses-permission> دسترسی را درخواست کنند.
• اگر مجموعه‌ای از برنامه‌ها را دارید که با یک کلید امضا شده‌اند ، هر برنامه می‌تواند همان مجوز(های) سفارشی را در صورت نیاز تعریف کند - سیستم اجازه می‌دهد برنامه‌ها به روش معمول نصب شوند.

تغییرات پیکربندی پیش فرض TLS/SSL

Android 5.0 تغییراتی را در پیکربندی پیش‌فرض TLS/SSL که توسط برنامه‌ها برای HTTPS و سایر ترافیک TLS/SSL استفاده می‌شود، معرفی می‌کند:

• پروتکل های TLSv1.2 و TLSv1.1 اکنون فعال هستند،
• مجموعه رمزهای AES-GCM (AEAD) اکنون فعال هستند،
• مجموعه‌های رمزگذاری MD5، 3DES، صادرات و کلید استاتیک ECDH اکنون غیرفعال شده‌اند،
• مجموعه‌های رمزنگاری Forward Secrecy (ECDHE و DHE) ترجیح داده می‌شوند.

این تغییرات ممکن است منجر به شکستگی در اتصال HTTPS یا TLS/SSL در تعداد کمی از موارد ذکر شده در زیر شود.

توجه داشته باشید که ProviderInstaller امنیتی از سرویس‌های Google Play در حال حاضر این تغییرات را در سراسر نسخه‌های پلتفرم Android به Android 2.3 ارائه می‌دهد.

سرور از هیچ یک از مجموعه رمزهای فعال پشتیبانی نمی کند

به عنوان مثال، یک سرور ممکن است تنها مجموعه رمزهای 3DES یا MD5 را پشتیبانی کند. راه حل ترجیحی بهبود پیکربندی سرور برای فعال کردن مجموعه‌ها و پروتکل‌های رمز قوی‌تر و مدرن‌تر است. در حالت ایده‌آل، TLSv1.2 و AES-GCM باید فعال باشند، و مجموعه‌های رمز محرمانه پیشرو (ECDHE، DHE) باید فعال و ترجیح داده شوند.

یک جایگزین این است که برنامه را تغییر دهید تا از یک SSLSocketFactory سفارشی برای برقراری ارتباط با سرور استفاده کنید. کارخانه باید به گونه‌ای طراحی شود که نمونه‌های SSLSocket را ایجاد کند که علاوه بر مجموعه‌های رمز پیش‌فرض، برخی از مجموعه‌های رمز مورد نیاز سرور را فعال کنند.

برنامه در مورد مجموعه های رمزی که برای اتصال به سرور استفاده می شود، فرضیات اشتباهی ایجاد می کند

به عنوان مثال، برخی از برنامه‌ها حاوی یک X509TrustManager سفارشی هستند که خراب می‌شود زیرا انتظار دارد پارامتر authType RSA باشد اما با ECDHE_RSA یا DHE_RSA مواجه می‌شود.

سرور نسبت به پسوندهای TLSv1.1، TLSv1.2 یا TLS جدید تحمل ندارد

به عنوان مثال، دست دادن TLS/SSL با یک سرور به اشتباه رد می شود یا متوقف می شود. راه حل ترجیحی ارتقای سرور برای مطابقت با پروتکل TLS/SSL است. این باعث می‌شود سرور با موفقیت در مورد پروتکل‌های جدیدتر مذاکره کند یا پروتکل‌های TLSv1 یا قدیمی‌تر را مذاکره کند و پسوندهای TLS را که نمی‌فهمد نادیده بگیرد. در برخی موارد، غیرفعال کردن TLSv1.1 و TLSv1.2 در سرور ممکن است تا زمانی که نرم‌افزار سرور ارتقا داده نشود، به عنوان یک معیار توقف عمل کند.

یک جایگزین این است که برنامه را تغییر دهید تا از یک SSLSocketFactory سفارشی برای برقراری ارتباط با سرور استفاده کنید. کارخانه باید طوری طراحی شود که نمونه‌های SSLSocket را تنها با پروتکل‌هایی فعال کند که به درستی توسط سرور پشتیبانی می‌شوند.

پشتیبانی از پروفایل های مدیریت شده

سرپرستان دستگاه می توانند نمایه مدیریت شده را به دستگاه اضافه کنند. این نمایه متعلق به مدیر است و به سرپرست کنترل نمایه مدیریت شده را می دهد در حالی که نمایه شخصی کاربر و فضای ذخیره سازی آن را تحت کنترل کاربر می گذارد. این تغییر می تواند رفتار برنامه موجود شما را به روش های زیر تحت تاثیر قرار دهد.

رسیدگی به مقاصد

مدیران دستگاه می توانند دسترسی به برنامه های سیستم را از نمایه مدیریت شده محدود کنند. در این حالت، اگر برنامه‌ای یک intent از نمایه مدیریت‌شده شلیک کند که معمولاً توسط آن برنامه مدیریت می‌شود، و کنترل‌کننده مناسبی برای intent در نمایه مدیریت‌شده وجود نداشته باشد، intent باعث ایجاد استثنا می‌شود. به عنوان مثال، سرپرست دستگاه می تواند برنامه های موجود در نمایه مدیریت شده را از دسترسی به برنامه دوربین سیستم محدود کند. اگر برنامه شما روی نمایه مدیریت‌شده اجرا می‌شود و startActivityForResult() را برای MediaStore.ACTION_IMAGE_CAPTURE فراخوانی می‌کند، و هیچ برنامه‌ای در نمایه مدیریت‌شده وجود ندارد که بتواند هدف را مدیریت کند، این منجر به ActivityNotFoundException می‌شود.

می توانید با بررسی اینکه حداقل یک کنترل کننده برای هر هدفی قبل از شلیک آن وجود دارد، از این امر جلوگیری کنید. برای بررسی وجود یک کنترل کننده معتبر، Intent.resolveActivity() را فراخوانی کنید. می‌توانید نمونه‌ای از این کار را در Take Photos Simply: گرفتن عکس با برنامه دوربین مشاهده کنید.

اشتراک گذاری فایل ها در پروفایل ها

هر نمایه دارای حافظه فایل مخصوص به خود است. از آنجایی که یک فایل URI به مکان خاصی در ذخیره سازی فایل اشاره دارد، این بدان معناست که URI فایلی که در یک نمایه معتبر است، در نمایه دیگر معتبر نیست. این معمولاً برای یک برنامه مشکلی ایجاد نمی کند، زیرا معمولاً فقط به فایل هایی که ایجاد می کند دسترسی پیدا می کند. با این حال، اگر یک برنامه یک فایل را به یک intent ضمیمه کند، پیوست کردن یک فایل URI ایمن نیست، زیرا در برخی شرایط، این هدف ممکن است در نمایه دیگر مدیریت شود. به عنوان مثال، یک سرپرست دستگاه ممکن است تعیین کند که رویدادهای ضبط تصویر باید توسط برنامه دوربین در نمایه شخصی مدیریت شود. اگر هدف توسط برنامه ای در نمایه مدیریت شده شلیک شود، دوربین باید بتواند تصویر را در مکانی بنویسد که برنامه های نمایه مدیریت شده بتوانند آن را بخوانند.

برای ایمن بودن، زمانی که نیاز دارید فایلی را به intent پیوست کنید که ممکن است از نمایه ای به نمایه دیگر عبور کند، باید یک URI محتوا برای فایل ایجاد کرده و از آن استفاده کنید. برای اطلاعات بیشتر درباره اشتراک‌گذاری فایل‌ها با URI محتوا، به اشتراک‌گذاری فایل‌ها مراجعه کنید. برای مثال، سرپرست دستگاه ممکن است اجازه دهد ACTION_IMAGE_CAPTURE توسط دوربین در نمایه شخصی مدیریت شود. EXTRA_OUTPUT هدف شلیک باید حاوی یک URI محتوا باشد که محل ذخیره عکس را مشخص کند. برنامه دوربین می‌تواند تصویر را در مکان مشخص شده توسط آن URI بنویسد و برنامه‌ای که هدف را اجرا کرده می‌تواند آن فایل را بخواند، حتی اگر برنامه در نمایه دیگر باشد.

پشتیبانی ویجت صفحه قفل حذف شد

اندروید 5.0 پشتیبانی از ویجت های صفحه قفل را حذف می کند. همچنان از ویجت ها در صفحه اصلی پشتیبانی می کند.