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

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

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

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

• הרשאות בתחילת ההפעלה

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

  (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 ויומני שיחות.

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

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

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

הדרישות

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

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

העברת הרשאות

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

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

שילוב

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

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

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

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

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

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

אפליקציות ללא GUI

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

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

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

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

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

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

יצירת חריגים

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

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

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

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

אפשר להגדיר הרשאות וקבוצות בהתאמה אישית בתור רגילות או מסוכן ולהוסיף הרשאות ספציפיות של ה-OEM (יצרן הציוד המקורי או הספק) הקיימות של קבוצות הרשאות, בדיוק כמו שהייתם עושים ב-Android 5.x ובגרסאות קודמות.

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

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

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

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

ביטול הרשאות

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

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

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

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

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