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

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

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

יצרני ציוד מקורי (OEM) שמשנים את הפלטפורמה עלולים להתנגש עם ההטמעה של מצב תנומה של האפליקציה. לדוגמה

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

CDD מציג קבוצה חדשה של דרישות לשינויים שמבוססים על השימוש באפליקציה, בדומה לדרישות הקיימות ב-3.5.1. השהיה של אפליקציות מתבצעת בהתאם לדרישות הבאות.

קוד המסגרת נמצא:

הלוגיקה של המדיניות נמצאת:

  • repo: platform/packages/modules/Permission
  • ספרייה: PermissionController/src/com/android/permissioncontroller/hibernation

אדריכלות ברמה גבוהה

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

  • ביטול אוטומטי של הרשאות
  • סגירה ידנית של האפליקציה
  • מוחקים את קובצי ה-ODEX וה-VDEX.
  • מחיקת המטמון של האפליקציה

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

העיצוב המתוכנן מתמקד בשני חלקים עיקריים:

  • בחירה מתי חבילה צריכה לעבור תנומה
  • אופטימיזציה של החבילה במצב תרדמה

שירות מערכת חדש, AppHibernationService, ושירות משימה, AppHibernationJobService,, ב-PermissionController הם הדבק ששולט בקבלת ההחלטות ובלוגיקה הכוללת.

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

האופטימיזציה של החבילה היא המקום שבו מתבצעים כל החיסכון והאופטימיזציות בפועל. AppHibernationService מתקשר עם חלקים שונים במערכת כדי לעצור את החבילה, למחוק נתוני מטמון, למחוק ארטיפקטים של ART וכו'. ביטול ההרשאות מופעל ישירות מ-AppHibernationJobService כדי לשמור על הפונקציונליות של ביטול ההרשאות האוטומטי במכשירי Android מגרסה 11 ומטה.

חוויית משתמש

המשתמש מקבל מידע ומנגנוני בקרה לגבי האפליקציות שאפשר להעביר למצב תרדמה.

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

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

תאימות לאחור

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

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

התאמה אישית

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

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

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

בדיקה

ל-App Hibernation יש בדיקות CTS ובדיקות יחידה כדי לוודא שהוא פועל כמו שצריך.