Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Verhaltensänderungen: Apps, die auf Android 16 oder höher ausgerichtet sind

Wie bei früheren Versionen enthält Android 16 Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps, die auf Android 16 oder höher ausgerichtet sind. Wenn Ihre App auf Android 16 oder höher ausgerichtet ist, sollten Sie sie gegebenenfalls so ändern, dass sie diese Verhaltensweisen unterstützt.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die sich auf alle Apps auswirken die unter Android 16 ausgeführt werden, unabhängig von der targetSdkVersion Ihrer App.

Nutzererfahrung und System-UI

Android 16 (API-Level 36) enthält die folgenden Änderungen, die eine einheitlichere und intuitivere Nutzererfahrung ermöglichen sollen.

Deaktivierung der Option „Nur Foto, ohne Rand“ wird entfernt

Android 15 强制实行全屏显示，但您的应用可以通过将 R.attr#windowOptOutEdgeToEdgeEnforcement 设置为 true 来选择停用。对于以 Android 16（API 级别 36）为目标平台的应用，R.attr#windowOptOutEdgeToEdgeEnforcement 已被废弃并停用，并且您的应用无法选择不采用从边缘到边缘的布局。

如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 15 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会继续正常运行。
如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 16 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会被停用。

如需在 Android 16 中进行测试，请确保您的应用支持无边框设计，并移除所有 R.attr#windowOptOutEdgeToEdgeEnforcement 用法，以便您的应用在 Android 15 设备上也能支持无边框设计。如需支持从边缘到边缘的显示，请参阅 Compose 和 Views 指南。

Migration oder Deaktivierung für die intelligente „Zurück“-Geste erforderlich

Bei Apps, die auf Android 16 (API-Level 36) oder höher ausgerichtet sind und auf einem Gerät mit Android 16 oder höher ausgeführt werden, sind die Systemanimationen für die intelligente „Zurück“-Touchgeste (Zurück zum Startbildschirm, Aufgabenübergang und Aktivitätsübergang) standardmäßig aktiviert. Außerdem wird onBackPressed nicht aufgerufen und KeyEvent.KEYCODE_BACK nicht mehr gesendet.

Wenn Ihre App das „Zurück“-Ereignis abfängt und Sie noch nicht zur intelligenten „Zurück“-Geste migriert haben, aktualisieren Sie Ihre App, um unterstützte APIs für die Rückwärtsnavigation zu verwenden. Alternativ können Sie die Funktion vorübergehend deaktivieren, indem Sie das android:enableOnBackInvokedCallback-Attribut im <application> oder <activity>-Tag der Datei AndroidManifest.xml Ihrer App auf false setzen.

Die Animation für die intelligente „Zurück“-Touchgeste zum Startbildschirm.

Die Animation für die intelligente „Zurück“-Touchgeste für den Aktivitätsübergang.

Die Animation für die intelligente „Zurück“-Touchgeste für den Aufgabenübergang.

Elegant Font APIs eingestellt und deaktiviert

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

Hauptfunktion

Android 16 (API-Level 36) enthält die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems ändern oder erweitern.

Optimierung der Arbeitsplanung mit fester Rate

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

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

Formfaktoren von Geräten

Android 16 (API-Level 36) enthält die folgenden Änderungen für Apps, die auf Geräten mit großem Bildschirm angezeigt werden.

Adaptive Layouts

现在，Android 应用可在各种设备（例如手机、平板电脑、可折叠设备、桌面设备、汽车和电视）上运行，并且在大屏设备上支持多种窗口模式（例如分屏和桌面窗口化模式），因此开发者应构建能够适应任何屏幕和窗口尺寸的 Android 应用，无论设备屏幕方向如何。在当今多设备的世界中，限制屏幕方向和尺寸可调整性等范式过于严格。

忽略屏幕方向、尺寸可调整性和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，在最小宽度 >= 600dp 的显示屏上，屏幕方向、尺寸调整能力和宽高比限制不再适用。应用会填满整个显示窗口，无论宽高比或用户偏好的屏幕方向如何，都不会使用竖屏黑边模式。

此变更引入了新的标准平台行为。Android 正在向一种模型转变，在该模型中，应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或有限的尺寸调整等限制会阻碍应用的适应性。使应用具有自适应性，以提供尽可能最佳的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的重大更改

忽略屏幕方向、可调整大小性和宽高比限制可能会影响应用在某些设备上的界面，尤其是那些专为锁定为纵向的小布局设计的元素：例如，布局拉伸、动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留用户状态，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在全屏模式和多窗口模式下，以下清单属性和运行时 API 会被大屏设备忽略：

系统会忽略 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 的屏幕

暂时选择不接收

如需选择停用特定 activity，请声明 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>

Gesundheit und Fitness

