שינויים בהתנהגות: אפליקציות שמטרגטות ל-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. מפעילים את השינוי בהתראות בהתאמה אישית:

   1. כדי להפעיל את ההתנהגות החדשה, משנים את הערך של targetSdkVersion באפליקציה ל-S.
   2. הידור מחדש.
   3. מתקינים את האפליקציה במכשיר או במהדמה עם Android 12.

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

   • המאפיינים של תצוגות בהתאמה אישית השתנו. באופן כללי, הגובה של התראות בהתאמה אישית קטן יותר מאשר בעבר. במצב מכווץ, הגובה המקסימלי של התוכן המותאם אישית ירד מ-106dp ל-48dp. בנוסף, יש פחות מקום אופקי.

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

   • כדי לוודא שהסטטוס 'התראה' נראה כמו שציפיתם, אל תשכחו להגדיל את רמת החשיבות של ערוץ ההתראות ל'גבוהה' (התרעה קופצת במסך).

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

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

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

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

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

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

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

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

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

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

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

מיקום משוער

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

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

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

זהירות: כדי להגן על הנתונים של האפליקציה, חשוב לזכור להגדיר את android:debuggable לערך false לפני שמפרסמים את האפליקציה.

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

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

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

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

Messages ב-Android Studio

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

Android Studio 2020.3.1 Canary 11 ואילך

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

1. אזהרת האיתור של שגיאות בקוד (lint) הבאה מופיעה בקובץ המניפסט:

   When using intent filters, please specify android:exported as well
   

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

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

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

הערה: אפליקציות עם ההרשאה SYSTEM_ALERT_WINDOW עדיין יכולות להתחיל פעילויות באמצעות משטח קפיצה של התראות, אבל מומלץ להימנע מתבנית חוויית המשתמש הזו ולהשתמש ב-PendingIntent במקום זאת.

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

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

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

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

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

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

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

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

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

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

גיבוי ושחזור

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

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

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

שינויים בפורמט 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 אחת זמינה ואפליקציית השיחה לא הפעילה חיבור 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.