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