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

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

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

פונקציונליות עיקרית

‫Android 17 (‏API ברמה 37) כוללת את השינויים הבאים, שמשנים או מרחיבים יכולות ליבה שונות של מערכת Android.

מגבלות זיכרון באפליקציות

ב-Android 17 מוצגות מגבלות על הזיכרון של האפליקציות, שמבוססות על זיכרון ה-RAM הכולל של המכשיר. המגבלות האלה נועדו ליצור סביבה יציבה יותר וניתנת יותר לחיזוי עבור האפליקציות שלכם ומשתמשי Android. המגבלות האלה מתמקדות בדליפות זיכרון ובערכים חריגים אחרים לפני שהם גורמים לחוסר יציבות במערכת, שמוביל לגמגום בממשק המשתמש, לניצול מוגבר של הסוללה ולסגירה של אפליקציות. אנחנו צופים שההשפעה על רוב הפעלות האפליקציות תהיה מינימלית, אבל מומלץ לפעול לפי השיטות המומלצות הבאות לניהול הזיכרון, כולל הגדרת בסיס לזיכרון.

כדי לבדוק אם הפעילות באפליקציה הושפעה, אפשר להתקשר אל getDescription ב-ApplicationExitInfo. אם האפליקציה הושפעה, סיבת היציאה תהיה REASON_OTHER והתיאור יכיל את המחרוזת "MemoryLimiter:AnonSwap" יחד עם מידע נוסף. אפשר גם להשתמש בפרופילים מבוססי-טריגר עם TRIGGER_TYPE_ANOMALY כדי לקבל קובצי dump של ה-heap שנאספים כשמגיעים למגבלת הזיכרון.

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

בדיקת התנהגות האפליקציה במסגרת מגבלות הזיכרון

אתם יכולים להשתמש בממשק הגישור של Android‏ (adb) כדי לשנות או להשבית את מגבלות הזיכרון בכל מכשיר שמוגדרות בו מגבלות כאלה. פקודת ה-shell‏ am מספקת שלוש פקודות משנה להתאמת מגבלות הזיכרון. (לפקודות האלה אין השפעה על מכשיר שלא מוטלות עליו מגבלות זיכרון).

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

ההגדרה הזו מורה למגביל הזיכרון להתעלם מחלק מהתהליכים או מכולם. העברת מזהה משתמש (UID) ב-Android גורמת למגביל הזיכרון להתעלם מהאכיפה בכל התהליכים שמשויכים למזהה המשתמש הזה. אפשר גם להעביר את הערך all (התעלמות מכל האפליקציות) או none (לא להתעלם מאף אפליקציה). העברת none מבטלת את כל הקריאות הקודמות אל am memory-limiter ignore.

אם תגדירו למגביל הזיכרון להתעלם ממזהה UID, עדיין תוכלו להגדיר מגבלת זיכרון ידנית לתהליך באפליקציה באמצעות קריאה ל-am memory-limiter manual.

manual

ההוראה גורמת למערכת להגביל את הזיכרון של התהליך עם ה-PID (מזהה התהליך) שצוין. מגבלת הזיכרון מצוינת כמספר שלם של MB. לדוגמה, אם מעבירים את הערך 30, התהליך מוגבל ל-30MB של זיכרון. העברת max מסירה את כל מגבלות הזיכרון בתהליך הזה. העברת הערך none מסירה את כל המגבלות שהוגדרו ידנית לתהליך, ומחזירה את מגבלת ברירת המחדל של המערכת (אם יש כזו).

status

בעמודה הזו מדווח הסטטוס הנוכחי של מגביל הזיכרון. הסטטוס כולל את מגבלות הזיכרון שמוטלות על תהליכים גלויים ולא גלויים.

פרטיות

‫Android 17 כוללת את השינויים הבאים לשיפור פרטיות המשתמשים.

הגנה על OTP ב-SMS

החל מ-Android 17, מערכת Android מרחיבה את ההגנה שלה על הודעות SMS שמכילות סיסמאות חד-פעמיות (OTP).

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

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

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

אפליקציות מסוימות, כמו אפליקציית העוזר הווירטואלי ל-SMS שמוגדרת כברירת מחדל, אפליקציות נלוות למכשירים מקושרים וכו', פטורות מההשהיה הזו. כל האפליקציות שמסתמכות על קריאת הודעות SMS כדי לחלץ מהן קודים חד-פעמיים צריכות לעבור לשימוש בממשקי ה-API של SMS Retriever או SMS User Consent כדי להבטיח המשך פעולה.

אבטחה

‫Android 17 כולל את השיפורים הבאים באבטחת המכשיר והאפליקציות.

תוכנית להוצאה משימוש של usesClearTraffic

בגרסה עתידית, אנחנו מתכננים להוציא משימוש את הרכיב usesCleartextTraffic. אפליקציות שצריכות ליצור חיבורים לא מוצפנים (HTTP) צריכות לעבור לשימוש בקובץ תצורה של אבטחת רשת, שמאפשר לכם לציין לאילו דומיינים האפליקציה צריכה ליצור חיבורים לא מוצפנים.

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

  • הגדרת המאפיין usesCleartextTraffic לערך true
  • שימוש בקובץ תצורת רשת

אם רמת ה-API המינימלית של האפליקציה היא 24 ומעלה, אפשר להשתמש בקובץ תצורה של רשת ולא צריך להגדיר את usesCleartextTraffic.

הגבלת הרשאות URI משתמעות