Android 16 (API-Level 36) enthält die folgenden Änderungen in Bezug auf Gesundheits- und Fitnessdaten.

Berechtigungen für Gesundheits- und Fitnessdaten

对于以 Android 16（API 级别 36）或更高版本为目标平台的应用， BODY_SENSORS 权限使用更精细的权限 under android.permissions.health，which Health Connect also uses。从 Android 16 开始，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

HEART_RATE_BPM Wear OS 上的健康服务
Sensor.TYPE_HEART_RATE 来自 Android Sensor Manager
heartRateAccuracy 和 heartRateBpm（来自 Wear OS 上的 ProtoLayout）
FOREGROUND_SERVICE_TYPE_HEALTH ，其中需要使用相应的 android.permission.health 权限来代替 BODY_SENSORS

如果您的应用使用这些 API，则应请求相应的精细权限：

如需在使用期间监测心率、血氧饱和度或体表温度：请请求 android.permissions.health 下的精细权限，例如 READ_HEART_RATE，而不是 BODY_SENSORS。
如需访问后台传感器，请请求 READ_HEALTH_DATA_IN_BACKGROUND，而不是 BODY_SENSORS_BACKGROUND。

这些权限与保护对 Health Connect（用于存储健康、健身和保健数据的 Android 数据存储区）中数据的读取访问权限的权限相同。

移动应用

迁移为使用 READ_HEART_RATE 和其他精细权限的移动应用还必须声明一项 activity 以显示应用的隐私权政策。这与健康数据共享的要求相同。

Konnektivität

Android 16 (API-Level 36) enthält die folgenden Änderungen am Bluetooth-Stack, um die Konnektivität mit Peripheriegeräten zu verbessern.

Neue Intents für den Umgang mit Verbindungsverlusten und Verschlüsselungsänderungen

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

如果广播 ACTION_KEY_MISSING intent：

系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。
如果未广播 ACTION_KEY_MISSING intent：

ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

Neue Möglichkeit zum Entfernen einer Bluetooth-Verbindung

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 ACTION_BOND_STATE_CHANGED 来监控配对状态变化。

Sicherheit

Android 16 (API-Level 36) enthält die folgenden Sicherheitsänderungen.

Version von MediaStore gesperrt

Bei Apps, die auf Android 16 oder höher ausgerichtet sind, ist MediaStore#getVersion() jetzt für jede App eindeutig. Dadurch werden identifizierende Eigenschaften aus dem Versionsstring entfernt, um Missbrauch und Verwendung für Fingerprinting-Techniken zu verhindern. Apps dürfen keine Annahmen über das Format dieser Version treffen. Apps sollten Versionsänderungen bereits bei der Verwendung dieser API verarbeiten und in den meisten Fällen sollte ihr aktuelles Verhalten nicht geändert werden müssen, es sei denn, der Entwickler hat versucht, zusätzliche Informationen abzuleiten, die über den beabsichtigten Umfang dieser API hinausgehen.

Sicherere Intents

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

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

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

显式 intent 必须与目标组件的 intent 过滤器匹配：如果 intent 显式定位到某个组件，则应与该组件的 intent 过滤器匹配。
没有操作的 intent 无法匹配任何 intent 过滤器：未指定操作的 intent 不应解析为任何 intent 过滤器。

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

影响

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

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

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

虽然 Safer Intents 计划在 Android 16 中的初始影响可能有限，但其路线图表明，该计划将在未来的 Android 版本中产生更广泛的影响。我们计划最终将严格的意图解析设为默认行为。

通过使恶意应用更难利用 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>

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

标志名称	说明
enforceIntentFilter	对传入的 intent 强制执行更严格的匹配
无	针对传入 intent 停用所有特殊匹配规则。指定多个标志时，系统会优先考虑“无”标志，以解决值冲突问题
allowNullAction	放宽匹配规则，以允许匹配没有操作的 intent。此标志应与“enforceIntentFilter”结合使用，以实现特定行为

测试和调试

在强制执行处于有效状态时，如果 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:")

Filterung von GPU-Systemaufrufen

为了加固 Mali GPU Surface，我们已在生产版本中屏蔽了已废弃或仅用于 GPU 开发的 Mali GPU IOCTL。此外，用于 GPU 性能剖析的 IOCTL 已限制为 shell 进程或可调试的应用。如需详细了解平台级政策，请参阅 SAC 更新。

此项变更适用于使用 Mali GPU 的 Pixel 设备（Pixel 6-9）。Arm 已在其 r54p2 release 版本的 Documentation/ioctl-categories.rst 中提供了 IOCTL 的官方分类。此列表将在未来的驱动程序版本中继续维护。

