שינויים בהתנהגות: אפליקציות שמטרגטות ל-Android מגרסה 16 ואילך

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

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

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

‫Android 16 (‏API ברמה 36) כוללת את השינויים הבאים, שנועדו ליצור חוויית משתמש עקבית ואינטואיטיבית יותר.

האפשרות להסיר את התצוגה מקצה לקצה תבוטל

Android 15 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

כדי להשתמש בתכונה "חיזוי החזרה", צריך לבצע העברה או לבטל את ההסכמה

באפליקציות שמטרגטות ל-Android 16 (רמת API‏ 36) ואילך ופועלות במכשיר עם Android 16 ואילך, מופעלות כברירת מחדל האנימציות של מערכת הניווט החזוי אחורה (חזרה למסך הבית, מעבר בין משימות ומעבר בין פעילויות). בנוסף, לא מתבצעת קריאה ל-onBackPressed ולא מתבצעת יותר שליחה של KeyEvent.KEYCODE_BACK.

אם האפליקציה שלכם מיירטת את אירוע החזרה ואתם עדיין לא עברתם לניווט חזוי אחורה, תצטרכו לעדכן את האפליקציה כדי להשתמש בממשקי API נתמכים של ניווט אחורה, או להשבית את התכונה באופן זמני על ידי הגדרת המאפיין android:enableOnBackInvokedCallback לערך false בתג <application> או <activity> של קובץ AndroidManifest.xml של האפליקציה.

הוצאה משימוש והשבתה של ממשקי API אלגנטיים לגופנים

באפליקציות שמטרגטות ל-Android 15 (רמת API‏ 35), מאפיין elegantTextHeight‏ TextView מוגדר כ-true כברירת מחדל, והגופן הקומפקטי מוחלף בגופן קריא הרבה יותר. אפשר לשנות את ההגדרה הזו על ידי הגדרת המאפיין elegantTextHeight לערך false.

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

ההתנהגות של

התנהגות

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

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

אופטימיזציה של תזמון פעולה בקצב קבוע

在以 Android 16 为目标平台之前，如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行，则当应用返回到有效的生命周期时，所有错过的执行会立即执行。

以 Android 16 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 兼容性标志进行测试。

גורמי צורה של מכשירים

‫Android 16 (‏API ברמה 36) כוללת את השינויים הבאים באפליקציות כשהן מוצגות במכשירים עם מסך גדול.

פריסות מותאמות

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

התעלמות מהגבלות על כיוון, שינוי גודל ויחס גובה-רוחב

באפליקציות שמטרגטות ל-Android 16 (רמת API 36), מערכת Android 16 כוללת שינויים באופן שבו המערכת מנהלת הגבלות על כיוון, שינוי גודל ויחס גובה-רוחב. ההגבלות לא חלות יותר על מסכים עם רוחב מינימלי של 600dp ומעלה. בנוסף, האפליקציות ממלאות את כל חלון התצוגה, ללא קשר ליחס הגובה-רוחב או לכיוון המועדף על המשתמש, ולא נעשה שימוש ב-pillarboxing.

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

אפשר גם לבדוק את ההתנהגות הזו באמצעות מסגרת התאימות של האפליקציה והפעלת דגל התאימות UNIVERSAL_RESIZABLE_BY_DEFAULT.

שינויי תוכנה נפוצים שעלולים לגרום לכשלים

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

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

פרטי ההטמעה

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

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

המערכת מתעלמת מהערכים הבאים של screenOrientation,‏ setRequestedOrientation() ו-getRequestedOrientation():

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

לגבי שינוי הגודל של התצוגה, android:resizeableActivity="false",‏ android:minAspectRatio ו-android:maxAspectRatio לא משפיעים.

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

חריגים

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

• משחקים (מבוססים על הדגל של android:appCategory)
• משתמשים שמביעים הסכמה מפורשת להתנהגות ברירת המחדל של האפליקציה בהגדרות יחס הגובה-רוחב של המכשיר
• מסכים שקטנים מ-sw600dp

ביטול זמני של ההסכמה

כדי לבטל את ההסכמה לפעילות ספציפית, צריך להצהיר על מאפיין המניפסט PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

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

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

בריאות וכושר

