פלטפורמת Android 12 כוללת שינויים בהתנהגות שעשויים להשפיע על האפליקציה שלכם. שינויי ההתנהגות הבאים חלים על כל האפליקציות כשהן פועלות ב-Android 12, ללא קשר ל-targetSdkVersion. מומלץ לבדוק את האפליקציה ולאחר מכן לשנות אותה לפי הצורך כדי לתמוך בהם כראוי, במקרים הרלוונטיים.
חשוב גם לעיין ברשימת השינויים בהתנהגות שמשפיעים רק על אפליקציות שמטרגטות ל-Android 12.
חוויית משתמש
אפקט של גלילת יתר
במכשירים עם Android מגרסה 12 ואילך, ההתנהגות החזותית של אירועי גלילת יתר משתנה.
ב-Android 11 ובגרסאות ישנות יותר, אירוע של גלילה מעבר לקצה המסך גורם לרכיבים החזותיים להאיר. ב-Android 12 ובגרסאות מתקדמות יותר, הרכיבים החזותיים נמתחים וקופצים בחזרה באירוע גרירה, והם נשלחים במהירות וקופצים בחזרה באירוע של שליחה במהירות.
מידע נוסף מופיע במדריך לאנימציה של תנועות גלילה.
מסכי פתיחה של אפליקציות
אם הטמעתם בעבר מסך פתיחה מותאם אישית ב-Android 11 ואילך, תצטרכו להעביר את האפליקציה ל-SplashScreen API כדי לוודא שהיא תוצג בצורה תקינה החל מ-Android 12. אם לא תעברו את האפליקציה, חוויית ההפעלה שלה תיפגע או תהיה שונה מהתכוונות שלכם.
להוראות, אפשר לעיין במאמר העברת ההטמעה הקיימת של מסך הפתיחה ל-Android 12.
בנוסף, החל מ-Android 12, המערכת תמיד מחילה את מסך הפתיחה החדש שמוגדר כברירת מחדל במערכת Android בכל האפליקציות בהפעלה ראשונית ובהפעלה מחדש.
ברירת המחדל של מסך הפתיחה היא שימוש ברכיב הסמל של האפליקציה במרכז האפליקציות ובסמל windowBackground של העיצוב (אם הוא בצבע אחד).
לפרטים נוספים אפשר לעיין במדריך למפתחים של מסכי פתיחה.
פתרון של כוונת השימוש באינטרנט
החל מ-Android 12 (רמת API 31), כוונה כלליות לאינטרנט מומרות לפעילות באפליקציה רק אם האפליקציה אושרה לדומיין הספציפי שמופיע בכוונה הזו לאינטרנט. אם האפליקציה לא אושרה לדומיין, ה-Intent באינטרנט עובר לאפליקציית הדפדפן שהוגדרה כברירת מחדל של המשתמש.
אפליקציות יכולות לקבל את האישור הזה באחת מהדרכים הבאות:
מאמתים את הדומיין באמצעות קישורים לאפליקציות ל-Android.
באפליקציות שמטרגטות ל-Android 12 ואילך, המערכת משנה את האופן שבו היא מאמתת באופן אוטומטי את הקישורים לאפליקציה שלכם ב-Android. במסנני הכוונה של האפליקציה, מוודאים שכלולה בהם הקטגוריה
BROWSABLEושיש תמיכה בסכימהhttps.ב-Android מגרסה 12 ואילך, אפשר לאמת באופן ידני את הקישורים לאפליקציות ל-Android, כדי לבדוק איך הלוגיקה המעודכנת הזו משפיעה על האפליקציה.
בקשו מהמשתמש לשייך את האפליקציה לדומיין בהגדרות המערכת.
אם האפליקציה שלכם מפעילה כוונות אינטרנט, כדאי להוסיף הנחיה או תיבת דו-שיח שמבקשות מהמשתמש לאשר את הפעולה.
שיפורים במצב של תצוגה היקפית לניווט באמצעות תנועות
ב-Android 12, ההתנהגות הקיימת מאוחדת כדי למשתמשים יהיה קל יותר לבצע פקודות ניווט באמצעות תנועות בזמן מצב immersive. בנוסף, ב-Android 12 יש התנהגות תאימות לאחור למצב 'הקשה ביד אחת'.
Display#getRealSize ו-getRealMetrics: הוצאה משימוש ומגבלות
מכשירי Android זמינים במגוון פורמטים שונים, כמו מסכים גדולים, טאבלטים ומכשירים מתקפלים. כדי להציג את התוכן בצורה מתאימה לכל מכשיר, האפליקציה צריכה לקבוע את גודל המסך או התצוגה. עם הזמן, מערכת Android סיפקה ממשקי API שונים לאחזור המידע הזה. ב-Android 11 הוספנו את ה-API WindowMetrics והוצאנו משימוש את השיטות הבאות:
ב-Android 12 אנחנו ממשיכים להמליץ להשתמש ב-WindowMetrics, ומוציאים משימוש את השיטות הבאות:
כדי לצמצם את ההתנהגות של אפליקציות שמשתמשות בממשקי Display API כדי לאחזר את גבולות האפליקציה, ב-Android 12 יש הגבלות על הערכים שמוחזרים על ידי ממשקי ה-API לאפליקציות שלא ניתן לשנות את הגודל שלהן באופן מלא. השינוי הזה עשוי להשפיע על אפליקציות שמשתמשות במידע הזה באמצעות MediaProjection.
אפליקציות צריכות להשתמש בממשקי ה-API של WindowMetrics כדי לשלוח שאילתה לגבי גבולות החלון שלהן, וב-Configuration.densityDpi כדי לשלוח שאילתה לגבי הצפיפות הנוכחית.
לתאימות רחבה יותר לגרסאות ישנות של Android, תוכלו להשתמש בספריית Jetpack WindowManager, שכוללת מחלקה של WindowMetrics שתומכת ב-Android 4.0 (רמת API 14) ואילך.
דוגמאות לשימוש ב-WindowMetrics
קודם כול, חשוב לוודא שאפשר לשנות את הגודל של הפעילויות באפליקציה.
פעילות צריכה להסתמך על WindowMetrics מההקשר של הפעילות לכל עבודה שקשורה לממשק המשתמש, במיוחד WindowManager.getCurrentWindowMetrics() או WindowMetricsCalculator.computeCurrentWindowMetrics() של Jetpack.
אם האפליקציה יוצרת 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, הקטגוריה הזו פעילה כברירת מחדל. הקטגוריה המוגבלת היא בעלת העדיפות הנמוכה ביותר (וההגבלות הגבוהות ביותר) מבין כל הקטגוריות. הקטגוריות לפי סדר עדיפות, מהגבוהה לנמוכה:
- פעילה: האפליקציה נמצאת בשימוש או שהייתה בשימוש לאחרונה.
- קבוצת עבודה: האפליקציה נמצאת בשימוש קבוע.
- תדירות גבוהה: משתמשים באפליקציה לעיתים קרובות, אבל לא כל יום.
- נדיר: לא משתמשים באפליקציה לעיתים קרובות.
- מוגבלת: האפליקציה צורכת כמות גדולה של משאבי מערכת, או שההתנהגות שלה לא רצויה.
המערכת מביאה בחשבון את התנהגות האפליקציה, בנוסף לדפוסי השימוש, כדי להחליט אם להעביר את האפליקציה לקטגוריה המוגבלת.
אם האפליקציה משתמשת במשאבי המערכת באופן אחראי יותר, יש סיכוי נמוך יותר שהיא תמוקם בקטגוריה המוגבלת. בנוסף, אם המשתמש יוצר אינטראקציה ישירה עם האפליקציה, המערכת תמייק אותה לקטגוריה פחות מגבילה.
איך בודקים אם האפליקציה נמצאת בקטגוריה המוגבלת
כדי לבדוק אם המערכת הוסיפה את האפליקציה שלכם לקטגוריה המוגבלת, צריך להפעיל את הפונקציה getAppStandbyBucket().
אם ערך ההחזרה של השיטה הזו הוא STANDBY_BUCKET_RESTRICTED, האפליקציה שלכם נמצאת בקטגוריה המוגבלת.
בדיקת ההתנהגות של קטגוריה מוגבלת
כדי לבדוק איך האפליקציה מתנהגת כשהמערכת מעבירה אותה לקטגוריה המוגבלת, אפשר להעביר אותה לקטגוריה הזו באופן ידני. כדי לעשות זאת, מריצים את הפקודה הבאה בחלון טרמינל:
adb shell am set-standby-bucket PACKAGE_NAME restricted
אבטחה ופרטיות
מיקום משוער
במכשירים עם Android מגרסה 12 ואילך, משתמשים יכולים לבקש שהאפליקציה תקבל גישה רק למידע על מיקום משוער.
אם האפליקציה שלכם מבקשת את הרשאת זמן הריצה ACCESS_FINE_LOCATION, עליכם לבקש גם את ההרשאה ACCESS_COARSE_LOCATION כדי לטפל במקרה שבו המשתמש מעניק לאפליקציה גישה למיקום המשוער. עליכם לכלול את שתי ההרשאות בבקשה אחת בזמן הריצה.
תיבת הדו-שיח של הרשאות המערכת כוללת את האפשרויות הבאות למשתמש, כפי שמוצג באיור 1:
- מדויק: גישה למידע מדויק על המיקום.
- משוער: גישה רק למידע משוער על המיקום.
מתגי גישה למיקרופון ולמצלמה
במכשירים נתמכים עם Android מגרסה 12 ואילך, המשתמשים יכולים להפעיל ולהשבית את הגישה של המצלמה והמיקרופון לכל האפליקציות במכשיר בלחיצה על מתג יחיד. המשתמשים יכולים לגשת לאפשרויות ההחלפה מהגדרות מהירות, כפי שמוצג באיור 1, או ממסך הפרטיות בהגדרות המערכת.
מידע נוסף על לחצני החלפת המצב ועל האופן שבו בודקים שהאפליקציה פועלת בהתאם לשיטות המומלצות לגבי ההרשאות CAMERA ו-RECORD_AUDIO
אינדיקטורים שמציינים גישה למיקרופון ולמצלמה
במכשירים עם Android מגרסה 12 ואילך, כשאפליקציה ניגשת למיקרופון או למצלמה, מופיע סמל בשורת הסטטוס.
מידע נוסף על האינדיקטורים האלה ועל האופן שבו בודקים שהאפליקציה פועלת בהתאם לשיטות המומלצות לגבי ההרשאות CAMERA ו-RECORD_AUDIO
הרשאות גישה לחבילה
במכשירים עם Android בגרסה 12 ואילך, אפליקציות שמטרגטות את Android 11 (רמת API 30) ואילך וקריאות לאחת מה-methods הבאות מקבלות קבוצה מסוננת של תוצאות, על סמך הרשאות הגישה לחבילה של האפליקציה לאפליקציות אחרות:
הטמעת BouncyCastle הוסרה
ב-Android 12 מתבצעת הסרה של הרבה הטמעות של BouncyCastle של אלגוריתמים קריפטוגרפיים שהוצאו משימוש, כולל כל האלגוריתמים של AES. במקום זאת, המערכת משתמשת בהטמעות של האלגוריתם ב-Conscrypt.
השינוי הזה משפיע על האפליקציה שלכם אם מתקיים אחד מהתנאים הבאים:
- האפליקציה שלכם משתמשת בגדלים של מפתחות של 512 ביט. גודל המפתח הזה לא נתמך ב-Conscrypt. אם יש צורך, מעדכנים את הלוגיקה של האפליקציה בנושא הצפנה כך שתשתמש בגדלים שונים של מפתחות.
באפליקציה שלכם נעשה שימוש בגדלים מפתח לא תקינים עם
KeyGenerator. ההטמעה שלKeyGeneratorב-Conscrypt מבצעת אימות נוסף על פרמטרים של מפתחות, בהשוואה ל-BouncyCastle. לדוגמה, Conscrypt לא מאפשר לאפליקציה ליצור מפתח AES ב-64 ביט כי הוא תומך רק במפתחות של 128, 192 ו-256 ביט.ב-BouncyCastle אפשר ליצור מפתחות בגדלים לא חוקיים, אבל אם משתמשים במפתחות האלה עם
Cipher, המערכת נכשלת. הקידוד נכשל מוקדם יותר.אתם מאתחלים את הצפנים של Galois/Counter Mode (GCM) באמצעות גודל שונה מ-12 בייטים. ההטמעה של
GcmParameterSpecב-Conscrypt דורשת אתחול של 12 בייטים, כפי שמומלץ על ידי NIST.
התראות לגישה ללוח העריכה
ב-Android 12 ואילך, כשאפליקציה מבצעת קריאה ל-getPrimaryClip() כדי לגשת לנתוני קליפ מאפליקציה אחרת בפעם הראשונה, מוצגת הודעה על גבי המסך כדי להודיע למשתמש על הגישה הזו ללוח.
הטקסט בהודעת ה-Toast מכיל את הפורמט הבא:
APP pasted from your clipboard.
מידע על טקסט בתיאור של קליפים
ב-Android 12 ואילך, getPrimaryClipDescription() יכול לזהות את הפרטים הבאים:
- טקסט מסוגנן, באמצעות
isStyledText(). - סיווגים שונים של טקסט, כמו כתובות URL, באמצעות
getConfidenceScore().
אפליקציות לא יכולות לסגור תיבת דו-שיח של מערכת
כדי לשפר את השליטה של המשתמשים בזמן אינטראקציה עם אפליקציות ועם המערכת, החל מ-Android 12 אנחנו מוציאים משימוש את הפעולה של כוונת הרכישה ACTION_CLOSE_SYSTEM_DIALOGS. מלבד מקרים מיוחדים, כשהאפליקציה מנסה להפעיל כוונה שמכילה את הפעולה הזו, המערכת מבצעת אחת מהפעולות הבאות על סמך גרסת ה-SDK היעד של האפליקציה:
- אם האפליקציה שלכם מטרגטת ל-Android מגרסה 12 ואילך, מתרחש אירוע
SecurityException. אם האפליקציה מטרגטת ל-Android 11 (רמת API 30) וגרסאות קודמות, ה-intent לא מופעל וההודעה הבאה מופיעה ב-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.חלונות התראות מערכת שקופים מספיק. המערכת מתייחסת לקבוצה של חלונות התראות מערכת כאל חלונות שקופים מספיק כשהעכירות המשולבת שלהם קטנה מ-100% או שווה ל-100%, בהתאם לעכירות המקסימלית של המערכת להסתרת מגע. ב-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
מחזור החיים של פעילות
פעילויות של מרכז האפליקציות ברמה הבסיסית לא מסתיימות יותר בלחיצה על 'הקודם'
ב-Android 12, המערכת משנה את ברירת המחדל של הקשה על 'הקודם' בפעילויות במרכז האפליקציות שנמצאות בשורש המשימות שלהן. בגרסאות קודמות, המערכת הייתה מסיימת את הפעילויות האלה בלחיצה על 'חזרה'. ב-Android 12, עכשיו המערכת מעבירה את הפעילות ואת המשימה שלה לרקע במקום לסיים את הפעילות. ההתנהגות החדשה תואמת להתנהגות הנוכחית כשמנווטים מחוץ לאפליקציה באמצעות הלחצן הראשי או תנועה.
ברוב האפליקציות, השינוי הזה אומר שמשתמשים שמשתמשים בלחצן 'הקודם' כדי לצאת מהאפליקציה יוכלו להמשיך להשתמש בה מהר יותר ממצב חם, במקום להפעיל מחדש את האפליקציה לגמרי ממצב קר.
מומלץ לבדוק את האפליקציות שלכם עם השינוי הזה. אם האפליקציה שלכם מעדכנת כרגע את onBackPressed() כדי לטפל בניווט חזרה ולסיים את ה-Activity, עליכם לעדכן את ההטמעה כך שתתבצע קריאה ל-super.onBackPressed() במקום לסיים. כשקוראים ל-super.onBackPressed(), הפעילות והמשימה שלה מועברות לרקע כשזה מתאים, ומספקות למשתמשים חוויית ניווט עקבית יותר באפליקציות השונות.
חשוב לזכור גם שבאופן כללי, מומלץ להשתמש בממשקי ה-API של AndroidX לפעילות כדי לספק ניווט אחורה בהתאמה אישית, במקום לשנות את onBackPressed(). ממשקי ה-API של AndroidX לפעילות מאפשרים למערכת לפעול באופן מתאים באופן אוטומטי אם אין רכיבים שחוסמים את לחיצה על 'הקודם' במערכת.
גרפיקה ותמונות
שיפור בקצב הרענון
ב-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, שמוגדר במפרט Passpoint של Wi-Fi Alliance.
מידע נוסף זמין במאמר Wi-Fi suggestion API לקישוריות לאינטרנט.
עדכנו את ההגבלות על ממשקים שאינם SDK
ב-Android 12 יש רשימות מעודכנות של פלטפורמות מוגבלות ללא SDK שמבוסס על שיתוף פעולה עם מפתחי Android והבדיקות הפנימיות העדכניות ביותר. כשהדבר אפשרי, אנחנו מוודאים שיש חלופות ציבוריות זמינות לפני שאנחנו מגבילים ממשקים שאינם SDK.
אם האפליקציה שלכם לא מטרגטת את Android 12, יכול להיות שחלק מהשינויים האלה לא ישפיעו עליכם באופן מיידי. עם זאת, אפשר להשתמש כרגע בממשקים מסוימים שאינם SDK (בהתאם לרמת ה-API לטירגוט של האפליקציה), אבל שימוש בשדה או בשיטה שאינם SDK תמיד כרוך בסיכון גבוה לקריסת האפליקציה.
אם אתם לא בטוחים אם באפליקציה שלכם נעשה שימוש בממשקים שאינם SDK, תוכלו לבדוק את האפליקציה כדי לברר זאת. אם האפליקציה שלכם מסתמכת על ממשקים שאינם ב-SDK, כדאי להתחיל לתכנן את המעבר לחלופות ל-SDK. עם זאת, אנחנו מבינים שלאפליקציות מסוימות יש תרחישים שימוש חוקיים לשימוש בממשקים שאינם SDK. אם לא מצאתם חלופה לשימוש בממשק שאינו ב-SDK עבור תכונה באפליקציה, עליכם לבקש ממשק API ציבורי חדש.
למידע נוסף על השינויים בגרסה הזו של Android, ראו עדכונים להגבלות על ממשקים שאינם SDK ב-Android 12. מידע נוסף על ממשקים שאינם ב-SDK זמין במאמר הגבלות על ממשקים שאינם ב-SDK.