שינויים בהתנהגות: כל האפליקציות

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

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

חוויית משתמש

אפקט של גלילת יתר

במכשירים עם Android מגרסה 12 ואילך, ההתנהגות החזותית של גלילת יתר אירועים.

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

למידע נוסף, ראה את המדריך להנפשה של גלילה תנועות.

מסכי פתיחה של אפליקציות

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

להוראות, ראו העברת מסך הפתיחה הקיים ב-Android 12.

בנוסף, החל מ-Android 12, המערכת תמיד מחילה את הגרסה החדשה של Android מסך הפתיחה שמוגדר כברירת מחדל במערכת מופעל קר ו הפעלה במצב ביניים (warm start) של כל האפליקציות. כברירת מחדל, מסך הפתיחה שמוגדר כברירת מחדל של המערכת נבנה באמצעות של רכיב סמל מרכז האפליקציות windowBackground מתוך עיצוב (אם יש צבע אחד).

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

פתרון Intent באינטרנט

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

אפליקציות יכולות לקבל את האישור הזה באחת מהדרכים הבאות:

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

שיפורים במצב עשיר לניווט באמצעות תנועות

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

Display#getRealSize ו-getRealMetrics: הוצאה משימוש ומגבלות

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

ב-Android 12 אנחנו ממשיכים להמליץ להשתמש ב-WindowMetrics, ולהוציא משימוש את השיטות האלה:

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

האפליקציות צריכות להשתמש בממשקי ה-API של WindowMetrics כדי להריץ שאילתות על הגבולות של החלון שלהם, Configuration.densityDpi כדי להריץ שאילתה על הצפיפות הנוכחית.

לתאימות רחבה יותר לגרסאות ישנות של Android, אפשר להשתמש ספריית Jetpack WindowManager, כולל כיתה WindowMetrics שתומך ב-Android 4.0 (רמת API 14) ואילך.

דוגמאות לשימוש ב-WindowMetrics

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

פעילות צריכה להסתמך על WindowMetrics מההקשר של הפעילות בכל בעבודה שקשורה לממשק המשתמש, WindowManager.getCurrentWindowMetrics() או Jetpack WindowMetricsCalculator.computeCurrentWindowMetrics().

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

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

Kotlin

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Java

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

אם לא ניתן לשנות את גודל האפליקציה באופן מלא, היא חייבת לשלוח שאילתה מ-WindowContext ומאחזרים את הערך WindowMetrics של גבולות הפעילות באמצעות WindowManager.getMaximumWindowMetrics() או בשיטת Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().

Kotlin

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Java

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

כל האפליקציות במצב ריבוי חלונות

ב-Android 12 פועלת התנהגות רגילה של מצב ריבוי חלונות.

במסכים גדולים (sw >= 600dp), הפלטפורמה תומכת בכל האפליקציות בריבוי חלונות בלי קשר להגדרת האפליקציה. אם המיקום resizeableActivity="false" האפליקציה עוברת למצב תאימות בעת הצורך כדי להתאים את התצוגה מאפיינים.

במסכים קטנים (sw < 600dp), המערכת בודקת minWidth וגם minHeight כדי לקבוע אם הפעילות יכולה לרוץ במצב ריבוי חלונות. אם המיקום resizeableActivity="false" האפליקציה לא יכולה לפעול במצב ריבוי חלונות, ללא קשר למינימום רוחב וגובה.

מידע נוסף זמין במאמר בנושא תמיכה בריבוי חלונות.

תצוגה מקדימה של המצלמה במסכים גדולים

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

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

עיכוב בחוויית המשתמש בהתראות לגבי שירות שפועל בחזית

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

ביצועים

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

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

  1. פעילה: האפליקציה נמצאת בשימוש או שהייתה בשימוש לאחרונה.
  2. קבוצת עבודה: האפליקציה נמצאת בשימוש רגיל.
  3. לעיתים קרובות: משתמשים באפליקציה לעיתים קרובות, אבל לא בכל יום.
  4. נדיר: לא משתמשים באפליקציה לעיתים קרובות.
  5. מוגבל: האפליקציה צורכת כמות גדולה של משאבי מערכת, או שהיא עשויה להופיע גם התנהגות בלתי רצויה.

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

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

בדיקה אם האפליקציה נמצאת בקטגוריה המוגבלת

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

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

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

