פלטפורמת 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 של העיצוב (אם הוא בצבע אחד).
פרטים נוספים זמינים במדריך למפתחים בנושא מסכי פתיחה.
פתרון Intent באינטרנט
החל מ-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.