‫Android 16 (‏API ברמה 36) כוללת את השינויים הבאים שקשורים לנתוני בריאות וכושר.

הרשאות ל"בריאות וכושר"

באפליקציות שמטרגטות ל-Android 16 ‏ (API level 36) ומעלה, BODY_SENSORS נעשה שימוש בהרשאות יותר מפורטות בקטע android.permissions.health, שגם Health Connect משתמש בהן. החל מ-Android 16, כל API שבעבר דרש את ההרשאה BODY_SENSORS או BODY_SENSORS_BACKGROUND דורש במקום זאת את ההרשאה התואמת android.permissions.health. השינוי הזה משפיע על סוגי הנתונים, ממשקי ה-API וסוגי השירותים שפועלים בחזית הבאים:

• HEART_RATE_BPM מ-Health Services ב-Wear OS
• ‫Sensor.TYPE_HEART_RATE מ-Android Sensor Manager
• ‫heartRateAccuracy ו-heartRateBpm מ-ProtoLayout ב-Wear OS
• ‫FOREGROUND_SERVICE_TYPE_HEALTH במקום BODY_SENSORS, שבו נדרשת ההרשאה android.permission.health המתאימה

אם האפליקציה שלכם משתמשת בממשקי ה-API האלה, היא צריכה לבקש את ההרשאות הגרנולריות המתאימות:

• כדי לעקוב אחרי נתוני קצב הלב, רמת החמצן בדם או טמפרטורת העור בזמן השימוש: צריך לבקש את ההרשאה המפורטת בקטע android.permissions.health, כמו READ_HEART_RATE במקום BODY_SENSORS.
• כדי לקבל גישה לחיישנים ברקע: שולחים בקשה ל-READ_HEALTH_DATA_IN_BACKGROUND במקום ל-BODY_SENSORS_BACKGROUND.

ההרשאות האלה זהות להרשאות שנדרשות כדי לקרוא נתונים מ-Health Connect, מאגר הנתונים של Android לנתוני בריאות, כושר ורווחה.

באפליקציות לנייד.

אפליקציות לנייד שעוברות לשימוש ב-READ_HEART_RATE ובהרשאות גרנולריות אחרות צריכות גם להצהיר על פעילות כדי להציג את מדיניות הפרטיות של האפליקציה. זו אותה דרישה כמו ב-Health Connect.

קישוריות

‫Android 16 (‏API ברמה 36) כוללת את השינויים הבאים במערך Bluetooth כדי לשפר את הקישוריות למכשירים היקפיים.

כוונה חדשה לטיפול באובדן של קשרים ושינויים בהצפנה

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

אפליקציות שמטרגטות את Android 16 יכולות עכשיו:

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

התאמה להטמעות שונות של יצרני ציוד מקורי (OEM)

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

מומלץ להשתמש בהתנהגויות הבאות באפליקציות:

• אם המערכת משדרת את הכוונה ACTION_KEY_MISSING:

  המערכת תנתק את הקישור של ACL (Asynchronous Connection-Less), אבל פרטי הקישור של המכשיר יישמרו (כפי שמתואר כאן).

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

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

• אם הכוונה ACTION_KEY_MISSING לא משודרת:

  הקישור ל-ACL יישאר מחובר, ופרטי הקישור של המכשיר יוסרו על ידי המערכת, בדומה להתנהגות ב-Android 15.

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

דרך חדשה להסרת שיוך Bluetooth

All apps targeting Android 16 are now able to unpair bluetooth devices using a public API in CompanionDeviceManager. If a companion device is being managed as a CDM association, then the app can trigger bluetooth bond removal by using the new removeBond(int) API on the associated device. The app can monitor the bond state changes by listening to the bluetooth device broadcast event ACTION_BOND_STATE_CHANGED.

אבטחה

‫Android 16 (‏API ברמה 36) כוללת את שינויי האבטחה הבאים.

נעילת גרסה של MediaStore

对于以 Android 16 或更高版本为目标平台的应用，MediaStore#getVersion() 现在将是每个应用的唯一标识。这会从版本字符串中移除标识属性，以防止滥用和用于指纹识别技术。应用不应对此版本的格式做出任何假设。在使用此 API 时，应用应已处理版本变更，并且在大多数情况下无需更改其当前行为，除非开发者尝试推断超出此 API 预期范围的其他信息。

