דף זה תורגם על ידי Cloud Translation API.

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

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

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

חוויית משתמש

עדכונים בהתאמה אישית

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

באפליקציות שמטרגטות את Android 12, התראות עם תצוגות תוכן בהתאמה אישית לא ישתמשו יותר באזור ההתראות המלא. במקום זאת, המערכת תחיל תבנית רגילה. התבנית הזו מבטיחה שההתראות בהתאמה אישית יהיו מעוטרות באותו אופן כמו התראות אחרות בכל המצבים, למשל סמל ההתראה ואמצעי ההרחבה (במצב הממוזער) וסמל ההתראה, שם האפליקציה ואמצעי ההקטנה (במצב המורחב). ההתנהגות הזו כמעט זהה להתנהגות של Notification.DecoratedCustomViewStyle.

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

באיור הבא מוצגת התראה בהתאמה אישית בתבנית הרגילה:

הדוגמאות הבאות מראות איך התראות בהתאמה אישית יוצגו במצב מכווץ ובמצב מורחב:

השינוי ב-Android 12 משפיע על אפליקציות שמגדירות תת-כיתות בהתאמה אישית של Notification.Style, או שמשתמשות בשיטות setCustomContentView(RemoteViews),‏ setCustomBigContentView(RemoteViews) ו-setCustomHeadsUpContentView(RemoteViews) של Notification.Builder.

אם באפליקציה שלכם נעשה שימוש בהתראות בהתאמה אישית מלאה, מומלץ לבדוק את התבנית החדשה בהקדם האפשרי.

מפעילים את השינוי בהתראות בהתאמה אישית:
1. כדי להפעיל את ההתנהגות החדשה, צריך לשנות את הערך של targetSdkVersion באפליקציה ל-S.
2. הידור מחדש.
3. מתקינים את האפליקציה במכשיר או במהדמה עם Android 12.
כדאי לבדוק את כל ההתראות שמשתמשות בתצוגות בהתאמה אישית, כדי לוודא שהן נראות כמו שציפיתם כשהן מוסתרות. במהלך הבדיקה, חשוב להביא בחשבון את השיקולים הבאים ולבצע את ההתאמות הנדרשות:
- המאפיינים של תצוגות בהתאמה אישית השתנו. באופן כללי, הגובה של התראות מותאמות אישית נמוך מבעבר. במצב מכווץ, הגובה המקסימלי של התוכן המותאם אישית ירד מ-106dp ל-48dp. בנוסף, יש פחות מקום אופקי.
- אפשר להרחיב את כל ההתראות באפליקציות שמטרגטות ל-Android מגרסה 12 ואילך. בדרך כלל, אם משתמשים ב-setCustomContentView, צריך להשתמש גם ב-setBigCustomContentView כדי לוודא שהמצב המכווץ והמצב המורחב עקביים.
- כדי לוודא שהסטטוס 'התראה' ייראה כמו שציפיתם, אל תשכחו להגדיל את רמת החשיבות של ערוץ ההתראות ל'גבוהה' (התרעה קופצת במסך).

שינויים באימות של קישורים לאפליקציות ל-Android

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

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

אפשר גם לאמת באופן ידני את הקישורים של האפליקציה כדי לבדוק את מהימנות ההצהרות.

שיפורים בהתנהגות של התכונה 'תמונה בתוך תמונה'

ב-Android 12 יש שיפורים בהתנהגות של מצב 'תמונה בתוך תמונה' (PiP), ושיפורים קוסמטיים מומלצים באנימציות המעבר גם לניווט באמצעות תנועות וגם לניווט מבוסס-רכיבים.

מידע נוסף זמין במאמר שיפורים בתכונה 'תמונה בתוך תמונה'.

עיצוב מחדש של ההודעות הקופצות

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

תמונה של מכשיר Android עם חלון קופץ עם הכיתוב 'שליחת הודעה' לצד סמל של אפליקציה

פרטים נוספים זמינים במאמר סקירה כללית על הודעות טוסט.

אבטחה ופרטיות

מיקום משוער

במכשירים עם Android מגרסה 12 ואילך, המשתמשים יכולים לבקש מהאפליקציה שלכם דיוק משוער של המיקום.

קובצי cookie מודרניים מסוג SameSite ב-WebView

הרכיב WebView של Android מבוסס על Chromium, הפרויקט בקוד פתוח שמניע את דפדפן Chrome של Google. ב-Chromium הוכנסו שינויים בטיפול בקובצי cookie של צד שלישי כדי לספק יותר אבטחה ופרטיות, ולספק למשתמשים יותר שקיפות ושליטה. החל מ-Android 12, השינויים האלה נכללים גם ב-WebView כשאפליקציות מטרגטות ל-Android 12 (רמת API 31) ואילך.

