אם האפליקציה שלכם מטרגטת את Android 11 (רמת API 30) ואילך, והמשתמש לא מבצע אינטראקציה עם האפליקציה במשך כמה חודשים, המערכת מעבירה את האפליקציה למצב תרדמת חורף. המערכת מבצעת אופטימיזציה לנפח האחסון במקום לביצועים, והיא מגינה על נתוני המשתמשים. התנהגות המערכת הזו דומה למה שקורה כשהמשתמש משבית את האפליקציה באופן ידני מהגדרות המערכת.
ההשלכות של מצב תנומה
כפי שמוצג בטבלה 1, ההשפעות של מצב תרדמה תלויות בגרסה של SDK היעד של האפליקציה, וגם במכשיר שבו האפליקציה פועלת:
גרסת היעד של ה-SDK | מאפייני המכשיר | ההשפעות של מצב תנומה |
---|---|---|
Android מגרסה 12 ואילך | מכשיר עם Android מגרסה 12 ואילך |
ההרשאות בזמן הריצה של האפליקציה יאפסו. הפעולה הזו מובילה לאותה השפעה כמו אם המשתמש צפה בהרשאה בהגדרות המערכת ושינה את רמת הגישה של האפליקציה לדחייה. האפליקציה לא יכולה להריץ משימות או התראות מהרקע. האפליקציה לא יכולה לקבל התראות דחיפה, כולל הודעות עם עדיפות גבוהה שנשלחות דרך Firebase Cloud Messaging. כל הקבצים במטמון של האפליקציה יוסרו. |
Android 11 | פועלת עם Android 11 | ההרשאות בזמן הריצה של האפליקציה יאפסו. |
Android 11 | פועלת ב-Android 6.0 (רמת API 23) עד Android 10 (רמת API 29), כולל, ומופעלת על ידי Google Play Services |
ההרשאות בזמן הריצה של האפליקציה יאפסו. ההתנהגות הזו תיכנס לתוקף בדצמבר 2021. מידע נוסף על איך מאפשרים לאפס את ההרשאות באופן אוטומטי למיליארדי מכשירים נוספים |
התנהגות המערכת כשאפליקציה יוצאת ממצב תרדמה
בפעם הבאה שהמשתמש יתקשר עם האפליקציה, היא תצא ממצב תרדמה ותוכל ליצור שוב משימות, התראות והתראות.
עם זאת, המערכת לא מבצעת את הפעולות הבאות עבור האפליקציה:
מעניקים מחדש את ההרשאות בזמן הריצה של האפליקציה.
המשתמש יצטרך להעניק מחדש את ההרשאות האלה לאפליקציה.
מגדירים מחדש את לוח הזמנים של משימות, התראות והתראות שהוגדרו לפני שהאפליקציה נכנסה למצב תרדמה.
כדי לתמוך בתהליך העבודה הזה בקלות רבה יותר, כדאי להשתמש ב-WorkManager. אפשר גם להוסיף לוגיקה של תזמון מחדש בבורר השידור
ACTION_BOOT_COMPLETED
, שמופעל כשהאפליקציה יוצאת ממצב תרדמה ואחרי שהמכשיר מופעל.
שימוש באפליקציות
בקטעים הבאים מפורטות דוגמאות לשימוש באפליקציה, וגם דוגמאות לפעולות שהמערכת לא מחשיבה כשימוש באפליקציה.
דוגמאות לשימוש באפליקציה
כשפעילות באפליקציה ממשיכה, המערכת מתייחסת לאירוע הזה כאינטראקציה של משתמש. לכן, המערכת מאריכה את משך הזמן לפני שהאפליקציה נכנסת למצב תרדמה.
ב-Android 11 ואילך, ההתנהגויות הבאות נחשבות גם הן לאינטראקציות של משתמשים:
חשוב לציין ששימוש באפליקציה למצב תרדמה לא מחייב אינטראקציה מפורשת של המשתמש. כל עוד רכיב מהחבילה מופעל, הוא עדיין נחשב לשימוש באפליקציה. דוגמאות לכך:
- אפליקציות שיש להן ספק שירות או תוכן שמקושר לאפליקציה אחרת במכשיר או במערכת ההפעלה. לדוגמה, עורכי שיטות קלט (IME) או מנהלי סיסמאות.
מקלטי שידור בחבילה שמקבלים שידור מפורש מחבילה חיצונית.
דוגמאות לא רלוונטיות
אם האפליקציה שלכם תמיד מציגה את ההתנהגויות שמתוארות ברשימה הבאה, היא תעבור למצב תרדמה אחרי כמה חודשים:
- הפעלת משימה מתוזמנת באמצעות
JobScheduler
. - מקבל שידור מרומז.
- תזמון התראות.
החרגות של המערכת ממצב תרדמה
ב-Android יש החרגות ברמת המערכת ממצב תרדמת של אפליקציות בתרחישי שימוש מסוימים. אם האפליקציה שלכם משתייכת לאחת מהקטגוריות הבאות, היא פטורה מתקני השימוש באפליקציות ולא תעבור למצב תרדמה.
- אפליקציות שלא מוצגות במרכז האפליקציות
- כל אפליקציה שאין לה משבצת פעילה של קיצור דרך במרכז האפליקציות.
- אפליקציות בפרופיל העבודה
- כל אפליקציה שמשתמש מתקין בפרופיל העבודה. לתשומת ליבכם: אם אותה אפליקציה נמצאת גם בפרופיל אישי, רק האפליקציה בפרופיל העבודה פטורה.
- בקרי מדיניות המכשירים
- אפליקציות ששולטות בכללי המדיניות המקומיים של המכשיר ובאפליקציות המערכת במכשירים.
- אפליקציות עם הרשאות של ספק
- כל אפליקציה שספקי טלפונים ניידים טוענים מראש במכשירים ורואים בה צורך למלא את ההתחייבויות החוזיות שלהם, למשל אפליקציות של הודעות קוליות או של שירות לקוחות.
- אפליקציות התקנה של צד שלישי
- חנויות אפליקציות של צד שלישי לעדכונים אוטומטיים של האפליקציות המותקנות בהן, במקרה הצורך.
החרגות של משתמשים ממצב תרדמה
אם אתם צופים שתרחישים לדוגמה מהותיים באפליקציה שלכם מושפעים ממצב תרדמה, תוכלו לבקש מהמשתמשים פטור ממצב תרדמה של האפליקציה. הפטור הזה שימושי במצבים שבהם המשתמש מצפה שהאפליקציה תפעל בעיקר ברקע, גם בלי אינטראקציה של המשתמש עם האפליקציה. למשל, כשהאפליקציה מבצעת אחת מהפעולות הבאות:
- דיווח על המיקום של בני המשפחה מעת לעת כדי לשמור על הבטיחות שלהם.
- סנכרון נתונים בין מכשיר לשרת של האפליקציה.
- לתקשר עם מכשירים חכמים, כמו טלוויזיה.
- התאמה למכשירים נלווים, כמו שעון.
כדי לבקש פטור, צריך לבצע את השלבים שמפורטים בקטעים הבאים.
בודקים אם המשתמש כבר השבית את מצב ההרדמה של האפליקציה
כדי לבדוק אם המשתמש כבר השבית את מצב ההרדמה של האפליקציה, צריך להשתמש ב-API getUnusedAppRestrictionsStatus()
.
לפרטים נוספים על השימוש ב-API הזה באפליקציה, אפשר לעיין בדוגמה לקוד API שבדף הזה.
לבקש מהמשתמש להשבית את מצב ההרדמה של האפליקציה
אם המשתמש עדיין לא השבית את מצב ההרדמה של האפליקציה, תוכלו לשלוח לו בקשה. כדי לעשות זאת, מבצעים את השלבים הבאים:
- להציג ממשק משתמש שמסביר למשתמש למה הוא צריך להשבית את מצב ההרדמה של האפליקציה.
-
קוראים ל-API
createManageUnusedAppRestrictionsIntent()
, כפי שמתואר בדוגמה לקוד API. ממשק ה-API הזה יוצר כוונה (intent) שגורמת לטעינת המסך פרטי האפליקציה בהגדרות. משם, המשתמש יכול להשבית את מצב ההרדמה של האפליקציה.חשוב לקרוא ל-
startActivityForResult()
ולא ל-startActivity()
כששולחים את הכוונה הזו.כפי שמוצג בטבלה 2, המיקום והשם של האפשרות משתנים בהתאם למאפיינים של המכשיר שבו האפליקציה מותקנת:
טבלה 2. אפשרות להשבית את מצב התרדמה של האפליקציה מאפייני המכשיר הדף שבו מופיעה האפשרות שם האפשרות שרוצים להשבית מכשיר עם Android מגרסה 13 ואילך נתונים מאפליקציות השהיית הפעילות באפליקציה אם אין בה שימוש פועלת עם Android 12 נתונים מאפליקציות הסרת הרשאות ופינוי נפח אחסון פועלת עם Android 11 פרטי האפליקציה > הרשאות הסרת ההרשאות אם האפליקציה לא נמצאת בשימוש פועלת ב-Android מגרסה 6.0 ועד 10, כולל, ומופעלת על ידי Google Play Services אפליקציית Play > תפריט > Play Protect > הרשאות לאפליקציות שלא בשימוש הסרת ההרשאות אם האפליקציה לא נמצאת בשימוש
דוגמה לקוד API
בדוגמת הקוד הזו מוסבר איך לבדוק אם מצב תרדמה מופעל באפליקציה, ואיך לבקש מהמשתמשים להשבית את מצב התרדמה באפליקציה.
Kotlin
val future: ListenableFuture<Int> = PackageManagerCompat.getUnusedAppRestrictionsStatus(context) future.addListener({ onResult(future.get()) }, ContextCompat.getMainExecutor(context)) fun onResult(appRestrictionsStatus: Int) { when (appRestrictionsStatus) { // Couldn't fetch status. Check logs for details. ERROR -> { } // Restrictions don't apply to your app on this device. FEATURE_NOT_AVAILABLE -> { } // The user has disabled restrictions for your app. DISABLED -> { } // If the user doesn't start your app for a few months, the system will // place restrictions on it. See the API_* constants for details. API_30_BACKPORT, API_30, API_31 -> handleRestrictions(appRestrictionsStatus) } } fun handleRestrictions(appRestrictionsStatus: Int) { // If your app works primarily in the background, you can ask the user // to disable these restrictions. Check if you have already asked the // user to disable these restrictions. If not, you can show a message to // the user explaining why permission auto-reset or app hibernation should be // disabled. Then, redirect the user to the page in system settings where they // can disable the feature. val intent = IntentCompat.createManageUnusedAppRestrictionsIntent(context, packageName) // You must use startActivityForResult(), not startActivity(), even if // you don't use the result code returned in onActivityResult(). startActivityForResult(intent, REQUEST_CODE) }
API של פלטפורמה מדור קודם
מערכת ההפעלה כוללת גם ממשק API ליצירת אינטראקציה עם תכונת ההרדמה. עם זאת, ה-API פועל רק במכשירים עם Android מגרסה 11 ואילך. ה-API לא מטפל בתכונות ההרדמה שמועברות לגרסאות קודמות של Android. לכן, אנחנו לא ממליצים להשתמש ב-API.
אם אתם צריכים להמשיך להשתמש ב-API באופן זמני למטרות תאימות, תוכלו להיעזר ברשימה הבאה:
- כדי לבדוק אם מצב תרדמת החורף מושבת באפליקציה:
isAutoRevokeWhitelisted()
- כדי לשלוח את המשתמש לדף ההגדרות של מצב תרדמה: יוצרים כוונה באמצעות
ACTION_APPLICATION_DETAILS_SETTINGS
הפעלה ידנית של התנהגות במצב תרדמה
כדי לבדוק איך האפליקציה מתנהגת אחרי שהמערכת מעבירה אותה למצב תרדמה:
(Android מגרסה 12 ואילך בלבד) מפעילים את התנהגות ההרדמה במכשיר:
adb shell device_config put app_hibernation app_hibernation_enabled true
מגדירים את משך הזמן שמוגדר כברירת מחדל שהמערכת ממתינה לפני שהיא נכנסת למצב תרדמה. כך תוכלו לשחזר אותו אחרי הבדיקה:
threshold=$(adb shell device_config get permissions \ auto_revoke_unused_threshold_millis2)
לצמצם את משך הזמן שהמערכת ממתינה. בדוגמה הבאה, המערכת משתנה כך שהאפליקציה תעבור למצב תרדמה רק שנייה אחת אחרי שתפסיקו את האינטראקציה עם האפליקציה:
adb shell device_config put permissions \ auto_revoke_unused_threshold_millis2 1000
מריצים את הפקודה הבאה כדי להמתין לסיום השידור בזמן האתחול במכשיר הבדיקה:
adb shell am wait-for-broadcast-idle
בסיום השידור, הפקודה הזו מחזירה את ההודעה:
All broadcast queues are idle!
מפעילים את תהליך מצב התרדמה של האפליקציה באופן ידני:
adb shell cmd jobscheduler run -u 0 -f \ com.google.android.permissioncontroller 2
(Android מגרסה 12 ואילך בלבד) מוודאים שהאפליקציה נמצאת במצב תרדמה באחת מהשיטות הבאות:
- שימו לב שבמכשיר הבדיקה מוצגת עכשיו התראה על כך שאפליקציות שלא בשימוש נמצאות במצב תרדמה.
מריצים את הפקודה הבאה:
adb shell cmd app_hibernation get-state PACKAGE-NAME
משחזרים את משך הזמן שמוגדר כברירת מחדל שבו המערכת ממתינה לפני שהיא מעבירה את האפליקציה למצב תרדמה:
adb shell device_config put permissions \ auto_revoke_unused_threshold_millis2 $threshold