שינויים בהתנהגות: כל האפליקציות

פלטפורמת Android 12 כוללת שינויים בהתנהגות שעשויים להשפיע על האפליקציה שלכם. שינויי ההתנהגות הבאים רלוונטיים לכל האפליקציות שפועלות ב-Android 12, בלי קשר ל-targetSdkVersion. אתם צריכים לבדוק את האפליקציה ולשנות אותה לפי הצורך כדי שהיא תתמוך בהם בצורה תקינה, במקרים הרלוונטיים.

חשוב גם לבדוק את רשימת השינויים בהתנהגות שמשפיעים רק על אפליקציות שמטרגטות ל-Android 12.

חוויית משתמש

אפקט המתיחה מעבר לקצה

במכשירים עם Android מגרסה 12 ואילך, ההתנהגות החזותית של אירועי גלילת יתר משתנה.

ב-Android מגרסה 11 ומטה, אירוע של גלילה מעבר לקצה גורם לרכיבים החזותיים להאיר. ב-Android מגרסה 12 ומעלה, הרכיבים החזותיים נמתחים וחוזרים למצב הקודם באירוע של גרירה, והם נזרקים וחוזרים למצב הקודם באירוע של זריקה.

מידע נוסף זמין במדריך בנושא הוספת אנימציה לתנועות גלילה.

מסכי פתיחה של אפליקציות

אם הטמעתם בעבר מסך פתיחה בהתאמה אישית ב-Android בגרסה 11 או בגרסה קודמת, תצטרכו להעביר את האפליקציה ל-API של SplashScreen כדי לוודא שהיא תוצג בצורה תקינה החל מ-Android בגרסה 12. אם לא תעבירו את האפליקציה, חוויית ההפעלה של האפליקציה תהיה פחות טובה או לא כמו שהתכוונתם.

כאן מוסבר איך להעביר את ההטמעה הקיימת של מסך הפתיחה ל-Android 12.

בנוסף, החל מ-Android 12, המערכת תמיד מפעילה את מסך הפתיחה החדש שמוגדר כברירת המחדל של המערכת ב-Android בהפעלה קרה ובהפעלה חמה בכל האפליקציות. כברירת מחדל, מסך הפתיחה של המערכת נוצר באמצעות רכיב סמל מרכז האפליקציות של האפליקציה והמאפיין windowBackground של העיצוב (אם הוא בצבע אחיד).

פרטים נוספים זמינים במדריך למפתחים בנושא מסכי פתיחה.

רזולוציית Intent באינטרנט

החל מ-Android 12 (רמת API‏ 31), Intent גנרי של אינטרנט מפעיל פעילות באפליקציה רק אם האפליקציה אושרה לדומיין הספציפי שכלול ב-Intent הזה. אם האפליקציה לא אושרה לדומיין, ה-Intent באינטרנט יפנה במקום זאת לאפליקציית דפדפן ברירת המחדל של המשתמש.

כדי לקבל את האישור הזה, האפליקציות צריכות לבצע אחת מהפעולות הבאות:

אם האפליקציה מפעילה כוונות אינטרנט, כדאי להוסיף הנחיה או תיבת דו-שיח שמבקשת מהמשתמש לאשר את הפעולה.

שיפורים במצב אימרסיבי לניווט באמצעות תנועות

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

  1. פעילה: האפליקציה נמצאת בשימוש כרגע או שהייתה בשימוש לאחרונה.
  2. קבוצת עבודה: האפליקציה נמצאת בשימוש קבוע.
  3. תדירות גבוהה: האפליקציה נמצאת בשימוש לעיתים קרובות, אבל לא כל יום.
  4. לעיתים רחוקות: האפליקציה לא בשימוש לעיתים קרובות.
  5. מוגבלת: האפליקציה צורכת הרבה משאבי מערכת או שהיא עלולה להתנהג בצורה לא רצויה.

כדי להחליט אם להעביר את האפליקציה לקטגוריה המוגבלת, המערכת בודקת את ההתנהגות של האפליקציה בנוסף לדפוסי השימוש.

אם האפליקציה תשתמש במשאבי המערכת בצורה אחראית יותר, סביר להניח שהיא לא תועבר לקטגוריית המוגבלות. בנוסף, המערכת מעבירה את האפליקציה לקטגוריה פחות מגבילה אם המשתמש יוצר אינטראקציה ישירה עם האפליקציה.

איך בודקים אם האפליקציה נמצאת בקטגוריה המוגבלת

