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

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

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

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

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

עיצוב מחדש של Toast

ב-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.

הנחיות מלאות למפתחי אתרים בנוגע לשינויים האלה זמינות במאמרים SameSite Cookies Explained ו-Schemeful SameSite.

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

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

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

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

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

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

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

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

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

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

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

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

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

ה-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 ואילך והיא מכילה פעילויות, שירותים או רכיבי Broadcast Receiver שמשתמשים במסנני כוונות, צריך להצהיר באופן מפורש על מאפיין 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'

יכולת שינוי של אובייקטים מסוג PendingIntent

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

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

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

הפעלות של אובייקטים מסוג Intent לא בטוחים

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

ביצועים

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

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

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

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

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

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

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

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

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

במסך ההגדרות אפשרויות למפתחים, בוחרים באפשרות שינויים בתאימות האפליקציה. במסך שמופיע, מקישים על שם האפליקציה ואז משביתים את ההגדרה REQUIRE_EXACT_ALARM_PERMISSION.
בחלון טרמינל במחשב הפיתוח, מריצים את הפקודה הבאה:
```
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
```

הגבלות על מעבר מהתראה לאפליקציה

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

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

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

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

זיהוי רכיבי האפליקציה שפועלים כקרש קפיצה להצגת התראות

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

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

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

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

אם האפליקציה שלכם מתחילה פעילות משירות או מ-broadcast receiver שפועל כ-notification trampoline, צריך לבצע את שלבי ההעברה הבאים:

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

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

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

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

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

אפליקציות שפועלות ב-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.

חיבור מקביל מקצה לקצה + חיבור לאינטרנט

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

תאימות

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

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

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

בדוגמת הקוד הבאה אפשר לראות איך מקבלים את 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 native API

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

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

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

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

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

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

הגבלות מעודכנות על שימוש בממשק שאינו ב-SDK

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

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

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

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