此项变更不会影响受支持的图形 API（包括 Vulkan 和 OpenGL），预计也不会影响开发者或现有应用。 Streamline Performance Analyzer 和 Android GPU 检查器等 GPU 性能剖析工具不会受到影响。

测试

如果您看到类似以下内容的 SELinux 拒绝，则您的应用很可能受到了此项变更的影响：

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

如果您的应用需要使用被屏蔽的 IOCTL，请提交 bug 并将其分配给 android-partner-security@google.com。

常见问题解答

此项政策变更是否适用于所有 OEM？ 此项变更将采用选择启用模式，但任何想要使用此加固方法的原始设备制造商(OEM)都可以使用。如需了解如何实现此项变更，请参阅实现文档。
是否必须在 OEM 代码库中进行更改才能实现此项变更，还是默认随新的 AOSP 版本提供？ 平台级变更将默认随新的 AOSP 版本提供。供应商可以选择在其代码库中启用此项变更，以便应用此项变更。
SoC 是否负责让 IOCTL 列表保持最新状态？例如，如果我的设备使用 ARM Mali GPU，我是否需要就任何变更与 ARM 联系？ 各个 SoC 必须在驱动程序发布后根据设备更新其 IOCTL 列表。例如，ARM 会在驱动程序更新后更新其发布的 IOCTL 列表。不过，OEM 应确保将更新纳入其 SEPolicy，并根据需要将任何选定的自定义 IOCTL 添加到列表中。
此项变更是否会自动应用于所有在售 Pixel 设备，还是需要用户执行操作来切换某些内容以应用此项变更？ 此项变更适用于所有使用 Mali GPU 的在售 Pixel 设备（Pixel 6-9）。无需用户执行任何操作即可应用此项变更。
使用此政策是否会影响内核驱动程序的性能？ 我们已使用 GFXBench 在 Mali GPU 上对此政策进行了测试，未观察到 GPU 性能发生任何可衡量的变化。
IOCTL 列表是否需要与当前的用户空间和内核驱动程序版本保持一致？是，允许的 IOCTL 列表必须与用户空间和内核驱动程序支持的 IOCTL 同步。如果用户空间或内核驱动程序中的 IOCTL 发生更新，则必须更新 SEPolicy IOCTL 列表以进行匹配。
ARM 已将 IOCTL 分类为“受限”/“检测”，但我们希望在生产用例中使用其中的一些 IOCTL，并/或拒绝其他 IOCTL。 各个 OEM/SoC 负责根据其用户空间 Mali 库的配置，决定如何对其使用的 IOCTL 进行分类。 ARM 的列表可用于帮助决定这些内容，但每个 OEM/SoC 的用例可能有所不同。

Datenschutz

Android 16 (API-Level 36) enthält die folgenden Änderungen in Bezug auf den Datenschutz.

Berechtigung für das lokale Netzwerk

Auf Geräte im LAN kann von jeder App zugegriffen werden, die die Berechtigung INTERNET hat. Dadurch können Apps problemlos eine Verbindung zu lokalen Geräten herstellen. Dies hat jedoch auch Auswirkungen auf den Datenschutz, z. B. durch die Erstellung eines Fingerabdrucks des Nutzers und die Verwendung als Proxy für den Standort.

Das Projekt „Local Network Protections“ zielt darauf ab, die Privatsphäre der Nutzer zu schützen, indem der Zugriff auf das lokale Netzwerk durch eine neue Laufzeitberechtigung eingeschränkt wird.

Release-Plan

Diese Änderung wird zwischen zwei Releases eingeführt, nämlich 25Q2 und 26Q2. Entwickler müssen diese Anleitung für das 2. Quartal 2025 unbedingt befolgen und Feedback geben, da diese Schutzmaßnahmen in einem späteren Android-Release erzwungen werden. Außerdem müssen sie Szenarien aktualisieren, die auf implizitem lokalen Netzwerkzugriff basieren. Verwenden Sie dazu die folgende Anleitung und bereiten Sie sich auf die Ablehnung und den Widerruf der neuen Berechtigung durch Nutzer vor.

Auswirkungen

Derzeit ist LNP eine Opt-in-Funktion. Das bedeutet, dass nur die Apps betroffen sind, für die sie aktiviert wurde. In der Opt-in-Phase sollen App-Entwickler herausfinden, welche Teile ihrer App auf impliziten Zugriff auf das lokale Netzwerk angewiesen sind, damit sie sich auf die Berechtigungsanforderungen für die nächste Version vorbereiten können.

Apps sind betroffen, wenn sie über folgende Methoden auf das lokale Netzwerk des Nutzers zugreifen:

Direkte oder bibliotheksbasierte Verwendung von Raw Sockets für lokale Netzwerkadressen (z.B. mDNS- oder SSDP-Service Discovery-Protokoll)
Verwendung von Klassen auf Framework-Ebene, die auf das lokale Netzwerk zugreifen (z.B. NsdManager)

