הרשאות זמן ריצה

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

ב-Android מגרסה 6.0 ואילך, מודל ההרשאות של אפליקציות Android נועד להפוך את ההרשאות למובנות, מועילות ומאובטחות יותר למשתמשים. המודל העביר אפליקציות ל-Android שנדרשות להן הרשאות מסוכנות (ראו הרשאות שהושפעו) ממודל הרשאות בזמן ההתקנה למודל הרשאות בזמן הריצה:

• הרשאות בזמן ההתקנה

  (Android 5.1 וגרסאות ישנות יותר) משתמשים מעניקים לאפליקציות הרשאות מסוכנות כשהם מתקינים או מעדכנים אותן. יצרני המכשירים וספקי הסלולר יכולים להתקין מראש אפליקציות עם הרשאות שהוקצו מראש, בלי להודיע על כך למשתמש.

• הרשאות בזמן ריצה

  (Android מגרסה 6.0 עד 9) משתמשים מעניקים לאפליקציה הרשאות מסוכנות כשהיא פועלת. המועד שבו מתבצעת בקשת ההרשאות (למשל, כשהאפליקציה מופעלת או כשהמשתמש נכנס לתכונה ספציפית) תלוי באפליקציה, אבל המשתמש הוא זה שמעניק או דוחה את הגישה של האפליקציה לקבוצות הרשאות ספציפיות. יצרני ציוד מקורי (OEM) או ספקי סלולר יכולים להתקין אפליקציות מראש, אבל הם לא יכולים להקצות הרשאות מראש אלא אם הם עוברים את תהליך הבקשה לחריגה. (מידע נוסף זמין במאמר יצירת חריגים).

  (Android 10) המשתמשים נהנים משקיפות מוגברת ויכולים לקבוע לאילו אפליקציות יהיו הרשאות בזמן ריצה לזיהוי פעילות (AR). המשתמשים מתבקשים ב תיבת הדו-שיח של הרשאות בסביבת זמן הריצה לאשר את ההרשאות תמיד, לאשר אותן בזמן השימוש או לדחות אותן. כשמשדרגים את מערכת ההפעלה ל-Android 10, ההרשאות שניתנו לאפליקציות נשמרות, אבל המשתמשים יכולים להיכנס אל הגדרות ולשנות אותן.

הרשאות זמן ריצה מונעות מאפליקציות לקבל גישה לנתונים פרטיים בלי הסכמה של המשתמש, ומספקות להן הקשר נוסף ותובנות לגבי סוגי ההרשאות שהאפליקציות מבקשות או קיבלו. מודל זמן הריצה מעודד מפתחים לעזור למשתמשים להבין למה האפליקציות זקוקות להרשאות המבוקשות, ומספק שקיפות רבה יותר כדי שהמשתמשים יוכלו לקבל החלטות טובות יותר לגבי מתן או דחייה של ההרשאות.

ההרשאות שהושפעו

ב-Android 6.0 ואילך נדרשות הרשאות מסוכנות כדי להשתמש במודל הרשאות בסביבת זמן ריצה. הרשאות מסוכנות הן הרשאות עם סיכון גבוה יותר (כמו READ_CALENDAR) שמעניקות לאפליקציות המבקשות גישה לנתונים פרטיים של משתמשים, או שליטה במכשיר, שעלולות להשפיע לרעה על המשתמש. כדי להציג רשימה של הרשאות מסוכנות, מריצים את הפקודה:

adb shell pm list permissions -g -d

בגרסאות Android 6.0 ואילך, ההתנהגות של הרשאות רגילות לא משתנה. אלה כולן הרשאות לא מסוכנות, כולל הרשאות רגילות, הרשאות מערכת והרשאות חתימה. הרשאות רגילות הן הרשאות עם סיכון נמוך יותר (כמו SET_WALLPAPER) שמעניקות לאפליקציות המבקשות גישה לתכונות מבודדות ברמת האפליקציה, עם סיכון מינימלי לאפליקציות אחרות, למערכת או למשתמש. כמו בגרסאות Android 5.1 וגרסאות ישנות יותר, המערכת מעניקה הרשאות רגילות לאפליקציה המבקשת באופן אוטומטי במהלך ההתקנה, ולא מבקשת מהמשתמש לאשר את הבקשה. פרטים על הרשאות זמינים במסמכי העזרה של הרכיב<permission>.

