שינויים בהתנהגות: אפליקציות שמטרגטות ל-Android 13 ואילך

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

חשוב גם לעיין ברשימת שינויי ההתנהגות שמשפיעים על כל האפליקציות שפועלות ב-Android 13.

פרטיות

ההרשאה לשליחת התראות משפיעה על המראה של שירות שפועל בחזית

אם המשתמש לא מאשר את הרשאת ההתראות, הוא לא יראה את ההודעות שקשורות לשירותים שפועלים בחזית במגירת ההתראות. עם זאת, המשתמשים עדיין רואים הודעות שקשורות לשירותים שפועלים בחזית במנהל המשימות, בלי קשר לשאלה אם הם העניקו את הרשאת ההתראה.

הרשאה חדשה בתחילת ההפעלה למכשירי Wi-Fi בקרבת מקום

בגרסאות קודמות של Android, המשתמש צריך להעניק לאפליקציה את ההרשאה ACCESS_FINE_LOCATION כדי להשלים כמה תרחישי שימוש נפוצים ב-Wi-Fi.

למשתמשים קשה לקשר בין הרשאות מיקום לבין פונקציונליות של Wi-Fi, ולכן ב-Android 13 (רמת API 33) מוצגת הרשאת זמן ריצה בקבוצת ההרשאות NEARBY_DEVICES לאפליקציות שמנהלות את החיבורים של המכשיר לנקודות גישה בקרבת מקום באמצעות Wi-Fi. ההרשאה הזו, NEARBY_WIFI_DEVICES, מאפשרת שימוש ב-Wi-Fi בתרחישים כמו:

  • חיפוש מכשירים בקרבת מקום, כמו מדפסות או מכשירים להפעלת Cast, והתחברות אליהם. תהליך העבודה הזה מאפשר לאפליקציה לבצע משימות מהסוגים הבאים:
    • קבלת מידע על נקודת הגישה מחוץ לפס, למשל באמצעות BLE.
    • איתור מכשירים והתחברות אליהם באמצעות Wi-Fi Aware, והתחברות באמצעות נקודה מקומית בלבד לשיתוף אינטרנט.
    • גילוי מכשירים והתחברות אליהם באמצעות Wi-Fi Direct.
  • התחלת חיבור ל-SSID מוכר, כמו רכב או מכשיר לבית חכם.
  • להפעיל נקודה מקומית בלבד לשיתוף אינטרנט.
  • הטווח של מכשירי Wi-Fi Aware בקרבת מקום.

כל עוד האפליקציה לא מפיקה מידע על מיקום פיזי מממשקי ה-API של Wi-Fi, צריך לבקש את ההרשאה NEARBY_WIFI_DEVICES במקום ACCESS_FINE_LOCATION כשמטרגטים ל-Android 13 ומעלה ומשתמשים בממשקי ה-API של Wi-Fi. כשמצהירים על ההרשאה NEARBY_WIFI_DEVICES, חשוב להדגיש שהאפליקציה אף פעם לא מפיקה מידע על מיקום פיזי מממשקי API של Wi-Fi. כדי לעשות זאת, מגדירים את המאפיין android:usesPermissionFlags לערך neverForLocation. התהליך הזה דומה לזה שמתבצע ב-Android 12 (API ברמה 31) ומעלה כשמצהירים שפרטי מכשיר Bluetooth אף פעם לא משמשים למיקום.

איך מבקשים הרשאה לגשת למכשירי Wi-Fi בקרבת מקום

הרשאות מפורטות למדיה

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

אם האפליקציה מטרגטת ל-Android 13 ומעלה וצריכה לגשת לקובצי מדיה שאפליקציות אחרות יצרו, עליך לבקש אחת או יותר מההרשאות המפורטות הבאות למדיה במקום ההרשאה READ_EXTERNAL_STORAGE:

סוג המדיה הרשאה לשליחת בקשות
תמונות READ_MEDIA_IMAGES
סרטונים READ_MEDIA_VIDEO
קובצי אודיו READ_MEDIA_AUDIO

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

איור 1 מציג אפליקציה שמבקשת את ההרשאה READ_MEDIA_AUDIO.