מיקום משוער

בתיבת הדו-שיח יש שתי קבוצות של אפשרויות, אחת מעל הקטגוריה &#39;אחר&#39;
איור 1. תיבת דו-שיח להרשאות מערכת שמאפשרת למשתמש כדי לספק מידע על המיקום המשוער.

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

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

תיבת הדו-שיח של הרשאות המערכת כוללת את האפשרויות הבאות למשתמש: כפי שמוצג באיור 1:

  • מדויקת: מספקת גישה לפרטי מיקום מדויק.
  • משוער: מספקת גישה רק לפרטי מיקום משוער.

מתגי הגישה למיקרופון ולמצלמה

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

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

אינדיקטורים של מיקרופון ומצלמה

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

למידע נוסף על אינדיקטורים ואיך לוודא שהאפליקציה פועלת לפי השיטות המומלצות לגבי CAMERA וגם RECORD_AUDIO הרשאות.

כרטיסי המידע בהגדרות המהירות מסומנים בתווית &#39;גישה למצלמה&#39; וגם &#39;גישה למיקרופון&#39;
איור 2. החלפת המצב של המיקרופון והמצלמה הגדרות מהירות.
מלבן מעוגל בפינה הימנית העליונה, שכולל סמל מצלמה וסמל מיקרופון
איור 3. אינדיקטורים של מיקרופון ומצלמה שמוצגים גישה לנתונים עדכניים.

הרשאות גישה לחבילת ההרשאות

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

הטמעת BouncyCastle הוסרה

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

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

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

  • באפליקציה שלך נעשה שימוש בגדלים לא חוקיים של מפתחות עם KeyGenerator. ההטמעה של Conscrypt ב-KeyGenerator יש ביצועים נוספים אימות של פרמטרים מרכזיים, בהשוואה ל-BouncyCastle. לדוגמה, Conscrypt אינה מאפשרת לאפליקציה שלך ליצור מפתח AES מסוג 64 ביט מפני ש-AES תומך רק מקשים של 128, 192 ו-256 ביט.

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

  • אתחלת את ההצפנה של Galois/Counter Mode (GCM) באמצעות שימוש בגודל אחר מ-12 בייטים. ההטמעה של Conscrypt כדי להשתמש ב-GcmParameterSpec נדרש אתחול של 12 בייטים, לפי המלצת NIST.

התראות גישה ללוח

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

הטקסט בתוך הודעת ההודעה נשלחת בפורמט הבא: APP pasted from your clipboard.

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

ב-Android מגרסה 12 ואילך, אפליקציית getPrimaryClipDescription() יכולה לזהות את הפרטים הבאים:

לאפליקציות אין אפשרות לסגור את תיבות הדו-שיח של המערכת

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

  • אם האפליקציה מטרגטת את Android 12 ואילך, SecurityException.

  • אם האפליקציה מטרגטת את Android 11 (רמת API 30) ומטה, כוונת הרכישה לא וההודעה הבאה תופיע Logcat:

    E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.

חריגים

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

  • באפליקציה שלך פועל אינסטרומנטציה בדיקה.

  • האפליקציה שלך מטרגטת את Android 11 ומטה ומוצג בה חלון שמופיע בחלק העליון של ההתראה חלונית הזזה.

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

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

אירועי מגע לא מהימנים חסומים

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

אפליקציות שהושפעו

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

  • שכבות-על שמחייבות את הרכיב SYSTEM_ALERT_WINDOW למשל, חלונות שמשתמשים TYPE_APPLICATION_OVERLAY, ומשתמשים בדגל FLAG_NOT_TOUCHABLE.
  • חלונות של פעילות שבהם נעשה שימוש בדגל FLAG_NOT_TOUCHABLE.

חריגים

במקרים הבאים, האפשרות "מעבר" נגיעות מותרות:

  • אינטראקציות בתוך האפליקציה. האפליקציה מציגה את שכבת-העל ואת שכבת-העל מוצגת רק כשהמשתמש מקיים אינטראקציה עם האפליקציה.

  • חלונות מהימנים. חלונות אלה כוללים (בין היתר) הבאים:

  • חלונות נסתרים התצוגה הבסיסית של החלון היא GONE או INVISIBLE

  • חלונות שקופים לחלוטין. נכס alpha הוא 0.0 עבור החלון.

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

