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

כשאתם מעלים קובץ 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)

אבטחה והרשאות

חוויית משתמש

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

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

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

רשימה מקיפה של השינויים שהוצגו ב-Android 9.0 (רמת API 28) מפורטת בקטע שינויים בהתנהגות.

מעבר מ-Android 9 (רמת API 28) ל-Android 10 (רמת API 29)

מעבר מ-Android 10 (רמת API 29) ל-Android 11 (רמת API 30)

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

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

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

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

  • כדאי להשתמש ב-camX, שנמצא בגרסת בטא, כדי להפיק את המקסימום מהמצלמה.
  • אתם יכולים להשתמש ברכיבים של Jetpack כדי לפעול לפי שיטות מומלצות, להימנע מכתיבת קוד סטנדרטי ולפשט משימות מורכבות, וכך להתמקד בקוד שחשוב לכם.
  • שימוש ב-Kotlin כדי לכתוב אפליקציות טובות יותר מהר יותר ובפחות קוד.
  • חשוב לוודא שאתם פועלים בהתאם לדרישות ולשיטות המומלצות בנושא פרטיות.
  • הוספת תמיכה בעיצוב כהה לאפליקציות.
  • מוסיפים לאפליקציות תמיכה בניווט באמצעות תנועות.
  • להעביר את האפליקציה מ-Google Cloud Messaging ‏ (GCM) לגרסה האחרונה של העברת הודעות בענן ב-Firebase.
  • ניהול חלונות מתקדם.

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

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

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

מידע נוסף

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