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

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

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

• אפליקציות חדשות ועדכוני אפליקציות חייבים לטרגט ל-Android 15 (רמת API‏ 35) ומעלה כדי להישלח אל Google Play, למעט אפליקציות ל-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 של האפליקציה, כמו שמתואר במאמר הגדרת ה-build. אפשר גם להשתמש במאפיין 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 כדי לתזמן ולהתחיל עבודה מזורזת בזמן שהאפליקציה פועלת ברקע. כדי להשלים פעולות רגישות לזמן שהמשתמש מבקש, צריך להפעיל שירותים שפועלים בחזית במסגרת התראה מדויקת.

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

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

• נמנום ואפליקציה במצב המתנה

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

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

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

מעבר מ-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)

• פרטיות
  • אכיפה של אחסון בהיקף מוגבל : אפליקציות צריכות לאמץ את מודל האחסון בהיקף מוגבל, שבו נשמרים קבצים ספציפיים לאפליקציה, קובצי מדיה וסוגים אחרים של קבצים, ומתבצעת גישה אליהם באמצעות מיקומים ייעודיים.
  • איפוס אוטומטי של הרשאות: אם משתמשים לא יצרו אינטראקציה עם אפליקציה במשך כמה חודשים, המערכת מאפסת אוטומטית את ההרשאות הרגישות של האפליקציה. השינוי הזה לא אמור להשפיע על רוב האפליקציות. אם האפליקציה שלכם פועלת בעיקר ברקע בלי אינטראקציות עם המשתמשים, כדאי לבקש מהמשתמשים להשבית את האיפוס האוטומטי.
  • גישה למיקום ברקע: אפליקציות צריכות לבקש הרשאת גישה למיקום בחזית וברקע בנפרד. אפשר להעניק גישה להרשאת מיקום ברקע רק בהגדרות האפליקציה ולא בתיבות דו-שיח של הרשאות בזמן ריצה.
  • חשיפת חבילות: כשמתבצעת שאילתה באפליקציה לגבי רשימת האפליקציות והשירותים המותקנים במכשיר, הרשימה שמוחזרת מסוננת.
    • אם אתם משתמשים בשירותים של המרת טקסט לדיבור או של זיהוי דיבור, תצטרכו להוסיף רכיבי שאילתות לשירותים לקובץ המניפסט.
• אבטחה
  • קבצים דחוסים של `resource.arsc` כבר לא נתמכים
  • נדרש עכשיו APK Signature Scheme v2. מסיבות שקשורות לתאימות לאחור, מפתחים צריכים להמשיך לחתום גם באמצעות APK Signature Scheme v1.
  • הגבלה על ממשק שאינו SDK. לא מומלץ להשתמש בממשקים שאינם ב-SDK באפליקציות שמיועדות לרמת API‏ 30 ומטה, כי חלק מהממשקים האלה חסומים עכשיו. במאמר הזה יש רשימה מקיפה של ממשקים שאינם SDK שנחסמו ב-Android 11.

רשימה מלאה של השינויים שהוצגו ב-Android 11 (רמת API‏ 30) מופיעה בדף שינויים בהתנהגות.

כדי להמשיך לעדכן לגרסה 31 של API, פועלים לפי ההוראות בקטע הקודם.

מודרניזציה של האפליקציות

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

• כדאי להשתמש ב-CameraX, שנמצאת בשלב הבטא, כדי להפיק את המרב מהשימוש במצלמה.
• אפשר להשתמש ברכיבי Jetpack כדי לפעול לפי שיטות מומלצות, להימנע מכתיבת קוד boilerplate ולפשט משימות מורכבות, וכך להתמקד בקוד שחשוב לכם.
• אפשר להשתמש ב-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 שקטן או שווה לגרסה הראשית של Support Library. מומלץ לעדכן לספריית תמיכה תואמת עדכנית כדי ליהנות מהתכונות העדכניות של התאימות ומהתיקונים של הבאגים.

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

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

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

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

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

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

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

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

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

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

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

מידע נוסף

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