רמת API: 21
בנוסף לתכונות וליכולות חדשות, Android 5.0 כולל מגוון שינויים במערכת ושינויים בהתנהגות של ממשקי ה-API. במסמך הזה נסקור כמה מהשינויים העיקריים שצריך להבין ולקחת בחשבון באפליקציות שלכם.
אם פרסמתם בעבר אפליקציה ל-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 Native Interface (JNI) כדי להריץ קוד C/C++.
- אתם משתמשים בכלי פיתוח שיוצרים קוד לא סטנדרטי (כמו חלק מהמחשימים).
- אתם משתמשים בשיטות שלא תואמות לאיסוף אשפה דחוסה.
התראות
חשוב לוודא שההתראות שלכם מביאות בחשבון את השינויים האלה ב-Android 5.0. למידע נוסף על עיצוב התראות ל-Android 5.0 ואילך, קראו את המדריך לעיצוב התראות.
סגנון Material Design
ההתראות מוצגות עם טקסט כהה על רקע לבן (או בהיר מאוד) כדי להתאים לווידג'טים החדשים בעיצוב חומר. מוודאים שכל ההתראות נראות טוב עם ערכת הצבעים החדשה. אם ההתראות לא נראות כמו שצריך, אפשר לתקן אותן:
- משתמשים ב-
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 Controls ו-RemoteControlClient
הכיתה RemoteControlClient הוצאה משימוש. כדאי לעבור ל-API החדש של MediaSession בהקדם האפשרי.
במסכי הנעילה של Android 5.0 לא מוצגים לחצני התחבורה של MediaSession או RemoteControlClient. במקום זאת, האפליקציה יכולה לספק שליטה בהפעלת המדיה ממסך הנעילה באמצעות התראה. כך תוכלו לשלוט טוב יותר בהצגת לחצני המדיה באפליקציה, ועדיין לספק למשתמשים חוויה עקבית במכשירים נעולים ופתוח.
בגרסה 5.0 של Android נוספה תבנית חדשה בשם Notification.MediaStyle למטרה הזו.
Notification.MediaStyle ממירה פעולות התראות שהוספתם באמצעות Notification.Builder.addAction() ללחצנים קומפקטיים שמוטמעים בהתראות של האפליקציה לגבי הפעלת מדיה. מעבירים את אסימון הסשן לשיטה setSession() כדי להודיע למערכת שההתראה הזו קובעת את ההתנהגות של סשן מדיה מתמשך.
חשוב להגדיר את ההצגה של ההתראה כ-VISIBILITY_PUBLIC כדי לסמן שהיא בטוחה להצגה בכל מסך נעילה (מאובטח או לא). מידע נוסף זמין במאמר התראות במסך הנעילה.
כדי להציג את פקדי ההפעלה של המדיה אם האפליקציה פועלת בפלטפורמת TV או Wear של Android, צריך להטמיע את הכיתה MediaSession. צריך להטמיע את MediaSession גם אם האפליקציה צריכה לקבל אירועים של לחצני מדיה במכשירי Android.
getRecentTasks()
בעקבות ההשקה של התכונה החדשה משימות של מסמכים ופעילויות בו-זמנית ב-Android 5.0 (ראו מסמכים ופעילויות בו-זמנית במסך 'מה עשיתי לאחרונה' בהמשך), השיטה ActivityManager.getRecentTasks() הוצאה משימוש כדי לשפר את פרטיות המשתמשים. כדי לשמור על תאימות לאחור, השיטה הזו עדיין מחזירה קבוצת משנה קטנה של הנתונים שלה, כולל המשימות של האפליקציה הקוראת ואולי גם משימות אחרות שאינן רגישות (כמו Home). אם האפליקציה משתמשת בשיטה הזו כדי לאחזר את המשימות שלה, צריך להשתמש ב-getAppTasks() במקום זאת כדי לאחזר את המידע הזה.
תמיכה ב-64 ביט ב-Android NDK
בגרסה 5.0 של Android נוספה תמיכה במערכות 64 ביט. השיפורים בגרסת 64 ביט מגדילים את מרחב הכתובות ומשפרים את הביצועים, ועדיין תומכים באופן מלא באפליקציות קיימות של 32 ביט. התמיכה ב-64 ביט משפרת גם את הביצועים של OpenSSL לקריפטוגרפיה. בנוסף, בגרסה הזו נוספו ממשקי API חדשים של NDK לנתוני מדיה, וגם תמיכה מקורית ב-OpenGL ES (GLES) 3.1.
כדי להשתמש בתמיכה ב-64 ביט שזמינה ב-Android 5.0, מורידים ומתקינים את NDK Revision 10c מהדף של Android NDK. למידע נוסף על שינויים חשובים ותיקוני באגים ב-NDK, אפשר לעיין בהערות הגרסה של גרסה 10c.
כבילת שירות
השיטה Context.bindService() דורשת עכשיו Intent מפורש, ומציגה חריגה אם מקבלת כוונה משתמעת.
כדי להבטיח שהאפליקציה מאובטחת, צריך להשתמש בכוונה מפורשת כשמפעילים או מקשרים את ה-Service, ולא להצהיר על מסנני כוונה לשירות.
WebView
ב-Android 5.0 יש שינוי בהתנהגות ברירת המחדל של האפליקציה.
- אם האפליקציה שלכם מטרגטת לרמת API 21 ואילך:
- המערכת חוסמת כברירת מחדל תוכן מעורב וקובצי cookie של צד שלישי. כדי לאפשר תוכן מעורב וקובצי Cookie של צד שלישי, משתמשים בשיטות
setMixedContentMode()ו-setAcceptThirdPartyCookies(), בהתאמה. - עכשיו המערכת בוחרת באופן חכם את החלקים במסמך ה-HTML שאותם היא רוצה לצייר. התנהגות ברירת המחדל החדשה הזו עוזרת לצמצם את טביעת הרגל של הזיכרון ולשפר את הביצועים. אם רוצים להריץ רינדור של כל המסמך בבת אחת, צריך להשבית את האופטימיזציה הזו באמצעות קריאה ל-
enableSlowWholeDocumentDraw().
- המערכת חוסמת כברירת מחדל תוכן מעורב וקובצי cookie של צד שלישי. כדי לאפשר תוכן מעורב וקובצי Cookie של צד שלישי, משתמשים בשיטות
- אם האפליקציה מטרגטת רמות API נמוכות מ-21: המערכת מאפשרת תוכן מעורב וקובצי cookie של צד שלישי, ותמיד מבצעת עיבוד של המסמך כולו בבת אחת.
דרישת הייחודיות להרשאות בהתאמה אישית
כפי שמתואר במאמר הרשאות, אפליקציות ל-Android יכולות להגדיר הרשאות בהתאמה אישית כדי לנהל את הגישה לרכיבים באופן קנייני, בלי להשתמש בהרשאות המערכת שהוגדרו מראש בפלטפורמה. אפליקציות מגדירות הרשאות בהתאמה אישית ברכיבי
<permission> שמוצהרים בקובצי המניפסט שלהן.
יש מספר תרחישים מצומצם שבהם הגדרת הרשאות בהתאמה אישית היא גישה לגיטימית ומאובטחת. עם זאת, לפעמים אין צורך ליצור הרשאות בהתאמה אישית, והן עלולות אפילו להציג סיכון פוטנציאלי לאפליקציה, בהתאם לרמת ההגנה שהוקצה להרשאות.
ב-Android 5.0 יש שינוי בהתנהגות כדי לוודא שרק אפליקציה אחת יכולה להגדיר הרשאה מותאמת אישית נתונה, אלא אם היא חתומה על אותו מפתח כמו אפליקציות אחרות שמגדירות את ההרשאה.
אפליקציות שמשתמשות בהרשאות מותאמות אישית כפולות
כל אפליקציה יכולה להגדיר הרשאה מותאמת אישית לפי הצורך, כך שיכול להיות שכמה אפליקציות יגדירו את אותה הרשאה מותאמת אישית. לדוגמה, אם שתי אפליקציות מציעות יכולת דומה, יכול להיות שהן יפיקו את אותו שם לוגי להרשאות בהתאמה אישית. אפליקציות יכולות גם לכלול ספריות ציבוריות נפוצות או דוגמאות קוד שכוללות בעצמן את אותן הגדרות הרשאות בהתאמה אישית.
ב-Android 4.4 ובגרסאות קודמות, משתמשים יכלו להתקין כמה אפליקציות כאלה במכשיר נתון, אבל המערכת הקצתה את רמת ההגנה שצוינה באפליקציה הראשונה שהותקנה.
החל מגרסה 5.0 של Android, המערכת אוכפת הגבלה חדשה על ייחודיות של הרשאות בהתאמה אישית לאפליקציות שחתומות על ידי מפתחות שונים. עכשיו רק אפליקציה אחת במכשיר יכולה להגדיר הרשאה מותאמת אישית נתונה (לפי השם שלה), אלא אם האפליקציה האחרת שמגדירה את ההרשאה חתומה על ידי אותו מפתח. אם המשתמש מנסה להתקין אפליקציה עם הרשאה מותאמת אישית כפולה, והיא לא חתומה באותו מפתח כמו האפליקציה המקומית שמגדירה את ההרשאה, המערכת חוסמת את ההתקנה.
שיקולים לגבי האפליקציה
ב-Android 5.0 ואילך, אפליקציות יכולות להמשיך להגדיר הרשאות בהתאמה אישית משלה בדיוק כמו בעבר, ולבקש הרשאות בהתאמה אישית מאפליקציות אחרות דרך המנגנון <uses-permission>. עם זאת, בעקבות הדרישה החדשה שנוספה ב-Android 5.0, כדאי לבדוק היטב את ההשפעות האפשריות על האפליקציה שלכם.
הנה כמה נקודות שכדאי לשקול:
- האם האפליקציה שלכם מכילה הצהרות על רכיבי
<permission>במניפסט שלה? אם כן, האם הן באמת נחוצות לתפקוד תקין של האפליקציה או השירות? או שאפשר להשתמש בהרשאת ברירת מחדל של המערכת במקום זאת? - אם יש באפליקציה שלכם רכיבים של
<permission>, אתם יודעים מאיפה הם הגיעו? - האם ברצונך לאשר לאפליקציות אחרות לבקש את ההרשאות בהתאמה אישית שלך דרך
<uses-permission>? - האם אתם משתמשים בקוד לדוגמה או בקוד סטנדרטי באפליקציה שכולל את הרכיבים
<permission>? האם רכיבי ההרשאות האלה באמת נחוצים? - האם השמות של ההרשאות בהתאמה אישית פשוטים או מבוססים על מונחים נפוצים שיכול להיות שאפליקציות אחרות משתמשות בהם?
התקנות ועדכונים חדשים
כפי שצוין למעלה, התקנות חדשות ועדכונים של האפליקציה במכשירים עם Android 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) מופעלות עכשיו,
- סטים של אלגוריתמים להצפנה (cipher suite) מסוג MD5, 3DES, ייצוא ומפתח סטטי ECDH מושבתים עכשיו,
- מומלץ להשתמש בחבילות הצפנה עם סודיות העברה (ECDHE ו-DHE).
השינויים האלה עשויים לגרום לשיבושים בקישוריות HTTPS או TLS/SSL במספר קטן של מקרים שמפורטים בהמשך.
חשוב לזכור ש-ProviderInstaller לאבטחה מ-Google Play Services כבר מציע את השינויים האלה בגרסאות של פלטפורמת Android, החל מ-Android 2.3.
השרת לא תומך באף אחת מחבילות ההצפנה המופעלות
לדוגמה, יכול להיות ששרת תומך רק בחבילות הצפנה מסוג 3DES או MD5. התיקון המועדף הוא לשפר את ההגדרות של השרת כדי לאפשר שימוש בפרוטוקולים ובחבילות הצפנה חזקים ומודרניים יותר. באופן אידיאלי, צריך להפעיל את TLSv1.2 ואת AES-GCM, וגם להפעיל את חבילות ההצפנה של Forward Secrecy (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 עם הפעלה של הפרוטוקולים שנתמכים בצורה נכונה על ידי השרת.
תמיכה בפרופילים מנוהלים
אדמינים של מכשירים יכולים להוסיף פרופיל מנוהל למכשיר. הפרופיל הזה הוא בבעלות האדמין, ומאפשר לו לשלוט בפרופיל המנוהל, בעוד שהפרופיל האישי של המשתמש ואחסון הנתונים שלו נשארים בשליטת המשתמש. השינוי הזה יכול להשפיע על ההתנהגות של האפליקציה הקיימת שלכם בדרכים הבאות.
טיפול בכוונות
אדמינים של המכשיר יכולים להגביל את הגישה לאפליקציות המערכת מהפרופיל המנוהל. במקרה כזה, אם אפליקציה מפעילה כוונה מהפרופיל המנוהל שבדרך כלל האפליקציה הזו מטפלת בה, ואין טיפול מתאים לכוונה בפרופיל המנוהל, הכוונה גורמת לחריגה. לדוגמה, האדמין של המכשיר יכול להגביל את הגישה של אפליקציות בפרופיל המנוהל לאפליקציית המצלמה של המערכת. אם האפליקציה פועלת בפרופיל המנוהל ומפעילה את startActivityForResult() עבור MediaStore.ACTION_IMAGE_CAPTURE, ואין באפליקציה בפרופיל המנוהל שיכולה לטפל בכוונה, התוצאה היא ActivityNotFoundException.
כדי למנוע זאת, צריך לוודא שיש לפחות טיפול אחד לכל כוונה לפני שמפעילים אותה. כדי לבדוק אם יש טיפול תקין, צריך לקרוא ל-Intent.resolveActivity(). דוגמה לכך מופיעה בקטע צילום תמונות בדרך פשוטה: צילום תמונה באפליקציית המצלמה.
שיתוף קבצים בין פרופילים
לכל פרופיל יש נפח אחסון משלו. מכיוון שמזהה URI של קובץ מתייחס למיקום ספציפי באחסון הקבצים, המשמעות היא שמזהה URI של קובץ שתקף בפרופיל אחד לא תקף בפרופיל השני. בדרך כלל, לאפליקציה אין בעיה עם זה, כי בדרך כלל היא רק ניגשת לקבצים שהיא יוצרת. עם זאת, אם אפליקציה מצרפת קובץ ל-Intent, לא בטוח שאפשר לצרף URI של קובץ, כי בנסיבות מסוימות ה-Intent עשוי להיות מטופל בפרופיל השני. לדוגמה, אדמין של מכשיר יכול לציין שאירועי צילום תמונות צריכים להיות מטופלים על ידי אפליקציית המצלמה בפרופיל האישי. אם האפליקציה בפרופיל המנוהל מפעילה את הכוונה, המצלמה צריכה להיות מסוגלת לכתוב את התמונה למיקום שבו האפליקציות בפרופיל המנוהל יכולות לקרוא אותה.
כדי להימנע מבעיות, כשצריך לצרף קובץ לכוונה שעשויה לעבור מפרופיל אחד לאחר, צריך ליצור URI של תוכן לקובץ ולהשתמש בו. מידע נוסף על שיתוף קבצים באמצעות מזהי URI של תוכן זמין במאמר שיתוף קבצים.
לדוגמה, האדמין של המכשיר יכול לאפשר ל-ACTION_IMAGE_CAPTURE להיות מטופלת על ידי המצלמה בפרופיל האישי. השדה EXTRA_OUTPUT של כוונת ההפעלה צריך לכלול URI של תוכן שמציין איפה התמונה צריכה להישמר. אפליקציית המצלמה יכולה לכתוב את התמונה למיקום שצוין ב-URI הזה, והאפליקציה שהפעילה את ה-intent תוכל לקרוא את הקובץ הזה, גם אם האפליקציה נמצאת בפרופיל השני.
הוסרה התמיכה בווידג'טים של מסך הנעילה
ב-Android 5.0 הוסרה התמיכה בווידג'טים במסך הנעילה, אבל התמיכה בווידג'טים במסך הבית נמשכת.