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

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

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

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

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

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

Android 17 引入了基于设备总 RAM 的应用内存限制，旨在为您的应用和 Android 用户打造更稳定、更具确定性的环境。这些限制侧重于在内存泄漏和其他异常值触发系统范围的不稳定性（导致界面卡顿、电池耗电量增加和应用被终止）之前，对其进行限制。虽然我们预计对绝大多数应用会话的影响很小，但我们建议您遵循以下内存最佳实践，包括建立内存基准。

您可以在 ApplicationExitInfo 中调用 getDescription，以确定您的应用会话是否受到影响；如果您的应用受到 影响，退出原因将为 REASON_OTHER，并且 说明将包含字符串 "MemoryLimiter:AnonSwap" 以及 其他信息。您还可以使用基于触发器的分析（使用 TRIGGER_TYPE_ANOMALY）来获取在达到 内存限制时收集的堆转储。

“管理应用内存”文档提供了相关信息 可帮助您诊断应用的内存问题并优化其资源 消耗。

在内存限制下测试应用的行为

您可以使用 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 用户 ID） 会指示内存限制器 忽略对与该 UID 相关联的所有进程的强制执行。 您还可以传递 all（忽略所有应用）或 none（不忽略任何应用）。 传递 none 会替换之前对 am memory-limiter ignore 的任何调用。

如果您指示内存限制器忽略某个 UID，您仍然可以通过调用 am memory-limiter manual 对应用中的进程应用手动内存限制。

manual

指示系统对具有指定 PID（进程 ID）的进程施加内存限制。内存限制以整数形式的 MB 数指定；例如，传递 30 指定进程的内存限制为 30 MB。传递 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，且该 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 的文档。

之前，系统不会尝试识别触控板的手势，而是以类似于触摸屏触摸的格式将原始的绝对手指位置传递给应用。如果应用仍需要此绝对数据，则应改为使用 View.POINTER_CAPTURE_MODE_ABSOLUTE 调用新的 View.requestPointerCapture(int) 方法。

מדיה

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

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

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