הגבלות קשות ורכות ב-Android 10

בנוסף לסיכונים, הרשאה יכולה להיות מוגבלת באופן מוחלט או מוגבלת באופן רך. בכל מקרה, צריך להוסיף את ההרשאה המוגבלת גם לרשימת ההיתרים. ההגבלות הקשות שלא נכללות ברשימת ההיתרים פועלות באופן שונה מההגבלות הרכות שלא נכללות ברשימת ההיתרים:

• (הגבלות נוקשות) לא ניתן להעניק לאפליקציות הרשאות שלא נכללות ברשימת ההיתרים.
• (הגבלות רכות) אפליקציות ללא רשימת ההיתרים פועלות בהתאם להרשאה הספציפית שהן מבקשות. ההתנהגות מתוארת במסמכים הציבוריים של ההרשאה המבוקשת.

כשמתקינים אפליקציה, הכלי להתקנה (כמו חנות Google Play) יכול לבחור שלא להוסיף את ההרשאות המוגבלות של האפליקציה לרשימת ההיתרים. ההרשאות מוגבלות על ידי הפלטפורמה, וניתן להעניק אותן רק אם האפליקציה עומדת בקריטריונים מיוחדים בהתאם למדיניות הפלטפורמה. דוגמאות לסוגי הרשאות עם הגבלה חמורה כוללות הרשאות ל-SMS וליומן שיחות.

הוספה לרשימת ההיתרים מתבצעת במהלך ההתקנה, וגם

• אפליקציה כבר מותקנת במהלך השדרוג מ-Android 9 ל-Android 10.
• הרשאה ניתנת מראש או שאפליקציה מותקנת מראש.
• צריכה להיות הרשאה לתפקיד שכבר מוגדר כדי להוסיף את ההרשאה לרשימת ההיתרים.
• המתקין (למשל, חנות Google Play) מסמנים את ההרשאה כרשימה מורשית.

משתמשים לא יכולים להוסיף הרשאות באופן ידני לרשימת ההיתרים.

דרישות

מודל ההרשאות בסביבת זמן הריצה חל על כל האפליקציות, כולל אפליקציות שמותקנות מראש ואפליקציות שמועברות למכשיר כחלק מתהליך ההגדרה. דרישות התוכנה של האפליקציה כוללות:

• מודל ההרשאות בסביבת זמן הריצה צריך להיות עקבי בכל המכשירים עם Android 6.0 ומעלה. הדרישה הזו נאכפת באמצעות בדיקות של חבילה לבדיקות תאימות (CTS) של Android.
• אפליקציות חייבות לבקש מהמשתמשים להעניק הרשאות לאפליקציה בזמן הריצה. פרטים נוספים זמינים במאמר עדכון אפליקציות. יכול להיות שנעניק החרגות מוגבלות לאפליקציות ולמפעילים שמוגדרים כברירת מחדל, שמספקים פונקציונליות בסיסית של המכשיר שחשובה לתפעול הצפוי של המכשיר. (לדוגמה, לאפליקציית החיוג שמוגדרת כברירת מחדל במכשיר לטיפול ב-ACTION_CALL עשויה להיות גישה להרשאת הטלפון). פרטים נוספים זמינים במאמר יצירת החרגות.
• אפליקציות שהוגדרו מראש עם הרשאות מסוכנות חייבות לטרגט לרמת API 23 ולשמור על מודל ההרשאות של זמן הריצה. כלומר, תהליך ממשק המשתמש במהלך התקנת האפליקציה לא יכול לסטות מההטמעה של PermissionController ב-AOSP, המשתמשים יכולים לבטל הרשאות מסוכנות של אפליקציות שמותקנות מראש וכו'.
• אפליקציות ללא ממשק משתמש חייבות להשתמש בפעילות כדי לבקש הרשאות או לשתף מזהה משתמש ייחודי (UID) עם אפליקציה אחרת שיש לה את ההרשאות הנדרשות. פרטים נוספים זמינים במאמר אפליקציות ללא ממשק משתמש.

העברת הרשאות

הרשאות שניתנו לאפליקציות ב-Android 5.x ימשיכו להיות בתוקף אחרי העדכון ל-Android 6.0 ואילך, אבל המשתמשים יכולים לבטל את ההרשאות האלה בכל שלב.

