כשאתם מעלים קובץ 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 ולמצב המתנה של אפליקציות, שכולל שינויים מצטברים שהוצגו במספר גרסאות של הפלטפורמה.
כשמכשיר נמצא במצב Doze ובמצב המתנה של אפליקציות, המערכת פועלת באופן הבא:
- הגבלת הגישה לרשת
- דחייה של התראות, סנכרון ומשימות
- הגבלת סריקות GPS ו-Wi-Fi
- הגבלת הודעות Firebase Cloud Messaging ברמת עדיפות רגילה.
-
שינויים בהרשאות
- המערכת מגבילה את הגישה לספריות פרטיות של אפליקציות.
-
חשיפת URI של
file://מחוץ לאפליקציה מפעילהFileUriExposedException. אם אתם צריכים לשתף קבצים מחוץ לאפליקציה, צריך להטמיע את הקודFileProvider
-
המערכת אוסרת על קישור לספריות שאינן NDK.
רשימה מקיפה של השינויים שהוצגו ב-Android 7.0 (רמת API 24) מופיעה בדף שינויים בהתנהגות לגרסה הזו של הפלטפורמה.
ממשיכים לפי ההוראות שבקטע הבא.
מעבר ל-Android 8 (רמת API 26)
השיקולים הבאים רלוונטיים לאפליקציות שמטרגטות את גרסת Android 8.0 ואילך של הפלטפורמה:
-
מגבלות על ביצוע ברקע
-
המערכת מגבילה את השירותים של אפליקציות שלא פועלות בחזית.
-
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)
-
התראות עם כוונה במסך מלא
-
צריך לבקש את ההרשאה הרגילה
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 כבר לא נתמכים
- עכשיו נדרשת סכמת החתימה APK Signature Scheme v2. מטעמי תאימות לאחור, המפתחים צריכים להמשיך לחתום גם באמצעות APK Signature Scheme v1.
- הגבלה על ממשק שאינו ב-SDK. לא מומלץ להשתמש בממשקים שאינם ב-SDK באפליקציות שמטרגטות רמת API 30, כי חלק מהממשקים האלה שאינם ב-SDK חסומים עכשיו. בקישור ממשקים שאינם ב-SDK שחוסמים עכשיו ב-Android 11 מופיעה רשימה מקיפה של ממשקים שאינם ב-SDK שחוסמים עכשיו.
רשימה מקיפה של השינויים שהוצגו ב-Android 11 (רמת API 30) מופיעה בדף שינויים בהתנהגות.
ממשיכים לעדכן ל-API 31 לפי ההוראות שמפורטות בקטע הקודם.
מודרניזציה של האפליקציות
כשאתם מעדכנים את רמת ה-API לטירגוט של האפליקציות, כדאי לשקול להשתמש בתכונות העדכניות של הפלטפורמה כדי לעדכן את האפליקציות ולשמח את המשתמשים.
- כדי להפיק את המקסימום מהשימוש במצלמה, כדאי להשתמש ב-CameraX, שעדיין נמצאת בגרסת בטא.
- אתם יכולים להשתמש ברכיבים של 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 שקטן או שווה לגרסה הראשית של Support Library. מומלץ לעדכן לספריית תמיכה תואמת מהדורת 2018 כדי ליהנות מתכונות התאימות ותיקוני הבאגים העדכניים ביותר.
בדיקת האפליקציה
אחרי שמעדכנים את רמת ה-API ואת התכונות של האפליקציה בהתאם, כדאי לבדוק כמה תרחישים לדוגמה של שימוש. ההצעות הבאות הן חלקיות, אבל הן נועדו להנחות אתכם בתהליך הבדיקה. מומלץ לבדוק את האפשרויות הבאות:
- שהאפליקציה שלכם מקובצת ל-API 29 ללא שגיאות או אזהרות.
לאפליקציה יש אסטרטגיה למקרים שבהם המשתמש דוחה בקשות להרשאות, והיא מבקשת מהמשתמש הרשאות. לשם כך:
- עוברים למסך 'פרטי האפליקציה' של האפליקציה ומשביתים כל הרשאה.
- פותחים את האפליקציה ומוודאים שהיא לא קורסת.
- מבצעים בדיקות של תרחישים לדוגמה לשימוש ולודא שההרשאות הנדרשות מופיעות שוב.
טיפול ב-Doze עם תוצאות צפויות וללא שגיאות.
- באמצעות adb, מעבירים את מכשיר הבדיקה למצב Doze בזמן שהאפליקציה פועלת.
- בודקים תרחישים לדוגמה שמפעילים הודעות של Firebase Cloud Messaging.
- בודקים תרחישים לדוגמה שבהם נעשה שימוש בהתראות או במשימות.
- להימנע מכל יחסי תלות בשירותי רקע.
- הגדרת האפליקציה למצב 'המתנה לאפליקציה'
- בודקים תרחישים לדוגמה שמפעילים הודעות של Firebase Cloud Messaging.
- בודקים את כל תרחישי השימוש שבהם נעשה שימוש בהתראות.
- באמצעות adb, מעבירים את מכשיר הבדיקה למצב Doze בזמן שהאפליקציה פועלת.
טיפול בתמונות או בסרטונים חדשים שצולמו
- בודקים שהאפליקציה מטפלת בצורה נכונה בשידורים המוגבלים
ACTION_NEW_PICTUREו-ACTION_NEW_VIDEO(כלומר, שהם מועברים למשימות של JobScheduler). - מוודאים שכל התרחישים לדוגמה הקריטיים שתלויים באירועים האלה עדיין פועלים.
- בודקים שהאפליקציה מטפלת בצורה נכונה בשידורים המוגבלים
טיפול בשיתוף קבצים עם אפליקציות אחרות - בדיקת כל תרחיש לדוגמה שבו מתבצע שיתוף של נתוני קבצים עם אפליקציה אחרת (גם עם אפליקציה אחרת של אותו מפתח)
- בודקים שהתוכן גלוי באפליקציה השנייה ולא גורם לקריסות.
מידע נוסף
להביע הסכמה לקבלת אימיילים ב-Google Play Console כדי שנוכל לשלוח לכם עדכונים והודעות חשובות מ-Android ומ-Google Play, כולל ניוזלטר חודשי לשותפים.