פלטפורמת Android 17 כוללת שינויים בהתנהגות שעשויים להשפיע על האפליקציה שלכם. שינויי ההתנהגות הבאים רלוונטיים לכל האפליקציות כשהן פועלות ב-Android 17, בלי קשר ל-targetSdkVersion. מומלץ לבדוק את האפליקציה ולשנות אותה לפי הצורך כדי לתמוך בשינויים האלה, במקרים הרלוונטיים.
חשוב גם לעיין ברשימת השינויים בהתנהגות שמשפיעים רק על אפליקציות שמטרגטות ל-Android 17.
פונקציונליות עיקרית
Android 17 (API ברמה 37) כוללת את השינויים הבאים, שמשנים או מרחיבים יכולות ליבה שונות של מערכת Android.
מגבלות זיכרון של אפליקציות
Android 17 introduces app memory limits based on the device's total RAM to create a more stable and deterministic environment for your applications and Android users. In Android 17, limits are set conservatively to establish system baselines, targeting extreme memory leaks and other outliers before they trigger system-wide instability resulting in UI stuttering, higher battery drain, and apps being killed. While we anticipate minimal impact on the vast majority of app sessions, we recommend the following memory best practices, including establishing a baseline for memory.
You can determine if your app session was impacted by calling
getDescription in ApplicationExitInfo; if your app was
affected, the exit reason will be REASON_OTHER and
the description will contain the string "MemoryLimiter:AnonSwap" along with
other information. You can also use trigger-based profiling with
TRIGGER_TYPE_ANOMALY to get heap dumps that are collected when the
memory limit is hit.
To help you find memory leaks, Android Studio Panda adds LeakCanary integration directly in the Android Studio Profiler as a dedicated task, contextualized within the IDE and fully integrated with your source code.
אבטחה
Android 17 כולל את השיפורים הבאים באבטחת המכשיר והאפליקציות.
תוכנית הוצאה משימוש של usesClearTraffic
בגרסה עתידית, אנחנו מתכננים להוציא משימוש את הרכיב usesCleartextTraffic.
אפליקציות שצריכות ליצור חיבורים לא מוצפנים (HTTP) צריכות לעבור לשימוש בקובץ תצורה של אבטחת רשת, שמאפשר לכם לציין לאילו דומיינים האפליקציה צריכה ליצור חיבורים לא מוצפנים.
חשוב לדעת שקבצי הגדרות של אבטחת רשת נתמכים רק ברמות API 24 ומעלה. אם רמת ה-API המינימלית של האפליקציה נמוכה מ-24, צריך לבצע את שתי הפעולות הבאות:
- הגדרת המאפיין
usesCleartextTrafficלערךtrue - שימוש בקובץ תצורת רשת
אם רמת ה-API המינימלית של האפליקציה היא 24 ומעלה, אפשר להשתמש בקובץ תצורה של רשת ולא צריך להגדיר את usesCleartextTraffic.
הגבלת הרשאות URI משתמעות
Currently, if an app launches an intent with a URI that has the action Send,
SendMultiple, or ImageCapture, the system automatically grants the read and
write URI permissions to the target app. We plan to change this behavior in
Android 18. For this reason, we recommend that apps explicitly
grant the relevant URI permissions instead of relying on the system to grant
them.
מגבלות על מאגר מפתחות לכל אפליקציה
Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.
If an app attempts to create keys beyond the limit, the creation fails with a
KeyStoreException. The exception's message string contains information
about the key limit. If the app calls getNumericErrorCode() on the
exception, the return value depends on what API level the app targets:
- Apps targeting Android 17 (API level 37) or higher:
getNumericErrorCode()returns the newERROR_TOO_MANY_KEYSvalue. - All other apps:
getNumericErrorCode()returnsERROR_INCORRECT_USAGE.
חוויית המשתמש וממשק המשתמש של המערכת
Android 17 כוללת את השינויים הבאים, שנועדו ליצור חוויית משתמש עקבית ואינטואיטיבית יותר.
שחזור ברירת המחדל של חשיפת ה-IME אחרי סיבוב
החל מ-Android 17, כשמתרחשים שינויים בהגדרות המכשיר (לדוגמה, סיבוב), והאפליקציה לא מטפלת בשינויים האלה בעצמה, מצב החשיפה הקודם של ה-IME לא משוחזר.
אם האפליקציה עוברת שינוי בהגדרות שהיא לא מטפלת בו, והיא צריכה שהמקלדת תהיה גלויה אחרי השינוי, צריך לבקש זאת באופן מפורש. אפשר לשלוח את הבקשה באחת מהדרכים הבאות:
- מגדירים את המאפיין
android:windowSoftInputModeלערךstateAlwaysVisible. - מבקשים באופן פרוגרמטי את המקלדת הווירטואלית ב-method
onCreate()של הפעילות, או מוסיפים את ה-methodonConfigurationChanged().
קלט אנושי
Android 17 כוללת את השינויים הבאים שמשפיעים על האינטראקציה של אפליקציות עם מכשירי קלט אנושיים כמו מקלדות ומשטחי מגע.
משטחי מגע מספקים אירועים יחסיים כברירת מחדל במהלך לכידת מצביע
Beginning with Android 17, if an app requests pointer capture using
View.requestPointerCapture() and the user uses a touchpad, the system
recognizes pointer movement and scrolling gestures from the user's touches and
reports them to the app in the same way as pointer and scroll wheel movements
from a captured mouse. In most cases, this removes the need for apps that
support captured mice to add special handling logic for touchpads. For more
details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.
Previously, the system did not attempt to recognize gestures from the touchpad,
and instead delivered the raw, absolute finger locations to the app in a similar
format to touchscreen touches. If an app still requires this absolute data, it
should call the new View.requestPointerCapture(int) method with
View.POINTER_CAPTURE_MODE_ABSOLUTE instead.
מדיה
Android 17 כוללת את השינויים הבאים בהתנהגות של מדיה.
חיזוק האבטחה של אודיו ברקע
החל מ-Android 17, מסגרת האודיו אוכפת הגבלות על אינטראקציות עם אודיו ברקע, כולל הפעלת אודיו, בקשות להרשאת אודיו וממשקי API לשינוי עוצמת הקול, כדי לוודא שהמשתמש יתחיל את השינויים האלה באופן מכוון.
אם האפליקציה מנסה לקרוא לממשקי API של אודיו בזמן שהאפליקציה לא נמצאת במחזור חיים תקין, ממשקי ה-API של הפעלת האודיו ושינוי עוצמת הקול נכשלים בשקט בלי להקפיץ חריגה או לספק הודעת שגיאה. ה-API של הרשאת האודיו נכשל עם קוד התוצאה AUDIOFOCUS_REQUEST_FAILED.
מידע נוסף, כולל אסטרטגיות להפחתת הסיכון, זמין במאמר בנושא הקשחה של אודיו ברקע.
קישוריות
Android 17 כוללת את השינויים הבאים לשיפור הקישוריות של המכשיר.
התאמה אוטומטית מחדש במקרה של אובדן קישוריות Bluetooth
ב-Android 17 מוצגת התאמה חוזרת אוטונומית, שיפור ברמת המערכת שנועד לפתור באופן אוטומטי בעיות של אובדן קישוריות Bluetooth.
בעבר, אם נוצר ניתוק בין המכשירים, המשתמשים היו צריכים לעבור להגדרות באופן ידני כדי לבטל את ההתאמה ואז להתאים מחדש את הציוד ההיקפי. התכונה הזו מבוססת על שיפור האבטחה ב-Android 16, ומאפשרת למערכת ליצור מחדש קישוריות ברקע בלי שהמשתמשים יצטרכו לנווט ידנית אל ההגדרות כדי לבטל את ההתאמה של ציוד היקפי ולהתאים אותו מחדש.
למרות שברוב האפליקציות לא יהיה צורך בשינויים בקוד, המפתחים צריכים להיות מודעים לשינויים הבאים בהתנהגות של מחסנית Bluetooth:
- הקשר חדש של צימוד:
ACTION_PAIRING_REQUESTכולל עכשיו את התוסףEXTRA_PAIRING_CONTEXT, שמאפשר לאפליקציות להבחין בין בקשת צימוד רגילה לבין ניסיון חוזר לצימוד שהופעל על ידי מערכת אוטונומית. - עדכוני מפתחות מותנים: מפתחות אבטחה קיימים יוחלפו רק אם ההתאמה מחדש תצליח והחיבור החדש יעמוד בדרישות האבטחה של החיבור הקודם או יעלה עליהן.
- שינוי בתזמון של כוונת המשתמש: כוונת המשתמש
ACTION_KEY_MISSINGמשודרת עכשיו רק אם הניסיון לצימוד אוטונומי נכשל. כך מצמצמים את הצורך בטיפול בשגיאות לא נחוצות באפליקציה, אם המערכת משחזרת את הקישור ברקע. - התראה למשתמש: המערכת מנהלת את ההתאמה מחדש באמצעות התראות ודיאלוגים חדשים בממשק המשתמש. המשתמשים יתבקשו לאשר את הניסיון לשיוך מחדש כדי לוודא שהם מודעים לחיבור מחדש.
יצרני מכשירים היקפיים ומפתחי אפליקציות נלוות צריכים לוודא שהחומרה והאפליקציה מטפלות בצורה חלקה במעברים בין מצבי ההתאמה. כדי לבדוק את ההתנהגות הזו, אפשר לדמות ניתוק של חיבור מרוחק באחת מהשיטות הבאות:
- הסרה ידנית של פרטי ההתאמה מהציוד ההיקפי
- מבטלים את ההתאמה של המכשיר באופן ידני דרך 'הגדרות' > 'מכשירים מחוברים'.