פלטפורמת 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), כוונה כלליות לאינטרנט מומרות לפעילות באפליקציה רק אם האפליקציה אושרה לדומיין הספציפי שמופיע בכוונה הזו לאינטרנט. אם האפליקציה לא אושרה לדומיין, כוונה האינטרנט תופנה במקום זאת לאפליקציית הדפדפן שמוגדרת כברירת מחדל של המשתמש.
אפליקציות יכולות לקבל את האישור הזה באחת מהדרכים הבאות:
מאמתים את הדומיין באמצעות קישורים לאפליקציות ל-Android.
באפליקציות שמטרגטות ל-Android 12 ואילך, המערכת משנה את האופן שבו היא מאמתת באופן אוטומטי את הקישורים לאפליקציה שלכם ב-Android. במסנני הכוונה של האפליקציה, מוודאים שכלולה בהם הקטגוריה
BROWSABLEושיש תמיכה בסכימהhttps.ב-Android 12 ואילך, תוכלו לאמת באופן ידני את קישורי האפליקציות ל-Android של האפליקציה שלכם, כדי לבדוק איך הלוגיקה המעודכנת הזו משפיעה על האפליקציה.
בקשו מהמשתמש לשייך את האפליקציה לדומיין בהגדרות המערכת.
אם האפליקציה שלכם מפעילה כוונות אינטרנט, כדאי להוסיף הנחיה או תיבת דו-שיח שבה המשתמש יתבקש לאשר את הפעולה.
שיפורים במצב של תצוגה היקפית לניווט באמצעות תנועות
ב-Android 12 משולב ההתנהגות הקיימת כדי למשתמשים יהיה קל יותר לבצע פקודות ניווט באמצעות תנועות בזמן מצב immersive. בנוסף, ב-Android 12 יש התנהגות של תאימות לאחור למצב immersive דביק.
Display#getRealSize ו-getRealMetrics: הוצאה משימוש ומגבלות
מכשירי Android זמינים במגוון פורמטים שונים, כמו מסכים גדולים, טאבלטים ומכשירים מתקפלים. כדי להציג את התוכן בצורה מתאימה לכל מכשיר, האפליקציה צריכה לקבוע את גודל המסך או התצוגה. עם הזמן, מערכת Android סיפקה ממשקי API שונים לאחזור המידע הזה. ב-Android 11 הוספנו את ה-API WindowMetrics והוצאנו משימוש את השיטות הבאות:
ב-Android 12 אנחנו ממשיכים להמליץ להשתמש ב-WindowMetrics, ומוציאים משימוש את השיטות הבאות:
כדי לצמצם את ההתנהגות של אפליקציות שמשתמשות בממשקי Display API כדי לאחזר את גבולות האפליקציה, ב-Android 12 יש הגבלות על הערכים שמוחזרים על ידי ממשקי ה-API לאפליקציות שלא ניתן לשנות את הגודל שלהן באופן מלא. השינוי הזה עשוי להשפיע על אפליקציות שמשתמשות במידע הזה באמצעות MediaProjection.
אפליקציות צריכות להשתמש בממשקי ה-API של WindowMetrics כדי לשלוח שאילתה לגבי גבולות החלון שלהן, וב-Configuration.densityDpi כדי לשלוח שאילתה לגבי הצפיפות הנוכחית.
כדי לשפר את התאימות לגרסאות ישנות יותר של Android, אפשר להשתמש בספרייה WindowManager של Jetpack, שכוללת את הכיתה 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) ואילך ומפעילות אחת מהשיטות הבאות מקבלות קבוצה מסוננת של תוצאות, על סמך החשיפה של החבילה של האפליקציה באפליקציות אחרות:
ההטמעה של BouncyCastle הוסרה
ב-Android 12 הוסרו הרבה הטמעות של BouncyCastle של אלגוריתמים קריפטוגרפיים שהוצאו משימוש בעבר, כולל כל אלגוריתמי ה-AES. במקום זאת, המערכת משתמשת בהטמעות של האלגוריתם ב-Conscrypt.
השינוי הזה משפיע על האפליקציה שלכם אם מתקיים אחד מהתנאים הבאים:
- האפליקציה שלכם משתמשת בגדלים של מפתחות של 512 ביט. גודל המפתח הזה לא נתמך ב-Conscrypt. אם יש צורך, מעדכנים את הלוגיקה של האפליקציה בנושא הצפנה כך שתשתמש בגדלים שונים של מפתחות.
באפליקציה שלכם נעשה שימוש בגדלים מפתח לא תקינים עם
KeyGenerator. ההטמעה שלKeyGeneratorב-Conscrypt מבצעת אימות נוסף על פרמטרים של מפתחות, בהשוואה ל-BouncyCastle. לדוגמה, Conscrypt לא מאפשר לאפליקציה ליצור מפתח AES של 64 ביט כי AES תומך רק במפתחות של 128, 192 ו-256 ביט.ב-BouncyCastle אפשר ליצור מפתחות בגדלים לא חוקיים, אבל אם משתמשים במפתחות האלה עם
Cipher, המערכת נכשלת. Conscrypt נכשל בשלב מוקדם יותר.אתם מאתחלים את הצפנים של 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().
באופן כללי, הקריאה החוזרת 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.