The Android 15 Beta is now available. Try it out today and let us know what you think!

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

הצגת התכונה תמונה בתוך תמונה לשיפורים מידע.

עיצוב מחדש של תצוגת טוסט

ב-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 הסבר וסכמה SameSite.

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

אם האפליקציה משתמשת ב-WebView, או אם אתם מנהלים אתר או שירות שמשתמשים בהם קובצי cookie, מומלץ לבדוק את הזרימה ב-Android 12 WebView. אם יימצאו בעיות, ייתכן שצריך לעדכן את קובצי ה-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.

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

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

הגבלת גיבוי 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>

Messages ב-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'

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

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

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

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

השקות של כוונות לא בטוחות

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

שינוי אופן הפעולה

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

גיבוי ושחזור

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

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

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

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

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

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

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

אפליקציות שפועלות במכשיר 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 אחת זמינה ואפליקציית השיחות הפעילה חיבור מקצה לקצה (P2P), ה-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 מקורי של mDNSCommenter

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

מכיוון שהשינוי הזה משפיע על המועד שבו הדימון (daemon) של mDNSCommenter יהיה זמין, אפליקציות מתבססת על ההנחה שהדימון (daemon) של mDNSResponseer יתחיל לאחר קריאה יכול להיות שאמצעי התשלום getSystemService() יקבל מהמערכת הודעות שכתוב בהן הדימון (daemon) של mDNSresponseer אינו זמין. אפליקציות שמשתמשות ב-NsdManager ולא משתמשות להשתמש ב-API המקורי mDNSResponseer לא מושפעים מהשינוי הזה.

ספריות ספקים

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

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

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

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

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

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

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

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