לעמוד בדרישה לגבי רמת ה-API לטירגוט של Google Play

כשמעלים קובץ APK, הוא צריך לעמוד בדרישות של Google Play בנושא רמת ה-API לטירגוט.

החל מ-31 באוגוסט 2025:

• כדי לשלוח אפליקציות חדשות ועדכונים לאפליקציות ל-Google Play, צריך לטרגט ל-Android 15 (רמת API 35) ומעלה. הדרישה הזו לא חלה על אפליקציות ל-Wear OS, ל-Android Automotive OS ול-Android TV, שצריך לטרגט ל-Android 14 (רמת API 34) ומעלה.
• אפליקציות קיימות צריכות לטרגט ל-Android 14 (רמת API‏ 34) או לגרסה מתקדמת יותר כדי להמשיך להיות זמינות למשתמשים חדשים במכשירים שפועלת בהם מערכת Android OS בגרסה מתקדמת יותר מרמת ה-API לטירגוט של האפליקציה. אפליקציות שמטרגטות ל-Android 13 (רמת API ‏33) או לגרסאות קודמות, כולל Android 12 (רמת API ‏31) או לגרסאות קודמות ל-Wear OS ול-Android TV, יהיו זמינות רק במכשירים שפועלת בהם מערכת Android OS באותה רמה או ברמה נמוכה יותר מרמת ה-API לטירגוט של האפליקציה.

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

היוצאים מן הכלל לדרישות האלה כוללים:

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

הערה: אפליקציות לא עדכניות לא זמינות למשתמשים חדשים במכשירים שפועלות בהם גרסאות חדשות יותר של Android. מידע נוסף זמין בקטע 'דרישות הזמינות של האפליקציה' במאמר דרישות רמת ה-API לטירגוט של אפליקציות ל-Google Play במרכז העזרה של Play Console.

למה כדאי לטרגט גרסאות חדשות יותר של SDK?

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

הגדרת האפליקציה לטירגוט רמת API עדכנית מבטיחה שהמשתמשים יוכלו ליהנות מהשיפורים האלה, ושהאפליקציה עדיין תוכל לפעול בגרסאות Android ישנות יותר. בנוסף, טירגוט רמת API עדכנית מאפשר לאפליקציה לנצל את התכונות האחרונות של הפלטפורמה כדי לספק חוויה נהדרת למשתמשים. בנוסף, החל מ-Android 10 (רמת API ‏29), משתמשים רואים אזהרה כשהם מפעילים אפליקציה בפעם הראשונה אם האפליקציה מטרגטת את Android 5.1 (רמת API ‏22) או גרסאות קודמות.

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

הערה: אם קובץ Gradle מכיל רשומות מניפסט, אפשר לאשר או לשנות את הערך הנוכחי של targetSdkVersion בקובץ Gradle של האפליקציה, כמו שמתואר במאמר הגדרת תהליך הבנייה. אפשר גם להשתמש במאפיין android:targetSdkVersion בקובץ המניפסט, כמו שמתואר במסמכי התיעוד של רכיב המניפסט <uses-sdk>.

מעבר מ-Android 12 ומגרסאות חדשות יותר (רמת API‏ 31) לגרסה עדכנית יותר

כדי לעדכן את האפליקציה כך שתטרגט לגרסה עדכנית יותר של Android, צריך לפעול לפי רשימת שינויי ההתנהגות הרלוונטית:

• שינויים בהתנהגות ב-Android 13
• שינויים בהתנהגות ב-Android 14
• שינויים בהתנהגות ב-Android 15
• שינויים בהתנהגות ב-Android 16

מעבר מ-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 כדי לתזמן ולהתחיל עבודה מזורזת בזמן שהאפליקציה פועלת ברקע. כדי להשלים פעולות רגישות לזמן שהמשתמש מבקש, צריך להפעיל שירותים בחזית האפליקציה במסגרת התראה מדויקת.

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

  אסור לאפליקציות להפעיל פעילויות משירותים או מ-broadcast receivers שמשמשים כקרש קפיצה להודעות. אחרי שהמשתמש מקיש על התראה או על לחצן פעולה בתוך ההתראה, האפליקציה לא יכולה להתקשר אל startActivity() בתוך שירות או מקלט שידורים.

