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

כל עוד האפליקציה לא מסיקה פרטי מיקום פיזי מממשקי ה-API של ה-Wi-Fi, צריך לבקש 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 בקרבת מקום

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

שני הלחצנים בתיבת הדו-שיח, מלמעלה למטה, הם 'אישור' ו'לא לאשר'.
איור 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().

החל מגרסה 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 התוספות כוללות ערך בוליאני true עבור המפתח SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT.
4 בהתאמה אישית PlaybackState פעולות בהתאמה אישית כוללות פעולה מותאמת אישית שעדיין לא הוצבה.
5 בהתאמה אישית PlaybackState פעולות מותאמות אישית כוללות פעולה מותאמת אישית שעדיין לא בוצעה.

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

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

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

במקום זאת, 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 (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 ואילך, מזהה הפרסום יוסר באופן אוטומטי ויוחלף במחרוזת של אפסים.

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

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

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

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

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

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

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