דף זה תורגם על ידי 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, או אפליקציות שמשתמשות ב-methods של Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) ו-setCustomHeadsUpContentView(RemoteViews).

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

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

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

הצהרת שיוך (Attribution) בבדיקה של גישה לנתונים

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

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

הגבלת גיבוי ב-ADB

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

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

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

אם האפליקציה שלכם מטרגטת ל-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 ואילך

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

האזהרה הבאה לגבי איתור שגיאות בקוד מופיעה בקובץ המניפסט:
```
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'

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

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

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

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

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

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

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

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