כדי לבדוק אם המערכת העבירה את האפליקציה לקטגוריה המוגבלת, מפעילים את הפונקציה getAppStandbyBucket(). אם ערך ההחזרה של השיטה הזו הוא STANDBY_BUCKET_RESTRICTED, האפליקציה נמצאת בקטגוריה המוגבלת.

בדיקת ההתנהגות של הקטגוריה המוגבלת

כדי לבדוק איך האפליקציה מתנהגת כשהמערכת מעבירה אותה לקטגוריה המוגבלת, אתם יכולים להעביר אותה לשם באופן ידני. כדי לעשות את זה, מריצים את הפקודה הבאה בחלון הטרמינל:

adb shell am set-standby-bucket PACKAGE_NAME restricted

מיקום בחזית וחיסכון בסוללה

החל מ-Android 12, אפשר להמשיך לשלוח את המיקום בחזית (כולל משירות שפועל בחזית) כשהתכונה "חיסכון בסוללה" פועלת, גם כשהמסך כבוי.

בעבר, מצב החיסכון בסוללה הפסיק את עדכוני המיקום כשהמסך היה כבוי. השינוי הזה מאפשר למשתמשים ליהנות מחיי סוללה ארוכים יותר, ומאפשר למפתחים להימנע מלבקש מהמשתמשים להשבית את החיסכון בסוללה כדי להבטיח את קבלת המיקום.

באפליקציות שמבקשות מיקום דרך שירות שפועל בחזית, צריך לבצע את הפעולות הבאות:

  1. התקשרו אל getLocationPowerSaverMode() כדי לבדוק איך תכונות המיקום של המכשיר פועלות כשמצב החיסכון בסוללה מופעל.
  2. אם הפונקציה מחזירה את הערך LOCATION_MODE_FOREGROUND_ONLY, האפליקציה תמשיך לקבל עדכוני מיקום כשהיא פועלת בחזית או מפעילה שירות בחזית, גם אם מצב החיסכון בסוללה מופעל והמסך כבוי.

אבטחה ופרטיות

מיקום משוער

בתיבת הדו-שיח יש שתי קבוצות של אפשרויות, אחת מעל השנייה
תרשים 1. תיבת דו-שיח של הרשאות מערכת שמאפשרת למשתמשים לתת הרשאה לנתוני מיקום משוער.

במכשירים עם Android בגרסה 12 ומעלה, המשתמשים יכולים לבקש שלאפליקציה תהיה גישה רק למיקום משוער.

אם האפליקציה מבקשת את ההרשאה בתחילת ההפעלה ACCESS_FINE_LOCATION, צריך לבקש גם את ההרשאה ACCESS_COARSE_LOCATION כדי לטפל במקרה שבו המשתמש מעניק לאפליקציה גישה למיקום משוער. צריך לכלול את שתי ההרשאות בבקשה אחת בתחילת ההפעלה.

תיבת הדו-שיח של הרשאות המערכת כוללת את האפשרויות הבאות למשתמש, כפי שמוצג באיור 1:

  • מדויק: האפליקציה מקבלת גישה לנתוני מיקום מדויקים.
  • משוער: גישה רק לנתוני מיקום משוערים.

מתגי הגישה למיקרופון ולמצלמה

במכשירים נתמכים עם Android מגרסה 12 ואילך, המשתמשים יכולים להפעיל ולהשבית את הגישה למצלמה ולמיקרופון בכל האפליקציות במכשיר באמצעות מתג אחד. המשתמשים יכולים לגשת לאפשרויות ההפעלה וההשבתה דרך ההגדרות המהירות, כמו שמוצג באיור 1, או דרך מסך הפרטיות בהגדרות המערכת.

כאן מוסבר על המתגים האלה, וכאן מוסבר איך לוודא שהאפליקציה פועלת לפי השיטות המומלצות בנוגע להרשאות CAMERA ו- RECORD_AUDIO.

אינדיקטורים למיקרופון ולמצלמה

במכשירים עם Android מגרסה 12 ואילך, כשלאפליקציה יש גישה למיקרופון או למצלמה, מופיע סמל בשורת הסטטוס.

בקישורים הבאים אפשר לקרוא מידע נוסף על האינדיקטורים האלה ואיך לוודא שהאפליקציה פועלת לפי השיטות המומלצות בנוגע להרשאות CAMERA ו-RECORD_AUDIO.

הכפתורים בהגדרות המהירות נקראים &quot;גישה למצלמה&quot; ו&quot;גישה למיקרופון&quot;
איור 2. מתגי גישה למיקרופון ולמצלמה בהגדרות המהירות.
מלבן מעוגל בפינה השמאלית העליונה, שכולל סמל של מצלמה וסמל של מיקרופון
איור 3. אינדיקטורים למיקרופון ולמצלמה, שמראים גישה לנתונים מהזמן האחרון.

