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

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

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

ההנחיות המלאות למפתחי אתרים לגבי השינויים האלה זמינות במאמרים הסבר על קובצי cookie של SameSite ו-Schemeful SameSite.

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

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

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

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

למידע על ניפוי באגים מרחוק ב-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

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

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

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

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

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

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

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

הפעלות לא בטוחות של כוונות

כדי לשפר את האבטחה בפלטפורמה, בגרסה 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ספריות ספקים

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

ספריות משותפות מקוריות שאינן 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.