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

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

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

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

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

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

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

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

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

אפליקציות מסוימות, כמו אפליקציית העזרה שמוגדרת כברירת מחדל ל-SMS, אפליקציות נלוות למכשירים מחוברים וכו', פטורות מהעיכוב הזה. כדי להבטיח שהאפליקציה תמשיך לפעול, כל האפליקציות שמסתמכות על קריאת הודעות SMS לצורך חילוץ OTP צריכות לעבור לשימוש בממשקי ה-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 הרלוונטיות, במקום להסתמך על המערכת שתעניק אותן.

כדי לזהות את השימוש ב-Intent האלה באפליקציה, משתמשים ב-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 ל-Intent‏ ACTION_SEND ול-Intent‏ 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 ל-Intent מסוג 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, כברירת מחדל, לא ניתן יותר להעביר תנועה בלולאה חוזרת בין פרופילים. תנועת Loopback באותו פרופיל לא מושפעת. השינוי הזה חל על כל האפליקציות שפועלות ב-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 יש תכונה חדשה של התאמה מחדש אוטונומית, שיפור ברמת המערכת שנועד לפתור באופן אוטומטי בעיות של אובדן חיבור Bluetooth.

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

ברוב האפליקציות לא צריך לשנות את הקוד, אבל המפתחים צריכים להיות מודעים לשינויים הבאים בהתנהגות של מחסנית ה-Bluetooth:

  • הקשר חדש להתאמה: ACTION_PAIRING_REQUEST כולל עכשיו את התוספת EXTRA_PAIRING_CONTEXT, שמאפשרת לאפליקציות להבחין בין בקשת התאמה רגילה לבין ניסיון התאמה מחדש שמתבצע באופן אוטונומי על ידי המערכת.
  • עדכונים מותנים של מפתחות: מפתחות אבטחה קיימים יוחלפו רק אם ההתאמה מחדש תצליח והחיבור החדש יעמוד ברמת האבטחה של החיבור הקודם או יעלה עליה.
  • שינוי בתזמון של Intent: ה-Intent‏ ACTION_KEY_MISSING משודר עכשיו רק אם הניסיון להתאמה אוטומטית מחדש נכשל. כך, אם המערכת משחזרת את הקישור ברקע, לא צריך לטפל בשגיאות מיותרות באפליקציה.
  • התראות למשתמשים: המערכת מנהלת את ההתאמה מחדש באמצעות התראות ותיבות דו-שיח חדשות בממשק המשתמש. המשתמשים יתבקשו לאשר את ניסיון ההתאמה מחדש כדי לוודא שהם מודעים לחיבור מחדש.

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

  • הסרה ידנית של פרטי הקישור מהציוד ההיקפי
  • מבטלים את ההתאמה של המכשיר באופן ידני: הגדרות > מכשירים מחוברים