זיהוי כשנחסם מגע לא מהימן

אם המערכת חוסמת פעולת מגע, Logcat רושם את ההודעה הבאה ביומן:

Untrusted touch due to occlusion by PACKAGE_NAME

בדיקת השינוי

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

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

כדי להחזיר את ההתנהגות לברירת המחדל (נגיעות לא מהימנות חסומות), מפעילים את הפקודה הפקודה הבאה:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

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

פעולות ברמה הבסיסית (root) של מרכז האפליקציות לא הסתיימו בלחיצה על 'הקודם'

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

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

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

חשוב גם לשים לב שבאופן כללי, מומלץ להשתמש בממשקי ה-API של AndroidX לפעילות. לספק ניווט אחורה מותאם אישית, במקום לשנות את onBackPressed(). ממשקי ה-API של AndroidX Activity לדחות אוטומטית את התנהגות המערכת המתאימה אם אין רכיבים שמיירטים את פעולת 'אחורה' של המערכת.

גרפיקה ותמונות

שיפור בקצב הרענון

ב-Android 12, קצב הרענון משתנה באמצעות setFrameRate() יכול לקרות גם אם המסך תומך במעבר חלק אל קצב הרענון החדש; מעבר חלק הוא כזה שאין בו הפרעות, למשל מסך שחור למשך שנייה או שתיים. בעבר, אם רשת המדיה לא תמכה במעבר חלק, בדרך כלל הוא ימשיך להשתמש אותו קצב רענון אחרי הקריאה של setFrameRate(). אפשר לקבוע כאן אם המעבר לרענון החדש יהיה חלק ככל האפשר, התקשרות אל getAlternativeRefreshRates(). באופן כללי, הקריאה החוזרת (callback) onDisplayChanged() נשלחת קריאה אחרי ששינוי קצב הרענון מסתיים, אבל עבור חלק במסכים שמחוברים לגורמים חיצוניים, מתבצעת קריאה במהלך מעבר לא חלק.

הדוגמה הבאה ממחישה איך ליישם את ההנחיות:

Kotlin

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Java

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

קישוריות

עדכונים ל-Passpoint

ממשקי ה-API הבאים נוספים ב-Android 12:

  • isPasspointTermsAndConditionsSupported(): התנאים וההגבלות הם נקודת Passpoint שמאפשרת לפריסות רשת להחליף פורטלים שבויים לא מאובטחים שמשתמשות ברשתות פתוחות, עם רשת Passpoint מאובטחת. התראה היא תוצג למשתמש כאשר יש לאשר את התנאים וההגבלות. אפליקציות שמציעות רשתות Passpoint שמוגבלות בתנאים ובהגבלות חייבים לקרוא קודם ל-API הזה כדי לוודא שהמכשיר תומך ביכולת. אם המכשיר לא תומך ביכולת, לא תהיה לו אפשרות להתחבר את הרשת הזו, ולהציג רשת חלופית או מדור קודם.

  • isDecoratedIdentitySupported(): כשמבצעים אימות לרשתות עם קידומת, המערכת מקושטת תחילית הזהות מאפשרת למפעילי רשת לעדכן את הגישה לרשת מזהה (NAI) שמאפשר לבצע ניתוב מפורש דרך מספר שרתי proxy בתוך של רשת AAA (ראו RFC 7542 עבור בנושא).

    ב-Android 12 התכונה הזו מוטמעת כדי לעמוד בדרישות של מפרט WBA PPS-MO תוספים. באפליקציות שמציעות רשתות Passpoint שנדרשת להן זהות מקושטת צריך להפעיל את ה-API הזה קודם כדי לוודא שהמכשיר תומך ביכולת. אם המיקום המכשיר לא תומך ביכולת, הזהות לא תופיע והאימות ברשת עלול להיכשל.

כדי ליצור הצעה של Passpoint, האפליקציות חייבות להשתמש ב PasspointConfiguration Credential, וגם HomeSp כיתות. האלה מחלקות מתארות את פרופיל Passpoint, שמוגדר ב-Wi-Fi Alliance פרוטוקול Passpoint המפרט.

מידע נוסף אפשר למצוא במאמר על Wi-Fi Offers API לחיבור אינטרנט.

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

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

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

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

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