פלטפורמת 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, התנהגות קיימת אוחדה כדי להקל על המשתמשים לבצע פקודות ניווט באמצעות מחוות במצב סוחף. בנוסף, ב-Android 12 יש התנהגות של תאימות לאחור למצב סטיקי אימרסיבי.
Display#getRealSize ו-getRealMetrics: הוצאה משימוש ומגבלות
מכשירי Android זמינים במגוון רחב של גדלים וצורות, כמו מסכים גדולים, טאבלטים ומכשירים מתקפלים. כדי שהתוכן יוצג בצורה מתאימה בכל מכשיר, האפליקציה צריכה לקבוע את גודל המסך או התצוגה. עם הזמן, מערכת Android סיפקה ממשקי API שונים לאחזור המידע הזה. ב-Android 11, השקנו את WindowMetrics API והוצאנו משימוש את השיטות הבאות:
ב-Android 12 אנחנו ממשיכים להמליץ על שימוש ב-WindowMetrics, ומפסיקים את התמיכה בשיטות הבאות:
כדי לצמצם את ההשפעה של התנהגות האפליקציות שמשתמשות בממשקי Display API כדי לאחזר את הגבולות של האפליקציה, ב-Android 12 יש הגבלות על הערכים שמוחזרים על ידי ממשקי ה-API עבור אפליקציות שלא ניתן לשנות את הגודל שלהן באופן מלא. הדבר הזה עלול להשפיע על אפליקציות שמשתמשות במידע הזה עם MediaProjection.
אפליקציות צריכות להשתמש בממשקי WindowMetrics API כדי לשלוח שאילתה לגבי הגבולות של החלון שלהן, וב-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) הוצג restricted bucket כ-App Standby Bucket. החל מ-Android 12, הדלי הזה פעיל כברירת מחדל. המאגר המוגבל הוא בעל העדיפות הנמוכה ביותר (וההגבלות המחמירות ביותר) מבין כל המאגרים. הקטגוריות מסודרות לפי סדר עדיפות מהגבוה לנמוך:
- פעילה: האפליקציה נמצאת בשימוש כרגע או שהיה בה שימוש לאחרונה.
- קבוצת עבודה: האפליקציה נמצאת בשימוש רגיל.
- תכוף: האפליקציה בשימוש לעיתים קרובות, אבל לא כל יום.
- נדיר: האפליקציה לא בשימוש לעיתים קרובות.
- גישה מוגבלת: האפליקציה צורכת כמות גדולה של משאבי מערכת, או עשויה להציג התנהגות לא רצויה.
המערכת בודקת את ההתנהגות של האפליקציה, בנוסף לדפוסי השימוש, כדי להחליט אם להוסיף את האפליקציה למאגר המוגבל.
הסיכוי שהאפליקציה שלכם תמוקם בדלי המוגבל נמוך יותר אם היא משתמשת במשאבי המערכת בצורה אחראית יותר. בנוסף, המערכת תמקם את האפליקציה שלכם בקטגוריה פחות מגבילה אם המשתמש יקיים אינטראקציה ישירה עם האפליקציה.
איך בודקים אם האפליקציה נמצאת בדלי המוגבל
כדי לבדוק אם המערכת מיקמה את האפליקציה שלכם בקטגוריה המוגבלת, מתקשרים אל getAppStandbyBucket().
אם ערך ההחזרה של השיטה הזו הוא STANDBY_BUCKET_RESTRICTED, האפליקציה שלכם נמצאת בדלי המוגבל.
בדיקת ההתנהגות של קטגוריה מוגבלת
כדי לבדוק איך האפליקציה מתנהגת כשהמערכת מעבירה אותה לקטגוריה המוגבלת, אפשר להעביר אותה לקטגוריה הזו באופן ידני. כדי לעשות זאת, מריצים את הפקודה הבאה בחלון טרמינל:
adb shell am set-standby-bucket PACKAGE_NAME restricted
מיקום בחזית וחיסכון בסוללה
החל מ-Android 12, אפשר להמשיך לספק מיקום בחזית (כולל משירות שפועל בחזית) בזמן שמצב חיסכון בסוללה פעיל, גם כשהמסך כבוי.
בעבר, מצב חיסכון בסוללה הפסיק את עדכוני המיקום כשהמסך היה כבוי. השינוי הזה משפר את חיי הסוללה של המשתמשים, ומאפשר למפתחים להימנע מבקשה מהמשתמשים להשבית את מצב החיסכון בסוללה כדי להבטיח את מסירת המיקום.
אפליקציות שמבקשות מיקום דרך שירות שפועל בחזית צריכות לבצע את השלבים הבאים:
- מתקשרים אל
getLocationPowerSaverMode()כדי לבדוק איך תכונות המיקום של המכשיר פועלות כשמצב החיסכון בסוללה פעיל. - אם הפונקציה מחזירה
LOCATION_MODE_FOREGROUND_ONLY, האפליקציה תמשיך לקבל עדכוני מיקום כשהיא פועלת בחזית או כשירות בחזית, גם כשמצב חיסכון בסוללה מופעל והמסך כבוי.
אבטחה ופרטיות
מיקום משוער
במכשירים עם 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. ההטמעה של Conscrypt ב-KeyGeneratorמבצעת אימות נוסף של פרמטרים מרכזיים, בהשוואה ל-BouncyCastle. לדוגמה, Conscrypt לא מאפשר לאפליקציה שלכם ליצור מפתח AES של 64 ביט, כי AES תומך רק במפתחות של 128, 192 ו-256 ביט.BouncyCastle מאפשר ליצור מפתחות בגדלים לא תקינים, אבל נכשל בהמשך אם משתמשים במפתחות האלה עם
Cipher. השגיאה ב-Conscrypt מתרחשת מוקדם יותר.אתם מאתחלים את הצפנים שלכם ב-Galois/Counter Mode (GCM) באמצעות גודל שונה מ-12 בייט. ההטמעה של
GcmParameterSpecב-Conscrypt דורשת אתחול של 12 בייט, כפי שמומלץ על ידי NIST.
התראות על גישה ללוח העריכה
ב-Android 12 ואילך, כשמתבצעת קריאה לאפליקציה getPrimaryClip() כדי לגשת לנתוני לוח מאפליקציה אחרת בפעם הראשונה, מוצגת למשתמש הודעה קצרה על הגישה ללוח.
הטקסט בהודעה הקופצת הוא בפורמט הבא:
APP pasted from your clipboard.
מידע על טקסט בתיאור של קליפ
ב-Android 12 ומעלה, אפשר להשתמש ב-getPrimaryClipDescription() כדי לזהות את הפרטים הבאים:
- טקסט מסוגנן, באמצעות
isStyledText(). - סיווגים שונים של טקסט, כמו כתובות URL, באמצעות
getConfidenceScore().
אפליקציות לא יכולות לסגור תיבות דו-שיח של המערכת
כדי לשפר את השליטה של המשתמשים באינטראקציה עם אפליקציות ועם המערכת, הוצאנו משימוש את פעולת ה-intent ACTION_CLOSE_SYSTEM_DIALOGS החל מ-Android 12. במקרים שבהם האפליקציה מנסה להפעיל
intent שמכיל את הפעולה הזו, המערכת מבצעת אחת מהפעולות הבאות בהתאם לגרסת ה-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 בחלון.חלונות התראות מערכת שקופים במידה מספקת. המערכת מחשיבה קבוצה של חלונות התראות במערכת כשקופים מספיק אם השקיפות המשולבת קטנה או שווה לשקיפות המקסימלית של המערכת להסתרה של מגעים. ב-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() מעבירה את הפעילות ואת המשימה שלה לרקע כשצריך, ומספקת למשתמשים חוויית ניווט עקבית יותר באפליקציות.
חשוב גם לציין שבדרך כלל מומלץ להשתמש בממשקי AndroidX Activity API כדי לספק ניווט מותאם אישית אחורה, במקום להחליף את onBackPressed(). ממשקי ה-API של AndroidX Activity
מועברים אוטומטית להתנהגות המערכת המתאימה אם אין רכיבים
שמיירטים את הלחיצה על לחצן 'הקודם' במערכת.
גרפיקה ותמונות
שיפור במעבר בין קצבי רענון
ב-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(): Terms and conditions היא תכונה של 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 for internet connectivity.
עדכון ההגבלות על ממשקים שאינם ב-SDK
Android 12 כולל רשימות מעודכנות של ממשקי non-SDK מוגבלים, שמבוססות על שיתוף פעולה עם מפתחי Android ועל הבדיקות הפנימיות האחרונות. כשאפשר, אנחנו מוודאים שיש חלופות ציבוריות לפני שאנחנו מגבילים ממשקים שאינם ב-SDK.
אם האפליקציה שלכם לא מטרגטת ל-Android 12, יכול להיות שחלק מהשינויים האלה לא ישפיעו עליכם באופן מיידי. עם זאת, למרות שכרגע אפשר להשתמש בחלק מהממשקים שאינם חלק מ-SDK (בהתאם לרמת ה-API לטירגוט של האפליקציה), שימוש בשיטה או בשדה שלא נכללים ב-SDK תמיד כרוך בסיכון גבוה להפסקת הפעולה של האפליקציה.
אם אתם לא בטוחים אם האפליקציה שלכם משתמשת בממשקים שאינם SDK, אתם יכולים לבצע בדיקה לאפליקציה כדי לגלות זאת. אם האפליקציה שלכם מסתמכת על ממשקים שלא נכללים ב-SDK, כדאי להתחיל לתכנן מעבר לחלופות ל-SDK. עם זאת, ברור לנו שיש אפליקציות שבהן יש תרחישי שימוש לגיטימיים בממשקים שאינם SDK. אם אין לכם אפשרות להשתמש בממשק חלופי במקום בממשק שאינו ב-SDK עבור תכונה באפליקציה, עליכם לבקש ממשק API ציבורי חדש.
מידע נוסף על השינויים בגרסה הזו של Android זמין במאמר עדכונים בהגבלות על ממשקי SDK שאינם חלק מ-Android 12. מידע נוסף על ממשקים שאינם ב-SDK זמין במאמר הגבלות על ממשקים שאינם ב-SDK.