אם מבקשים גם את ההרשאה READ_MEDIA_IMAGES וגם את ההרשאה READ_MEDIA_VIDEO בו-זמנית, תופיע רק תיבת דו-שיח אחת של הרשאת מערכת.

אם לאפליקציה שלכם הוענקה בעבר ההרשאה READ_EXTERNAL_STORAGE, כל ההרשאות מסוג READ_MEDIA_* שנדרשות יוענקו לה אוטומטית במהלך השדרוג. אפשר להשתמש בפקודת ה-ADB הבאה כדי לבדוק את ההרשאות ששודרגו:

adb shell cmd appops get --uid PACKAGE_NAME

נדרשת הרשאה חדשה לשימוש בחיישנים לבישים ברקע

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

אם האפליקציה שלכם מטרגטת את Android 13 ונדרשת לה גישה למידע מחיישנים גופניים בזמן שהיא פועלת ברקע, אתם צריכים להצהיר על ההרשאה החדשה BODY_SENSORS_BACKGROUND בנוסף להרשאה הקיימת BODY_SENSORS.

ביצועים וסוללה

ניצול משאבי הסוללה

אם המשתמש מעביר את האפליקציה שלך למצב מוגבל לשימוש בסוללה ברקע, בזמן שהאפליקציה מטרגטת ל-Android 13, המערכת לא מעבירה את השידור BOOT_COMPLETED או את השידור LOCKED_BOOT_COMPLETED עד שהאפליקציה מופעלת מסיבות אחרות.

חוויית משתמש

ממשק השליטה במדיה נגזר מ-PlaybackState

באפליקציות שמיועדות ל-Android 13 (רמת API ‏33) ואילך, המערכת מפיקה את אמצעי הבקרה של המדיה מפעולות PlaybackState. ההגדרה הזו מאפשרת למערכת להציג קבוצה עשירה יותר של אמצעי בקרה, שבאופן טכני עקביים בין טלפונים וטאבלטים, וגם תואמים לאופן שבו אמצעי בקרה של מדיה מוצגים בפלטפורמות אחרות של Android, כמו Android Auto ו-Android TV.

באיור 2 מוצגות דוגמאות לאופן שבו זה נראה בטלפון ובטאבלט, בהתאמה.

אמצעי בקרה להפעלת מדיה, שמוצגים בטלפונים ובטאבלטים. בדוגמה מוצג טראק לדוגמה, שבו אפשר לראות איך הלחצנים עשויים להופיע
איור 2: אמצעי בקרה של מדיה בטלפונים ובטאבלטים

בגרסאות קודמות של Android (עד גרסה 13), המערכת הציגה עד חמש פעולות מתוך MediaStyleההתראה, בסדר שבו הן נוספו. במצב קומפקטי – לדוגמה, בהגדרות המהירות המכווצות – מוצגות עד שלוש פעולות שצוינו באמצעות setShowActionsInCompactView().

החל מ-Android 13, המערכת מציגה עד חמישה לחצני פעולה על סמך PlaybackState, כפי שמתואר בטבלה הבאה. במצב קומפקטי, יוצגו רק שלושת משבצות הפעולה הראשונות. באפליקציות שלא מטרגטות ל-Android 13 או באפליקציות שלא כוללות את PlaybackState, המערכת תציג אמצעי בקרה על סמך רשימת Action שנוספה להתראה MediaStyle, כפי שמתואר בפסקה הקודמת.

משבצת פעולה קריטריונים
1 Play הסטטוס הנוכחי של PlaybackState הוא אחד מהבאים:
  • STATE_NONE
  • STATE_STOPPED
  • STATE_PAUSED
  • STATE_ERROR
סימן גרפי של טעינה מתבצעת הסטטוס הנוכחי של PlaybackState הוא אחד מהבאים:
  • STATE_CONNECTING
  • STATE_BUFFERING