Für Traffic zu und von einer lokalen Netzwerkadresse ist die Berechtigung für den Zugriff auf das lokale Netzwerk erforderlich. In der folgenden Tabelle sind einige häufige Fälle aufgeführt:

Low-Level-Netzwerkbetrieb der App	Berechtigung für das lokale Netzwerk erforderlich
Ausgehende TCP-Verbindung herstellen	Ja
Eingehende TCP-Verbindungen akzeptieren	Ja
Senden eines UDP-Unicast, ‑Multicast oder ‑Broadcast	Ja
Empfangen eines eingehenden UDP-Unicast, ‑Multicast oder ‑Broadcast	Ja

Diese Einschränkungen sind tief im Netzwerk-Stack implementiert und gelten daher für alle Netzwerk-APIs. Dazu gehören Sockets, die in nativem oder verwaltetem Code erstellt wurden, Netzwerkbibliotheken wie Cronet und OkHttp sowie alle APIs, die darauf basieren. Wenn Sie versuchen, Dienste im lokalen Netzwerk aufzulösen (d.h. Dienste mit dem Suffix „.local“), ist die Berechtigung für das lokale Netzwerk erforderlich.

Ausnahmen von den oben genannten Regeln:

Wenn sich der DNS-Server eines Geräts in einem lokalen Netzwerk befindet, ist für den Traffic zu oder von diesem Gerät (über Port 53) keine Berechtigung für den Zugriff auf das lokale Netzwerk erforderlich.
Für Anwendungen, die Output Switcher als In-App-Auswahl verwenden, sind keine Berechtigungen für das lokale Netzwerk erforderlich (weitere Informationen folgen im 4. Quartal 2025).

Entwicklerleitfaden (Opt-in)

So aktivieren Sie Einschränkungen für das lokale Netzwerk:

Flashen Sie das Gerät mit einem Build mit 25Q2 Beta 3 oder höher.
Installieren Sie die zu testende App.

Aktivieren oder deaktivieren Sie das Appcompat-Flag in adb:

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

Gerät neu starten

Der Zugriff Ihrer App auf das lokale Netzwerk ist jetzt eingeschränkt und jeder Versuch, auf das lokale Netzwerk zuzugreifen, führt zu Socket-Fehlern. Wenn Sie APIs verwenden, die lokale Netzwerkoperationen außerhalb Ihres App-Prozesses ausführen (z. B. NsdManager), sind sie während der Opt-in-Phase nicht betroffen.

Um den Zugriff wiederherzustellen, müssen Sie Ihrer App die Berechtigung für NEARBY_WIFI_DEVICES erteilen.

Die App muss die Berechtigung NEARBY_WIFI_DEVICES in ihrem Manifest deklarieren.
Gehen Sie zu Einstellungen > Apps > [Name der App] > Berechtigungen > Geräte in der Nähe > Zulassen.

Der Zugriff Ihrer App auf das lokale Netzwerk sollte jetzt wiederhergestellt sein und alle Ihre Szenarien sollten wie vor der Aktivierung der App funktionieren.

Sobald die Erzwingung des Schutzes des lokalen Netzwerks beginnt, wirkt sich das auf den Netzwerkverkehr der App aus.

Berechtigung	Ausgehende LAN-Anfrage	Ausgehende/eingehende Internetanfrage	Eingehende LAN-Anfrage
Gewährt	YouTube?	YouTube?	YouTube?
Nicht gewährt	Pannen	YouTube?	Pannen

Verwenden Sie den folgenden Befehl, um das App-Compat-Flag zu deaktivieren:

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Fehler

Fehler, die durch diese Einschränkungen entstehen, werden an den aufrufenden Socket zurückgegeben, wenn er „send“ oder eine „send“-Variante für eine lokale Netzwerkadresse aufruft.

Beispiel für Fehlermeldung:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Definition des lokalen Netzwerks

Ein lokales Netzwerk in diesem Projekt bezieht sich auf ein IP-Netzwerk, das eine für Broadcasts geeignete Netzwerkschnittstelle wie WLAN oder Ethernet verwendet, jedoch keine Mobilfunk- (WWAN) oder VPN-Verbindungen.

Die folgenden Netzwerke gelten als lokale Netzwerke:

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
Direkt verbundene Routen
Stummelnetzwerke wie Thread
Mehrere Subnetze (noch nicht festgelegt)

Außerdem werden sowohl Multicast-Adressen (224.0.0.0/4, ff00::/8) als auch die IPv4-Broadcast-Adresse (255.255.255.255) als lokale Netzwerkadressen klassifiziert.

App-eigene Fotos

当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。