‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

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

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

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

מיקום משוער

במכשירים עם 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.

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

משאבים אחרים

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

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

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

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

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

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

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

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

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

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

הגבלת גיבוי ADB

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

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

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

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

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

בקטע הקוד הבא יש דוגמה לשירות שמכיל מסנן Intent שהמאפיין 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

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

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

בדיקת השינוי ביכולת השינוי של ה-intent בהמתנה

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

הפעלות של Intent לא בטוח

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

ביצועים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תאימות

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

אם יש רק רשת Wi-Fi אחת זמינה, יוחזר ה-WifiInfo שלה.
אם יש יותר מרשת Wi-Fi אחת זמינה ואפליקציית השיחות הפעילה חיבור בין עמיתים, תוחזר ה-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;
    ...
  }
  ...
};

ממשק API מקורי של mDNSResponder

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

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

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

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

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

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

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

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

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

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

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