המאפיין SameSite של קובץ cookie קובע אם אפשר לשלוח אותו עם כל הבקשות, או רק עם בקשות באותו אתר. השינויים הבאים בנושא הגנה על הפרטיות משפרים את אופן הטיפול המוגדר כברירת מחדל בקובצי cookie של צד שלישי ועוזרים להגן מפני שיתוף לא מכוון בין אתרים:

קובצי cookie ללא מאפיין SameSite מטופלים כ-SameSite=Lax.
בקובצי cookie עם SameSite=None צריך גם לציין את המאפיין Secure, כלומר הם דורשים הקשר מאובטח וצריך לשלוח אותם באמצעות HTTPS.
קישורים בין גרסאות HTTP ו-HTTPS של אתרים נחשבים עכשיו כבקשות בין אתרים, ולכן קובצי cookie לא נשלחים אלא אם הם מסומנים כראוי בתור SameSite=None; Secure.

למפתחים, ההנחיה הכללית היא לזהות את יחסי התלות בין קובצי cookie באתרים שונים בתהליכי המשתמש הקריטיים, ולוודא שהמאפיין SameSite מוגדר באופן מפורש עם הערכים המתאימים במקרים הנדרשים. עליכם לציין במפורש את קובצי ה-cookie שמותר להם לפעול באתרים שונים או במעברים באותו אתר מ-HTTP ל-HTTPS.

למפתחי אתרים, הנחיות מלאות לגבי השינויים האלה זמינות במאמרים הסבר על קובצי cookie מסוג SameSite וSchemeful SameSite.

בדיקת התנהגויות SameSite באפליקציה

אם האפליקציה שלכם משתמשת ב-WebView, או אם אתם מנהלים אתר או שירות שמשתמשים בקובצי cookie, מומלץ לבדוק את התהליכים ב-WebView של Android 12. אם יימצאו בעיות, ייתכן שיהיה צורך לעדכן את קובצי ה-cookie כך שיתמכו בדפוסי ההתנהגות החדשים של SameSite.

חשוב לבדוק אם יש בעיות בכניסות ובתוכן מוטמע, וגם בתהליכי כניסה, רכישה ותהליכי אימות אחרים שבהם המשתמש מתחיל בדף לא מאובטח וממשיך לדף מאובטח.

כדי לבדוק אפליקציה עם WebView, צריך להפעיל את ההתנהגויות החדשות של SameSite באפליקציה שרוצים לבדוק. לשם כך, מבצעים את אחד מהשלבים הבאים:

כדי להפעיל באופן ידני את התנהגויות SameSite במכשיר הבדיקה, משנים את מצב הדגל של ממשק המשתמש webview-enable-modern-cookie-same-site ב-WebView devtools.

הגישה הזו מאפשרת לבדוק בכל מכשיר עם Android בגרסה 5.0 (רמת API‏ 21) ואילך, כולל Android 12, ו-WebView בגרסה 89.0.4385.0 ואילך.
צריך לקמפל את האפליקציה כך שתטרגט את Android 12 (רמת API 31) עד targetSdkVersion.

אם משתמשים בגישה הזו, צריך להשתמש במכשיר עם Android 12.

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

מקורות מידע נוספים

מידע נוסף על ההתנהגויות המודרניות של SameSite ועל ההשקה שלהן ב-Chrome וב-WebView זמין בדף עדכוני SameSite ב-Chromium. אם מצאתם באג ב-WebView או ב-Chromium, תוכלו לדווח עליו בכלי הציבורי למעקב אחר בעיות ב-Chromium.

חיישני תנועה מוגבלים בקצב שליחת הבקשות

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

מידע נוסף על הגבלת קצב של חיישנים.

מצב תנומה של אפליקציה

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

מידע נוסף זמין במדריך בנושא הרדמה של אפליקציות.

הצהרת שיוך בביקורת הרשאות גישה לנתונים

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

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

הגבלת גיבוי ADB

כדי להגן על נתונים פרטיים של אפליקציות, התנהגות ברירת המחדל של הפקודה adb backup השתנתה ב-Android 12. באפליקציות שמטרגטות את Android 12 (רמת API 31) ואילך, כשמשתמש מריץ את הפקודה adb backup, נתוני האפליקציה לא נכללים בכל נתוני המערכת האחרים שמיוצאים מהמכשיר.

