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

פלטפורמת 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 将扩大对包含一次性密码 (OTP) 的短信的保护范围。

在之前的 Android 版本中，此保护主要侧重于 SMS Retriever 格式。对于大多数应用，包含 SMS Retriever 哈希的消息的递送延迟了 3 小时。不过，某些应用（例如默认短信处理程序）不受此延迟的影响，拥有哈希的应用也不受此延迟的影响。

从 Android 17 开始，此保护也适用于 WebOTP 格式的消息。如果应用有权读取短信，但不是 WebOTP 消息的预期接收者（由网域验证确定），则该应用在收到消息后 3 小时内无法访问该消息。此变更旨在提高用户安全性，确保只有与消息中提及的网域关联的应用才能以编程方式读取验证码。

在这 3 小时的延迟期间，系统会保留 SMS_RECEIVED_ACTION 广播，并过滤 短信提供商 数据库查询。延迟结束后，这些应用即可使用短信。此变更适用于 所有应用，无论其目标 API 级别如何。

某些应用（例如默认短信助理应用、关联设备配套应用等）不受此延迟的影响。所有依赖于读取短信 来提取 OTP 的应用都应过渡到使用 SMS Retriever 或 SMS User Consent API，以确保功能持续可用。

אבטחה

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

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

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

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

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

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

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

目前，如果应用启动的 intent 具有 URI，且该 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标志添加到ACTION_SEND和 ACTION_SEND_MULTIPLEintent：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

对于 ACTION_IMAGE_CAPTURE intent，请同时添加FLAG_GRANT_READ_URI_PERMISSION 和 FLAG_GRANT_WRITE_URI_PERMISSION 标志：

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

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

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