הרשאת גישה לחבילה

במכשירים עם 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() כדי לגשת לנתוני לוח מאפליקציה אחרת בפעם הראשונה, מוצגת למשתמש הודעה קצרה על הגישה הזו ללוח.

הטקסט בתוך ההודעה הקצרה מכיל את הפורמט הבא: APP pasted from your clipboard.

מידע על טקסט בתיאור הקליפ

ב-Android 12 ואילך, getPrimaryClipDescription() יכול לזהות את הפרטים הבאים:

אפליקציות לא יכולות לסגור תיבות דו-שיח של המערכת

כדי לשפר את השליטה של המשתמשים באינטראקציה עם אפליקציות ועם המערכת, פעולת ה-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

מחזור חיים של פעילות

פעילויות של מרכז האפליקציות ברמה הבסיסית (root) לא מסתיימות יותר בלחיצה על "הקודם"

ב-Android 12, השתנה הטיפול שמוגדר כברירת מחדל בלחיצה על מקש החזרה של המערכת בפעילויות של מרכז האפליקציות שנמצאות ברמה הבסיסית (root) של המשימות שלהן. בגרסאות קודמות, המערכת הייתה מסיימת את הפעילויות האלה בלחיצה על "הקודם". ב-Android 12, המערכת מעבירה את הפעילות והמשימה שלה לרקע במקום לסיים את הפעילות. ההתנהגות החדשה תואמת להתנהגות הנוכחית כשיוצאים מאפליקציה באמצעות כפתור הבית או תנועה.

ברוב האפליקציות, המשמעות של השינוי הזה היא שמשתמשים שמשתמשים בלחצן "הקודם" כדי לצאת מהאפליקציה יכולים להמשיך להשתמש בה מהר יותר ממצב חם, במקום להפעיל מחדש את האפליקציה ממצב קר.

מומלץ לבדוק את האפליקציות שלכם עם השינוי הזה. אם האפליקציה שלכם מבטלת כרגע את onBackPressed() כדי לטפל בניווט לאחור ולסיים את Activity, צריך לעדכן את ההטמעה כך שתתבצע קריאה ל-super.onBackPressed() במקום לסיים. קריאה ל-super.onBackPressed() מעבירה את הפעילות והמשימה שלה לרקע כשצריך, ומספקת למשתמשים חוויית ניווט עקבית יותר באפליקציות.

חשוב גם לציין שבאופן כללי, מומלץ להשתמש בממשקי ה-API של AndroidX Activity כדי לספק ניווט לאחור מותאם אישית, במקום לשנות את 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(): התנאים וההגבלות הם תכונה של 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 כוללת רשימות מעודכנות של ממשקים מוגבלים שאינם SDK, שמבוססות על שיתוף פעולה עם מפתחי Android ועל הבדיקות הפנימיות האחרונות. בכל פעם שאפשר, אנחנו מוודאים שקיימות חלופות ציבוריות לפני שאנחנו מגבילים ממשקים שאינם SDK.

אם האפליקציה לא מטרגטת את Android 12, יכול להיות שחלק מהשינויים האלה לא ישפיעו עליכם באופן מיידי. עם זאת, למרות שכרגע אפשר להשתמש בחלק מהממשקים שאינם SDK (בהתאם לרמת ה-API המיועדת של האפליקציה), שימוש בכל שיטה או שדה שאינם SDK תמיד כרוך בסיכון גבוה לפגיעה באפליקציה.

אם אתם לא בטוחים אם האפליקציה שלכם משתמשת בממשקים שאינם SDK, אתם יכולים לבדוק את האפליקציה כדי לגלות. אם האפליקציה שלכם מסתמכת על ממשקים שאינם SDK, כדאי להתחיל לתכנן מעבר לחלופות SDK. עם זאת, אנחנו מבינים שיש אפליקציות שבהן יש תרחישי שימוש לגיטימיים לשימוש בממשקים שאינם SDK. אם אתם לא מוצאים חלופה לשימוש בממשק שאינו SDK לתכונה באפליקציה, אתם צריכים לבקש API ציבורי חדש.

למידע נוסף על השינויים בגרסה הזו של Android, קראו את המאמר עדכונים להגבלות על ממשקים שאינם SDK ב-Android 12. מידע נוסף על ממשקים שאינם SDK זמין במאמר הגבלות על ממשקים שאינם SDK.