אם תהליכי הבדיקה או הפיתוח מסתמכים על נתוני אפליקציה באמצעות adb backup, עכשיו אפשר להביע הסכמה לייצוא נתוני האפליקציה באמצעות הגדרת הערך true בקובץ המניפסט של האפליקציה ב-android:debuggable.

ייצוא בטוח יותר של רכיבים

אם האפליקציה שלכם מטרגטת ל-Android 12 ואילך ומכילה פעילויות, שירותים או מקבלי שידור שמשתמשים במסנני כוונה, עליכם להצהיר באופן מפורש על המאפיין android:exported עבור רכיבי האפליקציה האלה.

אם רכיב האפליקציה כולל את הקטגוריה LAUNCHER, מגדירים את הערך של android:exported כ-true. ברוב המקרים האחרים, מגדירים את android:exported לערך false.

קטע הקוד הבא מציג דוגמה לשירות שמכיל מסנן כוונה שהמאפיין android:exported שלו מוגדר כ-false:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

הודעות ב-Android Studio

אם האפליקציה מכילה פעילות, שירות או מקלט שידורים שמשתמשים במסנני Intent אבל לא מגדירים את android:exported, מוצגות הודעות האזהרה הבאות, בהתאם לגרסה של Android Studio שבה אתם משתמשים:

Android Studio 2020.3.1 Canary 11 ואילך

ההודעות הבאות מופיעות:

אזהרת האיתור של שגיאות בקוד (lint) הבאה מופיעה בקובץ המניפסט:
```
When using intent filters, please specify android:exported as well
```

כשמנסים לקמפל את האפליקציה, מופיעה הודעת השגיאה הבאה לגבי ה-build:

Manifest merger failed : Apps targeting Android 12 and higher are required \
to specify an explicit value for android:exported when the corresponding \
component has an intent filter defined.

גרסאות ישנות יותר של Android Studio

אם תנסו להתקין את האפליקציה, תופיע הודעת השגיאה הבאה ב-Logcat:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

יכולת שינוי של Intent בהמתנה

אם האפליקציה מטרגטת את Android 12, צריך לציין את יכולת השינוי של כל אובייקט PendingIntent שהאפליקציה יוצרת. הדרישה הנוספת הזו משפרת את אבטחת האפליקציה.

בדיקת השינוי ביכולת השינוי של PendingIntent

כדי לבדוק אם באפליקציה שלכם חסרות הצהרות על יכולת שינוי, מחפשים את האזהרה הבאה של איתור שגיאות ב-Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

הפעלות לא בטוחות של כוונות

כדי לשפר את האבטחה בפלטפורמה, בגרסה Android 12 ואילך יש תכונת ניפוי באגים שמאפשרת לזהות הפעלות לא בטוחות של כוונות. כשהמערכת מזהה הפעלה לא בטוחה כזו, מתרחשת הפרה של StrictMode.

ביצועים

הגבלות על הפעלה של שירותים שפועלים בחזית

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

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

הרשאה להתראה מדויקת

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

כדי לקבל את הגישה המיוחדת הזו לאפליקציה, צריך לבקש את ההרשאה SCHEDULE_EXACT_ALARM במניפסט.

יש להשתמש בהתראות מדויקות רק בתכונות שגלויות למשתמשים. מידע נוסף על התרחישים המקובלים להגדרת התראה מדויקת

השבתת השינוי בהתנהגות

כשאתם מכינים את האפליקציה לטירגוט ל-Android 12, אתם יכולים להשבית באופן זמני את השינוי בהתנהגות בגרסת build לצורכי ניפוי באגים, למטרות בדיקה. כדי לעשות זאת:

במסך ההגדרות Developer options (אפשרויות למפתחים), בוחרים באפשרות App Compatibility Changes (שינויים בתאימות לאפליקציות). במסך שמופיע, מקישים על שם האפליקציה ומשביתים את האפשרות REQUIRE_EXACT_ALARM_PERMISSION.
בחלון הטרמינל במכונת הפיתוח, מריצים את הפקודה הבאה:
```
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
```

הגבלות על 'טרמפולינה של התראות'

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

כדי לשפר את הביצועים ואת חוויית המשתמש של האפליקציה, אפליקציות שמטרגטות את Android מגרסה 12 ואילך לא יכולות להפעיל פעילויות משירותים או ממקלטים של שידורים שמשמשים כtrampolines של התראות. במילים אחרות, אחרי שהמשתמש מקייש על התראה או על לחצן פעולה בהתראה, האפליקציה לא יכולה להפעיל את startActivity() בתוך שירות או מקלט שידור.

