שינויים בהתנהגות: אפליקציות שמטרגטות ל-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 בתרחישים כמו:

  • חיפוש מכשירים בקרבת מקום והתחברות אליהם, כמו מדפסות או מכשירים להפעלת תוכן במכשיר אחר. תהליך העבודה הזה מאפשר לאפליקציה לבצע משימות מהסוגים הבאים:
    • לקבל מידע על נקודת הגישה מחוץ לפס, למשל באמצעות 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 הפעלה המצב הנוכחי של 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 כוללות ערך בוליאני true למפתח SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV.
3 הבא פעולות PlaybackState כוללות את ACTION_SKIP_TO_NEXT.
בהתאמה אישית פעולות PlaybackState לא כוללות את ACTION_SKIP_TO_NEXT ופעולות בהתאמה אישית מסוג PlaybackState כוללות פעולה בהתאמה אישית שעדיין לא נבחר לה מיקום.
ריק ‫תוספות מסוג PlaybackState כוללות ערך בוליאני 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.