כאן אפשר לראות את כל השינויים שמשפיעים על אפליקציות שמטרגטות ל-Android 12 (רמת API‏ 31).

מעבר מגרסה נמוכה יותר מ-Android 11 (רמת API‏ 30)

בוחרים את הגרסה של Android שממנה רוצים להעביר את הנתונים:

מעבר ל-Android 5 (רמת API‏ 21)

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

• ‫Android 5.0 (רמת API‏: 21)
• ‫Android 4.4 (רמת API‏: 19).
• ‫Android 4.1.x (רמת API‏: 16).

ממשיכים לפי ההוראות שבקטע הבא.

מעבר ל-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 בעדיפות רגילה.

• שינויים בהרשאות

  • המערכת מגבילה את הגישה לספריות פרטיות של אפליקציות.
  • חשיפת file:// URI מחוץ לאפליקציה מפעילה FileUriExposedException. אם אתם צריכים לשתף קבצים מחוץ לאפליקציה, אתם צריכים להטמיע את FileProvider

• המערכת לא מאפשרת קישור לספריות שאינן NDK.

רשימה מלאה של השינויים שהוכנסו ב-Android 7.0 (רמת API‏ 24) מופיעה בדף שינויים בהתנהגות של גרסת הפלטפורמה הזו.

ממשיכים לפי ההוראות שבקטע הבא.

מעבר ל-Android 8 (רמת API‏ 26)

השיקולים הבאים רלוונטיים לאפליקציות שמטרגטות את Android 8.0 וגרסאות גבוהות יותר של הפלטפורמה:

• Background Execution Limits
  • המערכת מגבילה את השירותים לאפליקציות שלא פועלות בחזית.
    • ‫ startService() מעכשיו מקפיץ הודעת שגיאה (throw) לחריגה כשאפליקציה מנסה להפעיל אותו בזמן ש-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 Cloud Messaging.
  • הודעות מרומזות
    • שידורים משתמעים מוגבלים. מידע על טיפול באירועים שמתרחשים ברקע זמין במסמכי התיעוד של JobScheduler API.
  • מגבלות על מיקום ברקע
    • לאפליקציות שפועלות ברקע יש גישה מוגבלת לנתוני המיקום.
      • במכשירים עם Google Play Services, משתמשים ב ספק מיקום משולב כדי לקבל עדכוני מיקום תקופתיים.
• ערוצי התראות
  • מומלץ להגדיר מאפיינים של הפרעות בהתראות לכל ערוץ בנפרד.
  • כדי שההתראות יופיעו, צריך להקצות אותן לערוץ.
  • הגרסה הזו של הפלטפורמה תומכת ב- NotificationCompat.Builder.
• פרטיות
  • ההיקף של ANDROID_ID הוא לפי חתימת האפליקציה.

רשימה מלאה של השינויים שהוכנסו ב-Android 8.0 (רמת API‏ 26) מופיעה בדף שינויים בהתנהגות של גרסת הפלטפורמה הזו.

מעבר מ-Android 8‏ (API 26) ל-Android 9‏ (API 28)

• Power Management
  • דלי המתנה של אפליקציות מביאים הגבלות חדשות על פעילות ברקע על סמך האינטראקציה עם האפליקציה, כמו דחיית משימות, אזעקות ומכסות על הודעות בעדיפות גבוהה
  • שיפורים במצב חיסכון בסוללה הגברת ההגבלות על אפליקציות במצב המתנה
• הרשאה לשימוש בשירות שפועל בחזית
  • צריך לבקש את ההרשאה הרגילה 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 שמוסיף באופן אוטומטי מסגרת שחורה לאפליקציה ביחסי גובה-רוחב צרים יותר.
• שינויים בפרטיות
  • Scoped storage
    • הגישה לאחסון חיצוני מוגבלת רק לספרייה ספציפית לאפליקציה ולסוגים ספציפיים של מדיה שהאפליקציה יצרה.
  • הגישה למיקום מוגבלת כשהאפליקציה ברקע, נדרשת הרשאה 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)