כשהאפליקציה מנסה להפעיל פעילות משירות או ממכשיר לקבלת שידורים שמשמשים כtrampoline של התראות, המערכת מונעת את הפעלת הפעילות וההודעה הבאה מופיעה ב-Logcat:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

זיהוי רכיבי האפליקציה שמשמש כtrampolines של התראות

כשבודקים את האפליקציה, אחרי שמקישים על התראה אפשר לזהות איזה שירות או מקלט שידור שימש כtrampoline של ההתראות באפליקציה. כדי לעשות זאת, בודקים את הפלט של הפקודה הבאה במסוף:

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

קטע מהפלט כולל את הטקסט "NotifInteractionLog". הקטע הזה מכיל את המידע הדרוש כדי לזהות את הרכיב שמתחיל לפעול כתוצאה מלחיצה על התראה.

עדכון האפליקציה

אם האפליקציה מפעילה פעילות משירות או ממכשיר לקבלת שידורים שמשמשים כtrampoline של התראות, צריך לבצע את שלבי ההעברה הבאים:

יוצרים אובייקט PendingIntent שמשויך לפעילות שהמשתמשים רואים אחרי שהם מקישים על ההתראה.
משתמשים באובייקט PendingIntent שיצרתם בשלב הקודם כחלק מיצירת ההתראה.

כדי לזהות את מקור הפעילות, לדוגמה, כדי לבצע רישום ביומן, אפשר להשתמש בתוספות בעת פרסום ההתראה. לצורך רישום ביומן מרכזי, אפשר להשתמש ב-ActivityLifecycleCallbacks או במשגיחי מחזור החיים של Jetpack.

החלפת המצב של ההתנהגות

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

גיבוי ושחזור

יש שינויים באופן שבו פועלים הגיבוי והשחזור באפליקציות שפועלות ב-Android 12 (רמת API 31) ומיועדות להרצה במכשירים כאלה. יש שתי דרכים לגבות ולשחזר את הנתונים ב-Android:

גיבויים בענן: נתוני המשתמשים מאוחסנים ב-Google Drive שלהם, כדי שאפשר יהיה לשחזר אותם מאוחר יותר במכשיר הזה או במכשיר חדש.
העברות ממכשיר למכשיר (D2D): נתוני המשתמשים נשלחים ישירות מהמכשיר הישן למכשיר החדש, למשל באמצעות כבל.

מידע נוסף על אופן הגיבוי והשחזור של נתונים זמין במאמרים גיבוי נתוני משתמשים באמצעות הגיבוי האוטומטי וגיבוי של צמדי מפתח/ערך באמצעות Android Backup Service.

שינויים בפונקציונליות של העברה ממכשיר למכשיר

באפליקציות שפועלות ב-Android מגרסה 12 ואילך ומטרגטות אותה:

ציון כללי הכללה והחרגה באמצעות מנגנון ההגדרה של ה-XML לא משפיע על העברות D2D, אבל עדיין משפיע על גיבוי ושחזור בענן (כמו גיבויים ב-Google Drive). כדי לציין כללים להעברות D2D, צריך להשתמש בהגדרות החדשות שמפורטות בקטע הבא.
במכשירים של יצרני מכשירים מסוימים, ציון הערך android:allowBackup="false" משבית את הגיבויים ל-Google Drive אבל לא משבית העברות D2D לאפליקציה.

פורמט חדש של הכללה והחרגה

באפליקציות שפועלות ב-Android 12 ואילך ומטרגטות את הגרסה הזו, נעשה שימוש בפורמט אחר של הגדרת ה-XML. הפורמט הזה מאפשר להבחין בבירור בין גיבוי ב-Google Drive להעברה ממכשיר ל-מכשיר, כי צריך לציין כללים להכללה ולהחרגה בנפרד לגיבויים בענן ולהעברות ממכשיר ל-מכשיר.

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

שינויים בפורמט XML

זה הפורמט שמשמש לגיבוי ושחזור של הגדרות ב-Android 11 ומטה:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

למטה מוצגים השינויים בפורמט בגופן מודגש.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

למידע נוסף, עיינו בקטע המתאים במדריך לגיבוי נתוני משתמש באמצעות גיבוי אוטומטי.

סימון במניפסט לאפליקציות

מפנים את האפליקציות להגדרת ה-XML החדשה באמצעות המאפיין android:dataExtractionRules בקובץ המניפסט. כשמפנים להגדרת ה-XML החדשה, המאפיין android:fullBackupContent שמפנה להגדרה הישנה מתעלם במכשירים עם Android מגרסה 12 ואילך. בקטע הקוד הבא מוצגות הרשומות החדשות בקובץ המניפסט:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

