שינויים בהתנהגות: אפליקציות שמטרגטות ל-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 ומעלה ומשתמשים בממשקי API של Wi-Fi. כשמצהירים על ההרשאה NEARBY_WIFI_DEVICES, צריך להצהיר באופן חד-משמעי שהאפליקציה אף פעם לא מפיקה נתוני מיקום פיזי מממשקי API של Wi-Fi. כדי לעשות את זה, מגדירים את המאפיין android:usesPermissionFlags בתור neverForLocation. התהליך הזה דומה לתהליך שמבצעים ב-Android בגרסה 12 (רמת API‏ 31) ומעלה כשמצהירים שפרטי מכשיר ה-Bluetooth אף פעם לא משמשים למיקום.

איך מבקשים הרשאה לגשת למכשירי Wi-Fi בקרבת מקום

הרשאות מדיה ספציפיות

‫2 הכפתורים בתיבת הדו-שיח, מלמעלה למטה, הם "אישור" ו"לא לאשר"
איור 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 שקדמו ל-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 כוללת רשימות מעודכנות של ממשקים מוגבלים שאינם SDK, על סמך שיתוף פעולה עם מפתחי Android והבדיקות הפנימיות האחרונות. בכל פעם שאפשר, אנחנו מוודאים שקיימות חלופות ציבוריות לפני שאנחנו מגבילים ממשקים שאינם SDK.

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

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

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