• פרטיות
  • אכיפה של אחסון בהיקף מוגבל : אפליקציות צריכות לאמץ את מודל האחסון בהיקף מוגבל, שבו נשמרים סוגים של קבצים ספציפיים לאפליקציה, מדיה וסוגים אחרים של קבצים, ומתבצעת גישה אליהם באמצעות מיקומים ייעודיים.
  • איפוס אוטומטי של הרשאות: אם משתמשים לא יצרו אינטראקציה עם אפליקציה במשך כמה חודשים, המערכת מאפסת אוטומטית את ההרשאות הרגישות של האפליקציה. רוב האפליקציות לא אמורות להיות מושפעות. אם האפליקציה שלכם פועלת בעיקר ברקע בלי אינטראקציות עם המשתמשים, כדאי לבקש מהמשתמשים להשבית את האיפוס האוטומטי.
  • גישה למיקום ברקע: אפליקציות צריכות לבקש הרשאת גישה למיקום בחזית וברקע בנפרד. אפשר להעניק גישה להרשאת מיקום ברקע רק בהגדרות האפליקציה ולא בתיבות דו-שיח של הרשאה בזמן ריצה.
  • Package Visibility: כשמבוצעת באפליקציה שאילתה לגבי רשימת האפליקציות והשירותים המותקנים במכשיר, הרשימה שמוחזרת מסוננת.
    • אם אתם משתמשים בשירותים של המרת טקסט לדיבור או זיהוי דיבור, תצטרכו להוסיף לרשימת ההיתרים את רכיבי השאילתות של השירותים.
• אבטחה
  • קבצים דחוסים של `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 Apps Linking to Platform Libraries.

כדאי גם לבדוק אם יש הגבלות בגרסה של ספריית התמיכה של Android שבה אתם משתמשים. כמו תמיד, אתם צריכים לוודא שיש תאימות בין הגרסה הראשית של ספריית התמיכה של Android לבין compileSdkVersion של האפליקציה שלכם.

מומלץ לבחור targetSdkVersion שקטן או שווה לגרסה הראשית של Support Library. מומלץ לעדכן לספריית תמיכה תואמת עדכנית כדי ליהנות מהתכונות העדכניות של התאימות ומהתיקונים של הבאגים.

בדיקת האפליקציה

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

• שהאפליקציה עוברת קומפילציה ל-API ברמה 29 ללא שגיאות או אזהרות.

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

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

• הכינויים פועלים במצב Doze עם תוצאות צפויות וללא שגיאות.

  • באמצעות adb, מעבירים את מכשיר הבדיקה למצב שינה בזמן שהאפליקציה פועלת.
    • בודקים תרחישים לדוגמה שמפעילים הודעות של Firebase Cloud Messaging.
    • בודקים תרחישי שימוש שכוללים שעונים מעוררים או משימות.
    • צריך לבטל את כל יחסי התלות בשירותי רקע.
  • העברת האפליקציה למצב המתנה (App Standby)
    • בודקים תרחישים לדוגמה שמפעילים הודעות של Firebase Cloud Messaging.
    • בודקים תרחישי שימוש שבהם נעשה שימוש בהתראות.

• האפליקציה מטפלת בתמונות או בסרטונים חדשים שצולמו

  • בודקים שהאפליקציה מטפלת בשידורים המוגבלים ACTION_NEW_PICTURE וב ACTION_NEW_VIDEO בצורה נכונה (כלומר, הם הועברו למשימות JobScheduler).
  • מוודאים שתרחישי שימוש קריטיים שתלויים באירועים האלה עדיין פועלים.

• מטפל בשיתוף קבצים עם אפליקציות אחרות – בדיקת כל תרחיש שימוש שבו נתוני קבצים משותפים עם אפליקציה אחרת (גם אם מדובר באפליקציה אחרת של אותו מפתח)

  • בודקים שהתוכן גלוי באפליקציה השנייה ולא גורם לקריסות.

מידע נוסף

הצטרפות לקבלת אימיילים ב-Google Play Console כדי שנוכל לשלוח לכם עדכונים והודעות חשובים מ-Android ומ-Google Play, כולל הניוזלטר החודשי שלנו לשותפים.