פלטפורמת 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, תוכלו להשתמש בספריית 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, המערכת נכשלת. 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.
חריגים
במקרים הבאים, מותר לבצע 'מעבר' של נגיעות:
- אינטראקציות באפליקציה. השכבה העליונה מוצגת באפליקציה, והיא מופיעה רק כשהמשתמש מקיים אינטראקציה עם האפליקציה.
חלונות מהימנים. החלונות האלה כוללים (בין היתר) את הדברים הבאים:
חלונות שקופים לחלוטין. המאפיין
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
מחזור החיים של פעילות
פעולות ברמה הבסיסית (root) של מרכז האפליקציות לא הסתיימו בלחיצה על 'הקודם'
מערכת Android 12 משנה את טיפול ברירת המחדל במערכת, לוחצים על 'חזרה' בלחיצה על פעילויות במרכז האפליקציות שנמצאות ברמה הבסיסית (root) של המשימות שלהן. בגרסאות קודמות, המערכת הייתה מסיימת את הפעילויות האלה בלחיצה על 'הקודם'. ב-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, שמוגדר במפרט נקודת הגישה של Wi-Fi Alliance.
מידע נוסף אפשר למצוא במאמר על Wi-Fi Offers API לחיבור אינטרנט.
עדכנו את ההגבלות על ממשקים שאינם SDK
ב-Android 12 יש רשימות מעודכנות של פלטפורמות מוגבלות ללא SDK שמבוסס על שיתוף פעולה עם מפתחי Android והבדיקות הפנימיות העדכניות ביותר. כשהדבר אפשרי, אנחנו מוודאים שחלופות ציבוריות זמינות לפני שאנחנו מגבילים ממשקים שהם לא SDK.
אם האפליקציה שלכם לא מטרגטת את Android 12, יכול להיות שחלק מהשינויים האלה לא ישפיעו עליכם באופן מיידי. עם זאת, אפשר להשתמש כרגע בממשקים מסוימים שאינם SDK (בהתאם לרמת ה-API לטירגוט של האפליקציה), אבל שימוש בשדה או בשיטה שאינם SDK תמיד כרוך בסיכון גבוה לקריסת האפליקציה.
אם אתם לא בטוחים אם באפליקציה שלכם נעשה שימוש בממשקים שאינם SDK, תוכלו לבדוק את האפליקציה כדי לברר זאת. אם האפליקציה שלכם מסתמכת על ממשקים שאינם ב-SDK, כדאי להתחיל לתכנן את המעבר לחלופות ל-SDK. עם זאת, אנחנו מבינים שלאפליקציות מסוימות יש תרחישים שימוש חוקיים לשימוש בממשקים שאינם SDK. אם אתם לא מוצאים חלופה לשימוש בממשק שאינו SDK עבור תכונה באפליקציה, אתם צריכים לבקש ממשק API ציבורי חדש.
מידע נוסף על השינויים בגרסה הזו של Android זמין במאמר עדכונים לגבי הגבלות על ממשקים שאינם SDK ב-Android 12. למידע נוסף על ממשקים שאינם SDK, ראו הגבלות על ממשקים שאינם SDK.