שינויים בהתנהגות: אפליקציות שמטרגטות ל-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 והתחברות אליהם באמצעות נקודה לשיתוף אינטרנט (Hotspot) מקומית בלבד.
  • איתור מכשירים והתחברות אליהם באמצעות Wi-Fi ישיר.
• התחלת חיבור ל-SSID ידוע, כמו רכב או מכשיר בית חכם.
• להפעיל נקודה מקומית בלבד לשיתוף אינטרנט.
• טווח של מכשירי Wi-Fi Aware בקרבת מקום.

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

הערה: השינוי הזה משפיע על האפליקציה רק אם אתם קוראים ל-Wi-Fi API. רשימת ממשקי ה-API שהושפעו

מידע נוסף על בקשת הרשאה לגישה למכשירי 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

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

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

ב-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().

החל מגרסה 13 של Android, המערכת מציגה עד חמישה לחצני פעולה על סמך 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() הוצאה משימוש, וכתוצאה מכך תתבצע פעולה ללא תוצאה (no-op) אם תתבצע קריאה לשיטה.

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

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

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

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

קישוריות

הוצאה משימוש של BluetoothAdapter#enable() ו-BluetoothAdapter#disable()

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

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

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

Google Play Services

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

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

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

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

עדכון ההגבלות על רכיבים שאינם SDK

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

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

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

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