בעדכון מ-Android 9 ל-Android 10, כל ההרשאות עם ההגבלות הקשות מתווספות לרשימת ההיתרים. פרטים על הטמעת ההרשאות המפוצלות לחזית/לרקע זמינים במאמר שינוי הפרטיות ב-Android 10, החל מבקשה למיקום ברקע.

שילוב

כשמשלבים את מודל ההרשאות בסביבת זמן הריצה של האפליקציה ל-Android מגרסה 6.0 ואילך, צריך לעדכן את האפליקציות המותקנות מראש כך שיתואמות למודל החדש. אפשר גם להגדיר חריגים לאפליקציות שמשמשות כברירת מחדל כמפעילים או כספקים של פונקציונליות הליבה, להגדיר הרשאות בהתאמה אישית ולהתאים אישית את העיצוב של האפליקציה PermissionController.

עדכון אפליקציות

לאפליקציות בתמונת המערכת ולאפליקציות שהותקנו מראש לא מוענקות הרשאות מראש באופן אוטומטי. מומלץ לעבוד עם מפתחי האפליקציות המותקנות מראש (יצרני ציוד מקורי, ספקי סלולר וצד שלישי) כדי לבצע את השינויים הנדרשים באפליקציות לפי ההנחיות למפתחים. באופן ספציפי, עליכם לוודא שהאפליקציות המותקנות מראש שונו כדי למנוע קריסות ובעיות אחרות כשמשתמשים מבטלים את ההרשאות.

אפליקציות שהותקנו מראש

ב-Android 9 וגרסאות ישנות יותר, אפליקציות שהוגדרו מראש ומשתמשות בהרשאות מסוכנות חייבות לטרגט לרמת API ‏23 ואילך, ולשמור על מודל ההרשאות של AOSP בגרסה 6.0 ואילך של Android. לדוגמה, תהליך ממשק המשתמש במהלך התקנת אפליקציה לא יכול לסטות מההטמעה של PermissionController ב-AOSP. המשתמשים יכולים אפילו לבטל את ההרשאות המסוכנות של אפליקציות שמותקנות מראש.

ב-Android מגרסה 6.0 ועד 9, חלק מההרשאות מוענקות במהלך תהליך ההתקנה. עם זאת, החל מגרסה 10, תהליך ההתקנה (שמתבצע על ידי האפליקציה Package Installer) הוא פונקציה נפרדת מהענקת ההרשאות (באפליקציה Permission Controller).

אפליקציות ללא ממשק משתמש

רק פעילויות יכולות לבקש הרשאות. שירותים לא יכולים לבקש הרשאות ישירות.

• ב-Android 5.1 ובגרסאות קודמות, אפליקציות ללא ממשק משתמש יכולות לבקש הרשאות בזמן ההתקנה, או אם הן הותקנו מראש בלי להשתמש בפעילות.
• בגרסה Android 6.0 ואילך, אפליקציות ללא ממשק משתמש חייבות להשתמש באחת מהשיטות הבאות כדי לבקש הרשאות:
• מוסיפים פעילות כדי לבקש הרשאות. (זו השיטה המועדפת).
• שיתוף מזהה UID עם אפליקציה אחרת שיש לה את ההרשאות הנדרשות. מומלץ להשתמש בשיטה הזו רק אם אתם צריכים שהפלטפורמה תעבד כמה קובצי APK כאפליקציה אחת.

המטרה היא למנוע בלבול בקרב המשתמשים באמצעות בקשות הרשאה שמופיעות מחוץ להקשר.

התאמה אישית של ממשק המשתמש של PackageInstaller

אם רוצים, אפשר להתאים אישית את העיצוב של ממשק המשתמש של ההרשאות על ידי עדכון עיצובי ברירת המחדל של המכשיר (Theme.DeviceDefault.Settings ו-Theme.DeviceDefault.Light.Dialog.NoActionBar) שבהם משתמש PackageInstaller. עם זאת, עקב החשיבות של עקביות למפתחי אפליקציות, אי אפשר להתאים אישית את המיקום, את המיקום ואת הכללים של מועד ההצגה של ממשק המשתמש של ההרשאות.