נכון לעכשיו, אם אפליקציה מפעילה intent עם URI שיש לו את הפעולה ACTION_SEND,‏ ACTION_SEND_MULTIPLE או ACTION_IMAGE_CAPTURE, המערכת מעניקה אוטומטית לאפליקציית היעד את הרשאות ה-URI לקריאה ולכתיבה. החל מ-Android 18, המערכת לא תעניק יותר את ההרשאות האלה באופן אוטומטי. לכן מומלץ שאפליקציות יעניקו במפורש את הרשאות ה-URI הרלוונטיות במקום להסתמך על המערכת שתעניק אותן.

כדי לזהות את השימוש בכוונות האלה באפליקציה, צריך להשתמש ב-StrictMode עם detectImplicitUriPermissionGrant() כדי להפעיל הפרה:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

אפשר גם לעקוב אחרי חריגים שנרשמו ביומן שכוללים את ההודעה Please set the grant explicitly in the app שמופיעה כשהמערכת מגדירה את ההרשאה באופן מרומז. אפשר לעקוב אחרי היומנים האלה באמצעות הפקודה הבאה של adb:

adb logcat | grep "Please set the grant explicitly in the app"

כדי להעניק במפורש את ההרשאות הנדרשות, מוסיפים את הדגל FLAG_GRANT_READ_URI_PERMISSION לכוונות ACTION_SEND ו-ACTION_SEND_MULTIPLE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

כוללים את הדגלים FLAG_GRANT_READ_URI_PERMISSION ו-FLAG_GRANT_WRITE_URI_PERMISSION עבור כוונות ACTION_IMAGE_CAPTURE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

מגבלות על חנות מפתחות לכל אפליקציה

אפליקציות צריכות להימנע מיצירה של מספר מופרז של מפתחות ב-Android Keystore, כי זהו משאב משותף לכל האפליקציות במכשיר. החל מ-Android 17, המערכת אוכפת מגבלה על מספר המפתחות שאפליקציה יכולה להיות הבעלים שלהם. המגבלה היא 50,000 מפתחות לאפליקציות שאינן אפליקציות מערכת שמטרגטות את Android 17 (רמת API 37) ואילך, ו-200,000 מפתחות לכל שאר האפליקציות. לאפליקציות מערכת יש מגבלה של 200,000 מפתחות, ללא קשר לרמת ה-API שהן מיועדות לה.

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

  • אפליקציות שמטרגטות ל-Android 17 (רמת API 37) ומעלה: הפונקציה getNumericErrorCode() מחזירה את הערך החדש ERROR_TOO_MANY_KEYS.
  • כל האפליקציות האחרות: getNumericErrorCode() מחזירה ERROR_INCORRECT_USAGE.

חסימה של תנועת גולשים בלולאה חוזרת (loopback) בין פרופילים

从 Android 17 开始，默认情况下不再允许跨个人资料环回流量。同一个人资料内的环回流量不受影响。 此项变更适用于在 Android 17 或更高版本上运行的所有应用，无论应用以哪个 API 级别为目标平台。

חוויית המשתמש וממשק המשתמש של המערכת

‫Android 17 כוללת את השינויים הבאים, שנועדו ליצור חוויית משתמש עקבית ואינטואיטיבית יותר.

שחזור ברירת המחדל של חשיפת ה-IME אחרי סיבוב

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

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

  • מגדירים את המאפיין android:windowSoftInputMode לערך stateAlwaysVisible.
  • מבקשים באופן פרוגרמטי את המקלדת הווירטואלית ב-method onCreate() של הפעילות, או מוסיפים את ה-method onConfigurationChanged().

קלט אנושי

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

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

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

בעבר, המערכת לא ניסתה לזהות תנועות מלוח המגע, אלא העבירה לאפליקציה את המיקומים המוחלטים של האצבעות בפורמט דומה לזה של מגעים במסך מגע. אם אפליקציה עדיין דורשת את הנתונים האלה, היא צריכה להפעיל את ה-method החדש View.requestPointerCapture(int) עם View.POINTER_CAPTURE_MODE_ABSOLUTE במקום זאת.

מדיה

‫Android 17 כוללת את השינויים הבאים בהתנהגות של מדיה.

הגברת האבטחה של אודיו ברקע

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

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

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

קישוריות

‫Android 17 כוללת את השינויים הבאים לשיפור הקישוריות של המכשיר.

התאמה אוטונומית מחדש במקרה של אובדן קישוריות Bluetooth

Android 17 introduces autonomous re-pairing, a system-level enhancement designed to automatically resolve Bluetooth bond loss.

Previously, if a bond was lost, users had to manually navigate to Settings to unpair and then re-pair the peripheral. This feature builds upon the security improvement of Android 16 by allowing the system to re-establish bonds in the background without requiring users to manually navigate to Settings to unpair and re-pair peripherals.

While most apps will not require code changes, developers should be aware of the following behavior changes in Bluetooth stack:

  • New pairing context: The ACTION_PAIRING_REQUEST now includes the EXTRA_PAIRING_CONTEXT extra which allows apps to distinguish between a standard pairing request and an autonomous system-initiated re-pairing attempt.
  • Conditional key updates: Existing security keys will only be replaced if the re-pairing is successful and new connection meets or exceeds the security level of the previous bond.
  • Modified intent timing: The ACTION_KEY_MISSING intent is now broadcast only if the autonomous re-pairing attempt fails. This reduces unnecessary error handling in the app if the system successfully recovers the bond in the background.
  • User notification: The system manages re-pairing via new UI notifications and dialogs. Users will be prompted to confirm the re-pairing attempt to ensure they are aware of the reconnection.

Peripheral device manufacturers and companion app developers should verify that hardware and app gracefully handle bond transitions. To test this behavior, simulate a remote bond loss using either of the following methods:

  • Manually remove the bond information from the peripheral device
  • Manually unpair the device in: Settings > Connected devices