כשמעלים APK, הוא צריך לעמוד ברמת ה-API המטורגטת של Google Play הדרישות.
החל מ-31 באוגוסט 2024:
- אפליקציות חדשות ועדכוני אפליקציות חדשים צריכים לטרגט ל-Android 14 (רמת API 34) ואילך כדי נשלחו אל Google Play. מלבד אפליקציות ל-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.
למה כדאי לטרגט ערכות 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 ב-AI. - מיקום: המשתמשים יכולים לבקש מאפליקציות לאחזר את המיקום המשוער בלבד
מידע. עליך לבקש את ההרשאה ל-
ACCESS_COARSE_LOCATIONבכל פעם שמבקשיםACCESS_FINE_LOCATION.- מסנני Intent: אם האפליקציה שלכם כוללת פעילויות, שירותים, או מקלטי שידורים שמשתמשים במסנני כוונה, עליך להצהיר באופן מפורש על המאפיין android:exported עבור רכיבים.
- מצב תנומה: ניתן להעביר אפליקציות למצב תנומה אם לא משתמשים בהן במשך פרק זמן מסוים. במצב תנומה, ההרשאות של האפליקציה בזמן הריצה המטמון מתאפס ואי אפשר להריץ משימות או התראות. אפשר לבדוק את האפליקציה סטטוס תנומה.
- שינויי Intent בהמתנה: צריך לציין את יכולת השינוי של כל אחד מהם. אובייקט PendingIntent שהאפליקציה שלכם יוצרת.
חוויית המשתמש
- התראות בהתאמה אישית: לא יתבצע התראות עם צפיות בתוכן בהתאמה אישית
להשתמש יותר באזור ההודעות, במקום זאת, המערכת מחילה
תבנית סטנדרטית. התבנית הזו מבטיחה שההתראות בהתאמה אישית כוללות את
קישוטים זהים לאלה של הודעות אחרות בכל המדינות. מה קורה?
כמעט זהה להתנהגות של
Notification.DecoratedCustomViewStyle. - שינויים באימות קישורים לאפליקציות ל-Android: כשמשתמשים ב-Android App Link יש לוודא שמסנני Intent כוללים את הפונקציה BROWSABLE. קטגוריה ותומכים בסכמת HTTPS.
ביצועים
הגבלות השקה של שירות שפועל בחזית: כדי לטרגט את Android 12 או גבוהה יותר, האפליקציה לא יכולה להפעיל שירותים שפועלים בחזית בזמן שהיא פועלת למעט כמה מקרים מיוחדים. אם אפליקציה מנסה להפעיל שירות שפועל ברקע בזמן שהוא פועל ברקע, קיימת חריגה (למעט מקרים מיוחדים).
כדאי להשתמש ב-WorkManager כדי לתזמן ולהתחיל עבודה מזורזת במהלך שהאפליקציה רצה ברקע. כדי להשלים פעולות דחופות בזמן בקשות ממשתמשים, הפעלת שירותים שפועלים בחזית תוך התראה מדויקת.
הגבלות על טרמפולינה של התראות: כשהמשתמשים מקישים על התראות, חלק מהאפליקציות מגיבות על ידי הפעלה של רכיב באפליקציה שמתחיל את הפעילות שהמשתמש רואה ומקיים איתם אינטראקציה. רכיב האפליקציה הזה נקרא טרמפולינה של התראות.
אסור לאפליקציות להתחיל פעילויות משירותים או ממקלטי שידור שהם ששימשו כטרמפולינות להתראות. אחרי שמשתמש מקיש על התראה או לחצן הפעולה בתוך ההתראה, האפליקציה לא יכולה להתקשר
startActivity()בתוך שירות או מקלט שידורים.
לעיון בקבוצה המלאה של השינויים שמשפיעים על אפליקציות שמטרגטות ל-Android 12 (API) רמה 31).
העברה מגרסה נמוכה מ-Android 11 (רמת API 30)
בוחרים את גרסת Android שממנה תתבצע ההעברה:
העברה ל-Android 5 (רמת API 21)
יש לעיין בדף 'שינויים בהתנהגות' המתאים לכל אחת מהגרסאות הבאות, כדי לוודא שהאפליקציה שלך מביאה בחשבון שינויים שנוספו בגרסאות האלה:
כדי להמשיך, פועלים לפי ההוראות שבקטע הבא.
העברה ל-Android 6 (רמת API 23)
השיקולים הבאים חלים על אפליקציות שמטרגטות את Android 6.0 ואילך של הפלטפורמה:
-
-
הרשאות מסוכנות מוענקות רק בזמן ריצה. תהליכי ממשק המשתמש שלכם חייבים להשתלם כדי להעניק את ההרשאות האלה.
-
במידת האפשר, יש לוודא שהאפליקציה מוכנה לטיפול בדחייה של בקשות הרשאה. לדוגמה, אם משתמש דוחה בקשה לקבלת גישה ל-GPS של המכשיר, צריך לוודא שלאפליקציה יש דרך אחרת להמשיך.
-
לרשימה מקיפה של השינויים שהושקו ב-Android 6.0 (רמת API 23), ראו שינויים בהתנהגות. עבור גרסת הפלטפורמה הזו.
כדי להמשיך, פועלים לפי ההוראות שבקטע הבא.
העברה ל-Android 7 (רמת API 24)
השיקולים הבאים חלים על אפליקציות שמטרגטות את Android 7.0 ואילך של הפלטפורמה:
-
מצב 'נמנום' ו'אפליקציה במצב המתנה'
עיצוב להתנהגויות שמתוארות במאמר אופטימיזציה ל'נמנום' ול-App Standby, שכולל שינויים מצטברים שהושקו במספר גרסאות פלטפורמה.
כשהמכשיר במצב 'נמנום' ו'מצב המתנה של אפליקציה', המערכת פועלת באופן הבא:
- הגישה לרשת מוגבלת
- דחייה של התראות, סנכרונים ועבודות
- הגבלת GPS וסריקות Wi-Fi
- הגבלת העדיפות הרגילה העברת הודעות בענן ב-Firebase הודעות.
-
שינויים בהרשאות
- המערכת מגבילה את הגישה לספריות פרטיות של אפליקציות.
-
חשיפת URI של
file://מחוץ לאפליקציה גורמת להפעלתFileUriExposedException. אם צריך לשתף קבצים עם גורמים מחוץ לאפליקציה, צריך להטמיעFileProvider
-
המערכת אוסרת על קישור לספריות שאינן NDK.
לרשימה מקיפה של השינויים שהוצגו ב-Android 7.0 (רמת API 24), אפשר לעיין במאמר שינויים בהתנהגות. עבור גרסת הפלטפורמה הזו.
כדי להמשיך, פועלים לפי ההוראות שבקטע הבא.
העברה ל-Android 8 (רמת API 26)
השיקולים הבאים חלים על אפליקציות שמטרגטות את Android 8.0 ואילך של הפלטפורמה:
-
מגבלות ביצוע ברקע
-
המערכת מגבילה שירותים לאפליקציות שלא פועלים בחזית.
-
עכשיו,
startService()מקפיצה הודעת שגיאה כשאפליקציה מנסה להפעיל אותה בזמן ש-startService()אסורה. -
כדי להפעיל שירותים שפועלים בחזית, האפליקציה צריכה להשתמש ב-
startForeground()וגםstartForegroundService() - יש לקרוא בעיון את השינויים שבוצעו ב-JobScheduler API, כפי שמתואר בדף 'שינויים בהתנהגות' של Android 8.0 (רמת API 26).
- כדי להשתמש ב- Firebase Cloud Messaging צריך גרסה 10.2.1 מ- Google Play Services SDK ואילך.
- כשמשתמשים ב העברת הודעות בענן ב-Firebase, העברת ההודעות כפופה למגבלות ביצוע ברקע. כאשר נדרשת עבודת רקע עם קבלת ההודעה, כגון כדי לבצע סנכרון של נתוני רקע, האפליקציה צריכה לתזמן משימות באמצעות Firebase Job Dispatcher או JobIntentService. מידע נוסף זמין במאמר משאבי עזרה להעברת הודעות בענן ב-Firebase
-
עכשיו,
-
שידורים מרומזים
-
קיימות הגבלות על שידור מרומז. לקבלת מידע על טיפול באירועי רקע, כדאי לעיין במסמכים של ה-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 המטורגטת של האפליקציות, כדאי להשתמש ב תכונות פלטפורמה שנועדו לעדכן את האפליקציות שלכם ולהפוך את המשתמשים לשביעות רצון.
- כדאי להשתמש ב-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
compileSdkVersion של האפליקציה.
מומלץ לבחור targetSdkVersion קטן מ- או שווה ל-
גרסה הראשית של ספריית התמיכה. מומלץ לעדכן
כדי ליהנות מהיתרונות של
של תכונות תאימות ותיקוני באגים.
בדיקת האפליקציה
אחרי שתעדכנו את רמת ה-API והתכונות של האפליקציה לפי הצורך, לבדוק כמה תרחישים עיקריים לדוגמה. ההצעות הבאות הן חלקיות, אבל כדאי שמנחים את תהליך הבדיקה. מומלץ לבדוק:
- שהאפליקציה עוברת הידור (compile) ל-API 29 ללא שגיאות או אזהרות.
לאפליקציה יש אסטרטגיה למקרים שבהם המשתמש דחה את ההרשאה ומבקש מהמשתמש הרשאות. לשם כך:
- עוברים למסך 'פרטי האפליקציה' באפליקציה ומשביתים כל אחת מההרשאות.
- פותחים את האפליקציה ומוודאים שאין קריסות.
- מבצעים בדיקות של תרחישי שימוש מרכזיים ומוודאים שההרשאות הנדרשות בהנחיות מחדש.
התכונה 'נמנום' עם תוצאות צפויות וללא שגיאות.
- באמצעות adb, יש למקם את מכשיר הבדיקה ב-Doze בזמן שהאפליקציה פועלת.
- לבדוק תרחישים לדוגמה שמפעילים הודעות בענן ב-Firebase.
- כדאי לבדוק תרחישים לדוגמה של התראות או משימות.
- מבטלים תלות בשירותי רקע.
- הגדרת האפליקציה למצב המתנה
- לבדוק תרחישים לדוגמה שמפעילים הודעות בענן ב-Firebase.
- מומלץ לבדוק תרחישים לדוגמה של התראות.
- באמצעות adb, יש למקם את מכשיר הבדיקה ב-Doze בזמן שהאפליקציה פועלת.
טיפול בתמונות / סרטונים חדשים שמצלמים
- בודקים שהאפליקציה מטפלת בבעיות מוגבלות
שידורים של
ACTION_NEW_PICTUREוACTION_NEW_VIDEOבצורה נכונה (כלומר, הועבר למשימות של JobScheduler). - לוודא שתרחישים קריטיים לדוגמה שתלויים באירועים האלה עדיין בעבודה.
- בודקים שהאפליקציה מטפלת בבעיות מוגבלות
שידורים של
ניהול שיתוף קבצים עם אפליקציות אחרות - לבדוק תרחישים לדוגמה שמשתפים נתוני קבצים עם אפליקציות אחרות (גם אפליקציה אחרת של אותו מפתח)
- בדיקה שהתוכן גלוי באפליקציה האחרת ולא מופעל קריסות.
מידע נוסף
להביע הסכמה לקבלת אימיילים ב-Google Play Console כדי שנוכל לשלוח לך עדכונים חשובים והודעות מ-Android ומ-Google Play, כולל הניוזלטר החודשי שלנו לשותפים.