קישוריות

הרשאות Bluetooth

Android 12 מציג את ההרשאות ל-BLUETOOTH_SCAN, ל-BLUETOOTH_ADVERTISE ול-BLUETOOTH_CONNECT. ההרשאות האלה מאפשרות לאפליקציות שמטרגטות את Android 12 לבצע אינטראקציה עם מכשירי Bluetooth, במיוחד לאפליקציות שלא דורשות גישה למיקום המכשיר.

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

חיבור מקצה לקצה (P2P) + חיבור לאינטרנט בו-זמנית

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

תאימות

WifiManager.getConnectionInfo() יכול להחזיר את WifiInfo רק לרשת אחת. לכן, ההתנהגות של ה-API השתנתה בדרכים הבאות ב-Android 12 ואילך:

אם יש רק רשת Wi-Fi אחת זמינה, המערכת מחזירה את הערך של WifiInfo שלה.
אם יש יותר מרשת Wi-Fi אחת זמינה ואפליקציית השיחה הפעילה חיבור peer-to-peer, המערכת תחזיר את הערך של WifiInfo שמתאים למכשיר השני.
אם יש יותר מרשת Wi-Fi אחת זמינה ואפליקציית השיחה לא הפעילה חיבור peer-to-peer, המערכת מחזירה את הערך של WifiInfo של החיבור הראשי שמספק את האינטרנט.

כדי לספק חוויית משתמש טובה יותר במכשירים שתומכים בשתי רשתות Wi-Fi בו-זמנית, מומלץ לכל האפליקציות – במיוחד לאפליקציות שמפעילות חיבורים מקצה לקצה – לעבור מהקריאה ל-WifiManager.getConnectionInfo() ולהשתמש במקום זאת ב-NetworkCallback.onCapabilitiesChanged() כדי לקבל את כל אובייקטי ה-WifiInfo שתואמים ל-NetworkRequest ששימש לרישום ה-NetworkCallback. getConnectionInfo() הוצאה משימוש החל מ-Android 12.

בדוגמת הקוד הבאה מוסבר איך לקבל את הערך של WifiInfo ב-NetworkCallback:

Kotlin

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

Java

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

mDNSResponder API מקורי

ב-Android 12 יש שינויים לגבי האופן שבו אפליקציות יכולות ליצור אינטראקציה עם הדימון mDNSResponder באמצעות ה-API המקורי של mDNSResponder. בעבר, כשאפליקציה רשמה שירות ברשת וקראה ל-method‏ getSystemService(), שירות ה-NSD של המערכת הפעיל את הדימון mDNSResponder, גם אם האפליקציה עדיין לא קראה לשיטות NsdManager. לאחר מכן הדימון הרשם את המכשיר לקבוצות ה-multicast של כל הצמתים, וכתוצאה מכך המערכת התעוררה בתדירות גבוהה יותר ונצרכה יותר חשמל. כדי לצמצם את השימוש בסוללה, ב-Android מגרסה 12 ואילך המערכת מפעילה עכשיו את הדימון mDNSResponder רק כשיש צורך בו לאירועי NSD, ומפסיקה אותו לאחר מכן.

מכיוון שהשינוי הזה משפיע על המועד שבו הדימון mDNSResponder זמין, אפליקציות שמניחות שהדימון mDNSResponder יופעל אחרי קריאה ל-method‏ getSystemService() עשויות לקבל מהמערכת הודעות על כך שהדימון mDNSResponder לא זמין. אפליקציות שמשתמשות ב-NsdManager ולא משתמשות ב-API המקורי של mDNSResponder לא מושפעות מהשינוי הזה.

ספריות של ספקים

ספריות מקוריות משותפות שסופקו על ידי ספקים

כברירת מחדל, אין גישה לספריות משותפות מקוריות שאינן NDK שמסופקות על ידי ספקי סיליקון או יצרני מכשירים, אם האפליקציה מטרגטת את Android 12 (רמת API 31) ואילך. אפשר לגשת לספריות רק אם מבקשים עבורן באופן מפורש באמצעות התג <uses-native-library>.

אם האפליקציה מטרגטת ל-Android 11 (רמת API 30) ומטה, אין צורך בתג <uses-native-library>. במקרה כזה, אפשר לגשת לכל ספרייה משותפת מקומית, גם אם מדובר בספריית NDK.

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

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

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

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

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