שינויים בהתנהגות: אפליקציות שמטרגטות ל-Android 13 ואילך

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

חשוב גם לעיין ברשימה של שינויי ההתנהגות שמשפיעים על כל האפליקציות שפועלות ב-Android 13.

פרטיות

ההרשאה לשליחת התראות משפיעה על המראה של השירות שפועל בחזית

אם המשתמש דוחה את ההרשאה לקבלת התראות, הוא לא יראה התראות שקשורות לשירותים שפועלים בחזית במגירה של ההתראות. עם זאת, המשתמשים עדיין רואים ב-Task Manager הודעות שקשורות לשירותים שפועלים בחזית, גם אם ההרשאה לשליחת התראות הוענקה.

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

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

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

לקבלת מידע נוסף, ראו Advertising 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.