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

במקום זאת, 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 תמיד כרוך בסיכון גבוה לגרימת כשל באפליקציה.

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

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