כשאתם מעלים קובץ APK, הוא צריך לעמוד בדרישות של Google Play לגבי רמת ה-API לטירגוט.
החל מ-31 באוגוסט 2024:
- כדי לשלוח אפליקציות חדשות ועדכוני אפליקציות ל-Google Play, הן צריכות לטרגט ל-Android 14 (רמת API 34) ואילך, מלבד אפליקציות ל-Wear OS ול-Android TV, שצריכות לטרגט ל-Android 13 (רמת API 33) ואילך.
- אפליקציות קיימות צריכות לטרגט ל-Android 13 (רמת API 33) ואילך כדי להישאר זמינות למשתמשים חדשים במכשירים עם מערכת Android OS בגרסה גבוהה יותר מרמת ה-API לטירגוט של האפליקציה. אפליקציות שמטרגטות את Android 12 (רמת API 31) או גרסאות קודמות (Android 10 (רמת API 29) או גרסאות קודמות ל-Wear OS ו-Android 11 (רמת API 30) או גרסאות קודמות ל-Android TV) יהיו זמינות רק במכשירים עם Android OS בגרסה זהה או נמוכה יותר מרמת ה-API לטירגוט של האפליקציה.
אם נדרש לך עוד זמן כדי לעדכן את האפליקציה, תהיה לך אפשרות לבקש הארכה עד 1 בנובמבר 2024. תהיה לך אפשרות לגשת לטופסי התוספים של האפליקציה ב-Play Console בהמשך השנה.
מקרים חריגים מהדרישות האלה:
- אפליקציות פרטיות באופן קבוע שמוגבלות למשתמשים בארגון מסוים ומיועדות להפצה פנימית בלבד.
- אפליקציות שמטרגטות את Android Automotive OS, או ארוזות בחבילות עם קובצי APK שמטרגטים את Android Automotive OS.
למה לטרגט ערכות SDK חדשות יותר?
בכל גרסה חדשה של Android יש שינויים שמספקים שיפורים באבטחה ובביצועים ומשפרים את חוויית המשתמש ב-Android. חלק מהשינויים האלה רלוונטיים רק לאפליקציות שמצהירות באופן מפורש על תמיכה באמצעות מאפיין המניפסט targetSdkVersion
(שנקרא גם רמת ה-API לטירגוט).
הגדרת האפליקציה כך שתטרגט לרמת API עדכנית תאפשר למשתמשים ליהנות מהשיפורים האלה, בזמן שהאפליקציה עדיין תוכל לפעול בגרסאות Android ישנות יותר. טירגוט לרמת API עדכנית מאפשר לאפליקציה שלכם ליהנות מהמאפיינים העדכניים ביותר של הפלטפורמה כדי לשמח את המשתמשים. בנוסף, החל מגרסה Android 10 (רמת API 29), משתמשים רואים אזהרה כשהם מפעילים אפליקציה בפעם הראשונה, אם האפליקציה מטרגטת את Android 5.1 (רמת API 22) ואילך.
במסמך הזה מפורטות נקודות חשובות שצריך לדעת כשמעדכנים את רמת ה-API לטירגוט כך שתעמוד בדרישה של Google Play. עליכם לפעול לפי ההוראות שמפורטות בקטעים הבאים, בהתאם לגרסה שאליה אתם עוברים.
מעבר מ-Android מגרסה 12 ואילך (רמת API 31) לגרסה עדכנית יותר
כדי לעדכן את האפליקציה כך שתטרגט לגרסה עדכנית יותר של Android, בצעו את רשימת השינויים הרלוונטיים בהתנהגות:
מעבר מ-Android 11 (רמת API 30) ל-Android 12 (רמת API 31)
אבטחה והרשאות
- Bluetooth: צריך להחליף את ההצהרות על ההרשאות
BLUETOOTH
ו-BLUETOOTH_ADMIN
בהרשאותBLUETOOTH_SCAN
,BLUETOOTH_ADVERTISE
אוBLUETOOTH_CONNECT
. כבר לא צריך לשלוחLOCATION
בקשות הרשאה בתחילת ההפעלה בשביל פעולות Bluetooth. - מיקום: משתמשים יכולים לבקש מאפליקציות לאחזר רק מידע משוער על המיקום שלהם. צריך לבקש את ההרשאה
ACCESS_COARSE_LOCATION
בכל פעם שמבקשים אתACCESS_FINE_LOCATION
.- מסנני Intent: אם האפליקציה מכילה פעילויות, שירותים או מקלטים של שידורים שמשתמשים במסנני Intent, צריך להצהיר באופן מפורש על המאפיין android:exported לרכיבים האלה.
- מצב תרדמה: יכול להיות שאפליקציות יועברו למצב תרדמה אם לא תשתמשו בהן במשך תקופה מסוימת. במצב תרדמה, ההרשאות בזמן הריצה והמטמון של האפליקציה מתאפסים, ולא ניתן להריץ משימות או התראות. אתם יכולים לבדוק את סטטוס ההרדמה של האפליקציה.
- יכולת השינוי של PendingIntent: עליכם לציין את יכולת השינוי של כל אובייקט PendingIntent שנוצר על ידי האפליקציה.
חוויית משתמש
- התראות בהתאמה אישית: התראות עם צפיות בתוכן בהתאמה אישית לא ישתמשו יותר באזור ההתראות המלא. במקום זאת, המערכת מחילה תבנית סטנדרטית. התבנית הזו מבטיחה שההתראות בהתאמה אישית יהיו מעוצבות באותו אופן כמו התראות אחרות בכל המצבים. ההתנהגות הזו כמעט זהה להתנהגות של
Notification.DecoratedCustomViewStyle
. - שינויים באימות של קישורי אפליקציות ל-Android: כשמשתמשים באימות של קישורי אפליקציות ל-Android, חשוב לוודא שמסנני ה-Intent כוללים את הקטגוריה BROWSABLE ותומכים בפרוטוקול HTTPS.
ביצועים
הגבלות הפעלה של שירותים שפועלים בחזית: כדי לטרגט את Android מגרסה 12 ואילך, האפליקציה לא יכולה להפעיל שירותים שפועלים בחזית בזמן שהיא פועלת ברקע, מלבד כמה מקרים מיוחדים. אם אפליקציה מנסה להפעיל שירות שפועל ברקע בזמן שהאפליקציה פועלת ברקע, מתרחשת חריגה (למעט המקרים המיוחדים).
כדאי להשתמש ב-WorkManager כדי לתזמן ולהתחיל משימות מהירות בזמן שהאפליקציה פועלת ברקע. כדי לבצע פעולות שחשוב לבצע בזמן, שהמשתמש מבקש, צריך להפעיל שירותים בחזית במסגרת התראה מדויקת.
הגבלות על 'טרמפולינה של התראות': כשמשתמשים מקישים על התראות, חלק מהאפליקציות מגיבים על ידי הפעלת רכיב באפליקציה שמתחיל את הפעילות שהמשתמש רואה ומקיים איתה אינטראקציה. רכיב האפליקציה הזה נקרא 'trampoline' של התראות.
אסור לאפליקציות להפעיל פעילויות משירותים או ממקלטי שידור המשמשים כtrampolines של התראות. אחרי שמשתמש מקייש על התראה או על לחצן פעולה בהתראה, האפליקציה לא יכולה להפעיל את
startActivity()
בתוך שירות או מקלט שידור.
כאן אפשר למצוא את הרשימה המלאה של השינויים שמשפיעים על אפליקציות שמטרגטות ל-Android 12 (רמת API 31).
מעבר מגרסה ישנה יותר מ-Android 11 (רמת API 30)
בוחרים את גרסת Android שממנה יתבצע המעבר:
העברה ל-Android 5 (רמת API 21)
כדי לוודא שהאפליקציה שלכם מביאה בחשבון את השינויים שהוצגו במהדורות הבאות, כדאי לעיין בדף Behavior Changes (שינויים בהתנהגות) המתאים לכל אחת מהמהדורות הבאות:
כדי להמשיך, פועלים לפי ההוראות בקטע הבא.
מעבר ל-Android 6 (רמת API 23)
השיקולים הבאים רלוונטיים לאפליקציות שמטרגטות את הפלטפורמה בגרסה Android 6.0 ואילך:
-
-
הרשאות מסוכנות ניתנות רק בזמן הריצה. תהליכי ממשק המשתמש צריכים לספק אפשרויות להענקת ההרשאות האלה.
-
במידת האפשר, יש לוודא שהאפליקציה מוכנה לטיפול בדחייה של בקשות הרשאה. לדוגמה, אם משתמש דוחה בקשה לגשת ל-GPS של המכשיר, חשוב לוודא שיש באפליקציה דרך אחרת להמשיך.
-
רשימה מקיפה של השינויים שהוצגו ב-Android 6.0 (רמת API 23) מפורטת בדף שינויים בהתנהגות לגרסה הזו של הפלטפורמה.
ממשיכים לפי ההוראות שבקטע הבא.
העברה ל-Android 7 (רמת API 24)
השיקולים הבאים חלים על אפליקציות שמטרגטות את Android 7.0 ואילך של הפלטפורמה:
-
מצב 'נמנום' ו'אפליקציה במצב המתנה'
תכנון לפי ההתנהגויות שמתוארות במאמר אופטימיזציה למצב Doze ולמצב המתנה של אפליקציות, שכולל שינויים מצטברים שהוצגו במספר גרסאות של הפלטפורמה.
כשהמכשיר במצב 'נמנום' ו'מצב המתנה של אפליקציה', המערכת פועלת באופן הבא:
- הגבלת הגישה לרשת
- דחייה של התראות, סנכרון ומשימות
- הגבלת סריקות GPS ו-Wi-Fi
- הגבלת הודעות Firebase Cloud Messaging ברמת עדיפות רגילה.
-
שינויים בהרשאות
- המערכת מגבילה את הגישה לספריות פרטיות של אפליקציות.
-
חשיפת URI של
file://
מחוץ לאפליקציה מפעילהFileUriExposedException
. אם צריך לשתף קבצים עם גורמים מחוץ לאפליקציה, צריך להטמיע אתFileProvider
-
המערכת אוסרת על קישור לספריות שאינן NDK.
לרשימה המלאה של השינויים שהושקו ב-Android 7.0 (רמת API 24), ראו את הדף שינויים בהתנהגות של גרסת הפלטפורמה הזו.
כדי להמשיך, פועלים לפי ההוראות שבקטע הבא.
מעבר ל-Android 8 (רמת API 26)
השיקולים הבאים רלוונטיים לאפליקציות שמטרגטות את הפלטפורמה בגרסה 8.0 ואילך של Android:
-
מגבלות ביצוע ברקע
-
המערכת מגבילה את השירותים של אפליקציות שלא פועלות בחזית.
-
startService()
מקפיץ עכשיו הודעת שגיאה כשאפליקציה מנסה להפעיל אותו בזמן ש-startService()
אסור. -
כדי להפעיל שירותים שפועלים בחזית, האפליקציה צריכה להשתמש ב-
startForeground()
וב-startForegroundService()
. - חשוב לקרוא בעיון את השינויים שבוצעו ב-JobScheduler API, כפי שמתואר בדף Behavior Changes ב-Android 8.0 (רמת API 26).
- כדי להשתמש ב- Firebase Cloud Messaging, צריך גרסה 10.2.1 של Google Play services SDK ואילך.
- כשמשתמשים ב- Firebase Cloud Messaging, שליחת ההודעות כפופה למגבלות על ביצוע פעולות ברקע. כאשר נדרשת עבודת רקע בזמן קבלת ההודעה, למשל כדי לבצע סנכרון של נתוני רקע, האפליקציה צריכה לתזמן משימות באמצעות Firebase Job Dispatcher או JobIntentService. מידע נוסף זמין ב מסמכי התיעוד של Firebase Cloud Messaging.
-
-
שידורים מרומזים
-
קיימות הגבלות על שידור מרומז. מידע על טיפול באירועים ברקע זמין במסמכי התיעוד של ה-API
JobScheduler
.
-
קיימות הגבלות על שידור מרומז. מידע על טיפול באירועים ברקע זמין במסמכי התיעוד של ה-API
-
הגבלות על מיקום ברקע
-
לאפליקציות שפועלות ברקע יש גישה מוגבלת לנתוני מיקום.
- במכשירים עם Google Play Services, אפשר להשתמש ב ספק המיקום המשולב כדי לקבל עדכוני מיקום מדי פעם.
-
לאפליקציות שפועלות ברקע יש גישה מוגבלת לנתוני מיקום.
-
המערכת מגבילה את השירותים של אפליקציות שלא פועלות בחזית.
-
ערוצי התראות
- צריך להגדיר את מאפייני ההפרעה של ההתראות בנפרד לכל ערוץ.
- כדי שההתראות יופיעו, צריך להקצות אותן לערוץ.
-
בגרסה הזו של הפלטפורמה יש תמיכה ב-
NotificationCompat.Builder
.
-
פרטיות
- ההיקף של ANDROID_ID הוא לכל מפתח לחתימת אפליקציה.
לרשימה מקיפה של השינויים שהושקו ב-Android 8.0 (רמת API 26), תוכלו לעיין בדף שינויים בהתנהגות של גרסת הפלטפורמה הזו.
מעבר מ-Android 8 (API 26) ל-Android 9 (API 28)
-
ניהול צריכת חשמל
- קטגוריות של אפליקציות במצב המתנה – הגבלות חדשות על פעילות ברקע על סמך המעורבות באפליקציה, כמו משימות מושהות, התראות ומכסות להודעות בעדיפות גבוהה
- שיפורים במצב חיסכון בסוללה מגבירים את ההגבלות על אפליקציות במצב המתנה
-
הרשאה לשימוש בשירות שפועל בחזית
- צריך לבקש את ההרשאה הרגילה
FOREGROUND_SERVICE
(לא הרשאת זמן ריצה)
- צריך לבקש את ההרשאה הרגילה
-
שינויים בהגדרות הפרטיות
- גישה מוגבלת לחיישני הרקע
- הגישה ליומני השיחות הוגבלה, והיא נמצאת עכשיו בקבוצת ההרשאות
CALL_LOG
- גישה מוגבלת למספרי טלפון, שנדרשת לה הרשאה
READ_CALL_LOG
- גישה מוגבלת למידע על רשתות Wi-Fi
רשימה מקיפה של השינויים שהוצגו ב-Android 9.0 (רמת API 28) מפורטת בקטע שינויים בהתנהגות.
מעבר מ-Android 9 (רמת API 28) ל-Android 10 (רמת API 29)
-
התראות
עם Intent במסך מלא
-
צריך לבקש את ההרשאה הרגילה
USE_FULL_SCREEN_INTENT
(לא הרשאת זמן ריצה).
-
צריך לבקש את ההרשאה הרגילה
-
תמיכה במכשירים מתקפלים ובמכשירים עם מסך גדול
-
במצב 'המשך' בו-זמנית, ניתן להגדיר כמה פעילויות בו-זמנית, אבל רק באחת מהן להתמקד בפועל.
-
השינוי הזה משפיע על ההתנהגות של
onResume()
ושלonPause()
. -
מושג חדש של מחזור חיים של 'הפעלה מחדש של הפעילות העליונה', שאפשר לזהות אותו על ידי הרשמה ל-
onTopResumedActivityChanged()
.- ניתן 'להפעיל מחדש' רק פעילות אחת.
-
השינוי הזה משפיע על ההתנהגות של
-
כשהערך של
resizeableActivity
מוגדר לערךfalse
, אפליקציות יכולות לציין גם את התגminAspectRatio
שמכניס את האפליקציה לפורמט letterbox באופן אוטומטי ביחס גובה-רוחב צר יותר.
-
במצב 'המשך' בו-זמנית, ניתן להגדיר כמה פעילויות בו-זמנית, אבל רק באחת מהן להתמקד בפועל.
-
שינויים בנושא פרטיות
-
אחסון ברמת ההיקף
- הגישה לאחסון החיצוני מוגבלת רק לספרייה ספציפית לאפליקציה ולסוגי מדיה ספציפיים שנוצרו על ידי האפליקציה.
-
הגישה למיקום מוגבלת בזמן שהאפליקציה פועלת ברקע,
נדרשת ההרשאה
ACCESS_BACKGROUND_LOCATION
. - גישה מוגבלת למזהים שלא ניתן לאפס, כמו מספר IMEI ומספר סדרתי.
-
גישה מוגבלת למידע על פעילות פיזית, כמו מספר הצעדים של המשתמש. נדרשת הרשאה
ACTIVITY_RECOGNITION
. -
גישה מוגבלת לחלק מממשקי ה-API של הטלפון, ה-Bluetooth וה-Wi-Fi, שנדרשת לה הרשאה
ACCESS_FINE_LOCATION
. -
גישה מוגבלת להגדרות ה-Wi-Fi
- אפליקציות לא יכולות יותר להפעיל או להשבית את ה-Wi-Fi ישירות, וצריך לעשות זאת באמצעות לוחות ההגדרות.
-
הגבלות על התחלת חיבור לרשת Wi-Fi, שמחייבות להשתמש ב-
WifiNetworkSpecifier
או ב-WifiNetworkSuggestion
.
-
אחסון ברמת ההיקף
מעבר מ-Android 10 (רמת API 29) ל-Android 11 (רמת API 30)
-
פרטיות
- אכיפת אחסון ברמת ההיקף : אפליקציות צריכות להשתמש במודל אחסון ברמת ההיקף, שבו קבצים ספציפיים לאפליקציה, קבצי מדיה וסוגים אחרים של קבצים נשמרים ומנוהלים במיקומים ייעודיים.
- איפוס אוטומטי של הרשאות: אם המשתמשים לא ניהלו אינטראקציה עם אפליקציה במשך כמה חודשים, המערכת מאפסת באופן אוטומטי את ההרשאות הרגישות של האפליקציה. רוב האפליקציות לא יושפעו מכך. אם האפליקציה פועלת בעיקר ברקע בלי אינטראקציות של משתמשים, כדאי לבקש מהמשתמשים להשבית את האיפוס האוטומטי.
- גישה למיקום ברקע: אפליקציות צריכות לבקש הרשאת מיקום בחזית וברקע בנפרד. ניתן להעניק גישה להרשאת מיקום ברקע רק בהגדרות האפליקציה, במקום בתיבת דו-שיח של הרשאה בזמן ריצה.
-
הרשאות גישה לחבילה: כשאפליקציה שולחת שאילתה לקבלת רשימת האפליקציות והשירותים המותקנות במכשיר, הרשימה המוחזרת מסוננת.
- אם אתם משתמשים בשירותי המרת טקסט לדיבור או בשירותי זיהוי דיבור, תצטרכו להוסיף רכיבי שאילתות לשירותים לקובץ המניפסט.
-
אבטחה
- קבצים דחוסים מסוג resource.arsc כבר לא נתמכים
- צריך עכשיו להשתמש בגרסה 2 של חתימת APK. מטעמי תאימות לאחור, המפתחים צריכים להמשיך לחתום גם באמצעות APK Signature Scheme v1.
- הגבלה על ממשק שאינו ב-SDK. לא מומלץ להשתמש בממשקים שאינם ב-SDK באפליקציות שמטרגטות רמת API 30, כי חלק מהממשקים האלה שאינם ב-SDK חסומים עכשיו. בקישור ממשקים שאינם ב-SDK שחוסמים עכשיו ב-Android 11 מופיעה רשימה מקיפה של ממשקים שאינם ב-SDK שחוסמים עכשיו.
רשימה מקיפה של השינויים שהוצגו ב-Android 11 (רמת API 30) מופיעה בדף שינויים בהתנהגות.
כדי להמשיך לעדכן ל-API 31, פועלים לפי ההוראות שמפורטות בקטע הקודם.
מודרניזציה של האפליקציות
כשאתם מעדכנים את רמת ה-API לטירגוט של האפליקציות, כדאי לשקול להשתמש בתכונות העדכניות של הפלטפורמה כדי לעדכן את האפליקציות ולשמח את המשתמשים.
- כדאי להשתמש ב-camX, שנמצא בגרסת בטא, כדי להפיק את המקסימום מהמצלמה.
- אתם יכולים להשתמש ברכיבים של Jetpack כדי לפעול לפי שיטות מומלצות, להימנע מכתיבת קוד סטנדרטי ולפשט משימות מורכבות, וכך להתמקד בקוד שחשוב לכם.
- שימוש ב-Kotlin כדי לכתוב אפליקציות טובות יותר מהר יותר ובפחות קוד.
- חשוב לוודא שאתם פועלים בהתאם לדרישות ולשיטות המומלצות בנושא פרטיות.
- הוספת תמיכה בעיצוב כהה לאפליקציות.
- מוסיפים לאפליקציות תמיכה בניווט באמצעות תנועות.
- להעביר את האפליקציה מ-Google Cloud Messaging (GCM) לגרסה האחרונה של העברת הודעות בענן ב-Firebase.
- ניהול חלונות מתקדם.
- תמיכה ביחסי גובה-רוחב גדולים יותר (יותר מ-16:9) כדי לנצל את השיפורים האחרונים בחומרה. חשוב לוודא שהאפליקציה משתנה לגודל שמתאים למסך. כדאי להצהיר על יחס גובה-רוחב מקסימלי רק במקרה הצורך. למידע נוסף על יחס גובה-רוחב מקסימלי, ראו הצהרה על תמיכה במסכים מוגבלים.
- מומלץ להוסיף תמיכה בריבוי חלונות כדי לשפר את הפרודוקטיביות באפליקציה ולנהל מסכים מרובים.
- אם חוויית שימוש מינימלית באפליקציה תשפר את חוויית המשתמש, כדאי להוסיף תמיכה בתמונה בתוך תמונה.
- אופטימיזציה למכשירים עם מגרעת במסך.
- לא להניח את גובה שורת הסטטוס. במקום זאת, צריך להשתמש ב-
WindowInsets
וב-View.OnApplyWindowInsetsListener
. למידע נוסף, ראו את הסרטון droidcon NYC 2017. להסבר. - אל תניחו שהאפליקציה תופסת את כל החלון. במקום זאת, צריך לאשר את המיקום באמצעות
View.getLocationInWindow()
ולא באמצעותView.getLocationOnScreen()
. * כשעובדים עםMotionEvent
, צריך להשתמש ב-MotionEvent.getX()
וב-MotionEvent.getY()
, ולא ב-MotionEvent.getRawX()
וב-MotionEvent.getRawY()
.
בדיקה ועדכון של ערכות ה-SDK והספריות
מוודאים שיחסי התלות של ערכות ה-SDK של הצד השלישי תומכים ב-API 31: חלק מספקי ה-SDK מפרסמים אותו במניפסט שלהם, באחרים יהיה צורך בבדיקה נוספת. אם משתמשים ב-SDK שלא תומך ב-API 31, חשוב לתת עדיפות גבוהה יותר לעבודה עם ספק ה-SDK כדי לפתור את הבעיה.
בנוסף, חשוב לשים לב שה-targetSdkVersion
של האפליקציה או המשחק עשוי להגביל את הגישה לספריות פרטיות של פלטפורמת Android. לפרטים נוספים, ראו קישור של אפליקציות ב-NDK לספריות פלטפורמה.
חשוב גם לבדוק אם יש הגבלות שאולי קיימות בגרסה של ספריית התמיכה ב-Android שבה משתמשים. כמו תמיד, עליכם לוודא את התאימות בין הגרסה הראשית של Android Support Library לבין compileSdkVersion
של האפליקציה.
מומלץ לבחור ערך ל-targetSdkVersion
שקטן או שווה לגרסה הראשית של ספריית התמיכה. מומלץ לעדכן לספריית תמיכה תואמת מהדורת 2018 כדי ליהנות מתכונות התאימות ותיקוני הבאגים העדכניים ביותר.
בדיקת האפליקציה
אחרי שמעדכנים את רמת ה-API ואת התכונות של האפליקציה בהתאם, כדאי לבדוק כמה תרחישים לדוגמה של שימוש. ההצעות הבאות הן חלקיות, אבל הן נועדו להנחות אתכם בתהליך הבדיקה. מומלץ לבדוק את האפשרויות הבאות:
- שהאפליקציה שלכם מקובצת ל-API 29 ללא שגיאות או אזהרות.
לאפליקציה יש אסטרטגיה למקרים שבהם המשתמש דוחה בקשות להרשאות ומבקש ממנו הרשאות. לשם כך:
- עוברים למסך 'פרטי האפליקציה' של האפליקציה ומשביתים כל הרשאה.
- פותחים את האפליקציה ומוודאים שהיא לא קורסת.
- מבצעים בדיקות של תרחישים לדוגמה לשימוש ולודא שההרשאות הנדרשות מופיעות שוב.
טיפול ב-Doze עם תוצאות צפויות וללא שגיאות.
- באמצעות adb, יש למקם את מכשיר הבדיקה ב-Doze בזמן שהאפליקציה פועלת.
- לבדוק תרחישים לדוגמה שמפעילים הודעות בענן ב-Firebase.
- בדיקת תרחישים לדוגמה שבהם נעשה שימוש בהתראות או במשימות.
- להימנע מכל יחסי תלות בשירותי רקע.
- הגדרת האפליקציה למצב 'המתנה לאפליקציה'
- בודקים תרחישים לדוגמה שמפעילים הודעות של Firebase Cloud Messaging.
- מומלץ לבדוק תרחישים לדוגמה של התראות.
- באמצעות adb, יש למקם את מכשיר הבדיקה ב-Doze בזמן שהאפליקציה פועלת.
טיפול בתמונות או בסרטונים חדשים שצולמו
- בודקים שהאפליקציה מטפלת בצורה נכונה בשידורים המוגבלים
ACTION_NEW_PICTURE
ו-ACTION_NEW_VIDEO
(כלומר, שהם מועברים למשימות של JobScheduler). - מוודאים שכל התרחישים לדוגמה הקריטיים שתלויים באירועים האלה עדיין פועלים.
- בודקים שהאפליקציה מטפלת בצורה נכונה בשידורים המוגבלים
טיפול בשיתוף קבצים עם אפליקציות אחרות - בדיקת כל תרחיש לדוגמה שבו מתבצע שיתוף של נתוני קבצים עם אפליקציה אחרת (גם עם אפליקציה אחרת של אותו מפתח)
- בודקים שהתוכן גלוי באפליקציה השנייה ולא גורם לקריסות.
מידע נוסף
להביע הסכמה לקבלת אימיילים ב-Google Play Console כדי שנוכל לשלוח לכם עדכונים והודעות חשובות מ-Android ומ-Google Play, כולל ניוזלטר חודשי לשותפים.