כוונות בטוחות יותר

“更安全的 intent”功能是一项多阶段安全计划，旨在提升 Android 的 intent 解析机制的安全性。目标是在 intent 处理期间添加检查，并过滤不符合特定条件的 intent，从而保护应用免受恶意操作的侵害。

在 Android 15 中，该功能侧重于发送应用，现在在 Android 16 中，控制权转移到了接收应用，允许开发者使用其应用清单选择加入严格的 intent 解析。

我们正在实施两项关键变更：

1. 显式 intent 必须与目标组件的 intent 过滤器相匹配：如果 intent 显式定位到某个组件，则应与该组件的 intent 过滤器相匹配。

2. 没有操作的 intent 无法匹配任何 intent 过滤器：未指定操作的 intent 不应解析为任何 intent 过滤器。

这些变更仅在涉及多个应用时适用，不会影响单个应用内的 intent 处理。

影响

选择启用性质意味着，开发者必须在应用清单中明确启用它，才能使其生效。 因此，此功能的影响将仅限于以下应用（开发者）：

• 了解“更安全的 intent”功能及其优势。
• 主动选择在应用中采用更严格的 intent 处理实践。

这种选择性采用的方法可最大限度地降低破坏可能依赖于当前不太安全的 intent 解析行为的现有应用的风险。

虽然在 Android 16 中，初始影响可能有限，但“更安全的 intent”计划的路线图显示，未来 Android 版本中会产生更广泛的影响。我们计划最终将严格的 intent 解析设为默认行为。

“更安全的 intent”功能可让恶意应用更难利用 intent 解析机制中的漏洞，从而有望显著提升 Android 生态系统的安全性。

不过，向选择退出和强制执行的过渡必须谨慎管理，以解决现有应用的潜在兼容性问题。

实现

开发者需要在应用清单中使用 intentMatchingFlags 属性明确启用更严格的 intent 匹配。 以下示例展示了如何为整个应用选择启用该功能，但在接收器上停用/选择停用该功能：

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

有关支持的标志的更多信息：

测试和调试

在强制执行处于有效状态时，如果 intent 调用方已正确填充 intent，应用应能正常运行。 不过，被屏蔽的 intent 会触发警告日志消息（例如 "Intent does not match component's intent filter:" 和 "Access blocked:"），并带有标记 "PackageManager."。这表示存在可能会影响应用的潜在问题，需要引起注意。

Logcat 过滤条件：

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

סינון של קריאות מערכת ל-GPU

To harden the Mali GPU surface, Mali GPU IOCTLs that have been deprecated or are intended solely for GPU development have been blocked in production builds. Additionally, IOCTLs used for GPU profiling have been restricted to the shell process or debuggable applications. Refer to the SAC update for more details on the platform-level policy.

This change takes place on Pixel devices using the Mali GPU (Pixel 6-9). Arm has provided official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their r54p2 release. This list will continue to be maintained in future driver releases.

This change does not impact supported graphics APIs (including Vulkan and OpenGL), and is not expected to impact developers or existing applications. GPU profiling tools such as the Streamline Performance Analyzer and the Android GPU Inspector won't be affected.

Testing

If you see a SELinux denial similar to the following, it is likely your application has been impacted by this change:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

If your application needs to use blocked IOCTLs, please file a bug and assign it to android-partner-security@google.com.

FAQ

1. Does this policy change apply to all OEMs? This change will be opt-in, but available to any OEMs who would like to use this hardening method. Instructions for implementing the change can be found in the implementation documentation.

2. Is it mandatory to make changes in the OEM codebase to implement this, or does it come with a new AOSP release by default? The platform-level change will come with a new AOSP release by default. Vendors may opt-in to this change in their codebase if they would like to apply it.

3. Are SoCs responsible for keeping the IOCTL list up to date? For example, if my device uses an ARM Mali GPU, would I need to reach out to ARM for any of the changes? Individual SoCs must update their IOCTL lists per device upon driver release. For example, ARM will update their published IOCTL list upon driver updates. However, OEMs should make sure that they incorporate the updates in their SEPolicy, and add any selected custom IOCTLs to the lists as needed.