כדי לכלול מחרוזות בשפות נוספות, צריך לתרום את המחרוזות ל-AOSP.

יצירת חריגים

אפשר להעניק מראש הרשאות לאפליקציות שמשמשות כמפעילים או כספקים שמוגדרים כברירת מחדל לפונקציונליות הליבה של מערכת ההפעלה באמצעות הכיתה DefaultPermissionGrantPolicy.java ב-PackageManager. לדוגמה:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

הגדרת הרשאות בהתאמה אישית

אפשר להגדיר הרשאות וקבוצות בהתאמה אישית כרגילות או כמסוכנות, ולהוסיף הרשאות ספציפיות ליצרן ציוד מקורי או לספק שירותי סלולר לקבוצות הרשאות קיימות, בדיוק כמו בגרסאות Android 5.x וגרסאות קודמות.

ב-Android מגרסה 6.0 ואילך, אם מוסיפים הרשאה מסוכנת חדשה, צריך לטפל בה באותו אופן שבו מטפלים בהרשאות מסוכנות אחרות (הבקשה להרשאה מתבצעת במהלך זמן הריצה של האפליקציה, והמשתמשים יכולים לבטל אותה). פרטים נוספים:

• אפשר להוסיף הרשאות חדשות לקבוצה קיימת, אבל אי אפשר לשנות את המיפוי של AOSP של הרשאות מסוכנות וקבוצות של הרשאות מסוכנות. (כלומר, אי אפשר להסיר הרשאה מקבוצה ולהקצות אותה לקבוצה אחרת).
• אפשר להוסיף קבוצות הרשאות חדשות באפליקציות שמותקנות במכשיר, אבל אי אפשר להוסיף קבוצות הרשאות חדשות במניפסט של הפלטפורמה.

בדיקת ההרשאות

Android כולל בדיקות של חבילת בדיקות התאימות (CTS) שמאשרות שההרשאות נשלחות לקבוצות הנכונות. דרישה לעבור את הבדיקות האלה היא תנאי לתאימות ל-CTS בגרסה Android 6.0 ואילך.

ביטול הרשאות

מגרסה 13 של Android ואילך, אפשר לבטל הרשאות זמן ריצה שהוקצו באמצעות Context.revokeSelfPermissionsOnKill(). הביטול מתבצע באופן אסינכרוני ומופעל כשבטוח לעשות זאת בלי להפריע למשתמש. כשהביטול מופעל, כל התהליכים שפועלים ב-UID של מבצע הקריאה נמחקים.

חשוב להבין שביטול הרשאה אחת לא בהכרח ישתקף בממשק המשתמש של ההגדרות, שבו ההרשאות מחולקות לפי קבוצות. בדרך כלל, קבוצת הרשאות מוצגת כשהוקצתה כל עוד הוקצתה לפחות אחת מההרשאות בקבוצה הזו. אם חשוב לכם לוודא שהמשתמשים יוכלו לאשר את ביטול ההרשאה בהגדרות, חשוב לבטל כל הרשאה בקבוצת ההרשאות. כדי לבדוק אילו הרשאות שייכות לקבוצה מסוימת, אפשר להשתמש ב-PackageManager.getGroupOfPlatformPermission וב-PackageManager.getPlatformPermissionsForGroup.

כשהמערכת מבטלת את ההרשאות המבוקשות, היא מבטלת גם את ההרשאות התואמות לרקע, אם אף אחת מההרשאות התואמות לחזית לא ניתנה עדיין.

ביטול ההרשאה לא יופעל כל עוד התהליך יישאר בחזית, אבל אפשר גם להפעיל אותו באופן מיידי על ידי סגירת כל התהליכים שפועלים ב-uid הנוכחי באופן ידני, למשל באמצעות System.exit(). עם זאת, מומלץ לאפשר למערכת להחליט מתי להפעיל אותו.

אחרי ביטול ההרשאה, תוכלו לבקש אותה שוב והמשתמש יתבקש לאשר או לדחות את הבקשה. אי אפשר לבקש הרשאה שנדחתה בעבר על ידי המשתמש. מומלץ לבטל הרשאות שיש לכם כרגע אבל אתם כבר לא צריכים, אבל חשוב לא להודיע למשתמש על הביטול עד שהוא ייכנס לתוקף.