השהיה המצב הנוכחי של PlaybackState הוא אף אחת מהאפשרויות שלמעלה.
2 הקודם PlaybackState פעולות כוללות ACTION_SKIP_TO_PREVIOUS.
בהתאמה אישית PlaybackState הפעולות לא כוללות את ACTION_SKIP_TO_PREVIOUS וPlaybackState הפעולות בהתאמה אישית כוללות פעולה מותאמת אישית שעדיין לא הוצבה.
ריק ‫PlaybackState extras כולל ערך בוליאני true למפתח SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV.
3 הבא PlaybackState פעולות כוללות ACTION_SKIP_TO_NEXT.
בהתאמה אישית PlaybackState הפעולות לא כוללות את ACTION_SKIP_TO_NEXT וPlaybackState הפעולות בהתאמה אישית כוללות פעולה מותאמת אישית שעדיין לא הוצבה.
ריק ‫PlaybackState extras כולל ערך בוליאני true למפתח SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT.
4 בהתאמה אישית PlaybackState פעולות בהתאמה אישית כוללות פעולה בהתאמה אישית שעדיין לא הוצבה.
5 בהתאמה אישית PlaybackState פעולות בהתאמה אישית כוללות פעולה בהתאמה אישית שעדיין לא הוצבה.

הפעולות המותאמות אישית ממוקמות לפי הסדר שבו הן נוספו ל-PlaybackState.

החלת ערכת צבעים של האפליקציה באופן אוטומטי על תוכן WebView

באפליקציות שמטרגטות ל-Android 13 (רמת API 33) ומעלה, השיטה setForceDark() הוצאה משימוש, ולכן לא מתבצעת פעולה אם קוראים לשיטה.

במקום זאת, WebView תמיד מגדיר עכשיו את שאילתת המדיה prefers-color-scheme בהתאם למאפיין העיצוב של האפליקציה, isLightTheme. במילים אחרות, אם הערך של isLightTheme הוא true או לא צוין, הערך של prefers-color-scheme הוא light. אחרת, הערך הוא dark. המשמעות של ההתנהגות הזו היא שהסגנון הבהיר או הכהה של תוכן האינטרנט מוחל באופן אוטומטי כדי להתאים לעיצוב של האפליקציה, אם התוכן תומך בכך.

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

אם עדיין יש לכם צורך להתאים אישית את אופן הפעולה של ערכת הצבעים באפליקציה, אתם יכולים להשתמש במקום זאת בשיטה setAlgorithmicDarkeningAllowed(). כדי לשמור על תאימות לאחור עם גרסאות קודמות של Android, מומלץ להשתמש בשיטה המקבילה setAlgorithmicDarkeningAllowed() ב-AndroidX.

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

קישוריות

השיטות BluetoothAdapter#enable()‎ ו-BluetoothAdapter#disable()‎ הוצאו משימוש

באפליקציות שמטרגטות ל-Android 13 (רמת API 33) ומעלה, השימוש בשיטות BluetoothAdapter#enable() ו- BluetoothAdapter#disable() הוצא משימוש והן תמיד מחזירות false.

השינויים האלה לא חלים על סוגי האפליקציות הבאים:

  • אפליקציות של בעלי המכשיר
  • אפליקציות של בעלי הפרופיל
  • אפליקציות מערכת

Google Play Services

נדרשת הרשאה לקבלת מזהה פרסום

באפליקציות שמבוססות על מזהה הפרסום של Google Play Services ומיועדות ל-Android 13 (רמת API‏ 33) ואילך, צריך להצהיר על ההרשאה הרגילה AD_ID בקובץ המניפסט של האפליקציה, באופן הבא:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

אם האפליקציה שלכם מטרגטת את Android 13 או גרסה מתקדמת יותר ולא הצהרתם על ההרשאה הזו, מזהה הפרסום יוסר באופן אוטומטי ויוחלף במחרוזת של אפסים.

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

מידע נוסף זמין במאמר בנושא מזהה הפרסום במרכז העזרה של Play Console.

הגבלות מעודכנות שאינן ב-SDK

‫Android 13 כולל רשימות מעודכנות של ממשקי non-SDK מוגבלים, שמבוססות על שיתוף פעולה עם מפתחי Android ועל הבדיקות הפנימיות האחרונות. כשאפשר, אנחנו מוודאים שיש חלופות ציבוריות לפני שאנחנו מגבילים ממשקים שאינם ב-SDK.

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

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

מידע נוסף על השינויים בגרסה הזו של Android זמין במאמר עדכונים בהגבלות על ממשקים שאינם SDK ב-Android 13. מידע נוסף על ממשקים שאינם ב-SDK זמין במאמר הגבלות על ממשקים שאינם ב-SDK.