4. Does this change apply to all Pixel in-market devices automatically, or is a user action required to toggle something to apply this change? This change applies to all Pixel in-market devices using the Mali GPU (Pixel 6-9). No user action is required to apply this change.

5. Will use of this policy impact the performance of the kernel driver? This policy was tested on the Mali GPU using GFXBench, and no measurable change to GPU performance was observed.

6. Is it necessary for the IOCTL list to align with the current userspace and kernel driver versions? Yes, the list of allowed IOCTLs must be synchronized with the IOCTLs supported by both the userspace and kernel drivers. If the IOCTLs in the user space or kernel driver are updated, the SEPolicy IOCTL list must be updated to match.

7. ARM has categorized IOCTLs as 'restricted' / 'instrumentation', but we want to use some of them in production use-cases, and/or deny others. Individual OEMs/SoCs are responsible for deciding on how to categorize the IOCTLs they use, based on the configuration of their userspace Mali libraries. ARM's list can be used to help decide on these, but each OEM/SoC's use-case may be different.

פרטיות

‫Android 16 (‏API ברמה 36) כוללת את השינויים הבאים שקשורים לפרטיות.

הרשאה לגישה לרשת המקומית

Devices on the LAN can be accessed by any app that has the INTERNET permission. This makes it easy for apps to connect to local devices but it also has privacy implications such as forming a fingerprint of the user, and being a proxy for location.

The Local Network Protections project aims to protect the user's privacy by gating access to the local network behind a new runtime permission.

Release plan

This change will be deployed between two releases, 25Q2 and 26Q2 respectively. It is imperative that developers follow this guidance for 25Q2 and share feedback because these protections will be enforced at a later Android release. Moreover, they will need to update scenarios which depend on implicit local network access by using the following guidance and prepare for user rejection and revocation of the new permission.

Impact

At the current stage, LNP is an opt-in feature which means only the apps that opt in will be affected. The goal of the opt-in phase is for app developers to understand which parts of their app depend on implicit local network access such that they can prepare to permission guard them for the next release.

Apps will be affected if they access the user's local network using:

• Direct or library use of raw sockets on local network addresses (e.g. mDNS or SSDP service discovery protocol)
• Use of framework level classes that access the local network (e.g. NsdManager)

Traffic to and from a local network address requires local network access permission. The following table lists some common cases:

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in native or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network (i.e. those with a .local suffix) will require local network permission.

Exceptions to the rules above:

• If a device's DNS server is on a local network, traffic to or from it (at port 53) doesn't require local network access permission.
• Applications using Output Switcher as their in-app picker won't need local network permissions (more guidance to come in 2025Q4).

Developer Guidance (Opt-in)

To opt into local network restrictions, do the following:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reboot The device

Now your app's access to the local network is restricted and any attempt to access the local network will lead to socket errors. If you are using APIs that perform local network operations outside of your app process (ex: NsdManager), they won't be impacted during the opt-in phase.

To restore access, you must grant your app permission to NEARBY_WIFI_DEVICES.

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. Go to Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow.

Now your app's access to the local network should be restored and all your scenarios should work as they did prior to opting the app in.

Once enforcement for local network protection begins, here is how the app network traffic will be impacted.

Use the following command to toggle-off the App-Compat flag

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errors

Errors arising from these restrictions will be returned to the calling socket whenever it invokes send or a send variant to a local network address.

Example errors:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Local Network Definition

A local network in this project refers to an IP network that utilizes a broadcast-capable network interface, such as Wi-Fi or Ethernet, but excludes cellular (WWAN) or VPN connections.

The following are considered local networks:

IPv4:

• 169.254.0.0/16 // Link Local
• 100.64.0.0/10 // CGNAT
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6:

• Link-local
• Directly-connected routes
• Stub networks like Thread
• Multiple-subnets (TBD)

Additionally, both multicast addresses (224.0.0.0/4, ff00::/8) and the IPv4 broadcast address (255.255.255.255) are classified as local network addresses.

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

When prompted for photo and video permissions by an app targeting SDK 36 or higher on devices running Android 16 or higher, users who choose to limit access to selected media will see any photos owned by the app pre-selected in the photo picker. Users can deselect any of these pre-selected items, which will revoke the app's access to those photos and videos.