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

Bei Apps, die auf Android 15 (API‑Level 35) ausgerichtet sind, ist das Attribut elegantTextHeight TextView standardmäßig auf true gesetzt. Dadurch wird die kompakte Schriftart durch eine Schriftart ersetzt, die viel besser lesbar ist. Sie können dies überschreiben, indem Sie das Attribut elegantTextHeight auf false festlegen.

In Android 16 wird das Attribut elegantTextHeight eingestellt. Es wird ignoriert, sobald Ihre App auf Android 16 ausgerichtet ist. Die von diesen APIs gesteuerten „UI-Schriftarten“ werden eingestellt. Sie sollten daher alle Layouts anpassen, um eine konsistente und zukunftssichere Textwiedergabe in Arabisch, Laotisch, Birmanisch, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu oder Thailändisch zu gewährleisten.

elegantTextHeight-Verhalten für Apps, die auf Android 14 (API-Level 34) oder niedriger ausgerichtet sind, oder für Apps, die auf Android 15 (API-Level 35) ausgerichtet sind und den Standardwert durch Festlegen des Attributs elegantTextHeight auf false überschrieben haben.

elegantTextHeight-Verhalten für Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, oder für Apps, die auf Android 15 (API-Level 35) ausgerichtet sind und den Standard nicht überschrieben haben, indem sie das Attribut elegantTextHeight auf false gesetzt haben.

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

Da Android-Apps jetzt auf einer Vielzahl von Geräten (z. B. Smartphones, Tablets, faltbare Smartphones, Desktops, Autos und Fernseher) und in verschiedenen Fenstermodi auf großen Displays (z. B. im Split-Screen-Modus und im Desktop-Fenstermodus) ausgeführt werden können, sollten Entwickler Android-Apps erstellen, die sich an jede Bildschirm- und Fenstergröße anpassen, unabhängig von der Geräteausrichtung. Paradigmen wie das Einschränken der Ausrichtung und Größenänderung sind in der heutigen Welt mit mehreren Geräten zu restriktiv.

Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis ignorieren

Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, gelten Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis nicht mehr auf Displays mit einer Breite von mindestens 600 dp. Apps füllen das gesamte Displayfenster, unabhängig vom Seitenverhältnis oder der bevorzugten Ausrichtung des Nutzers, und Pillarboxing wird nicht verwendet.

Mit dieser Änderung wird ein neues Standardplattformverhalten eingeführt. Android entwickelt sich zu einem Modell, bei dem Apps sich an verschiedene Ausrichtungen, Displaygrößen und Seitenverhältnisse anpassen müssen. Einschränkungen wie eine feste Ausrichtung oder eine begrenzte Größenänderung behindern die Anpassungsfähigkeit von Apps. Machen Sie Ihre App anpassungsfähig, um die bestmögliche Nutzererfahrung zu bieten.

Sie können dieses Verhalten auch mit dem Framework für die App-Kompatibilität testen und das UNIVERSAL_RESIZABLE_BY_DEFAULT Kompatibilitätsflag aktivieren.

Häufige nicht abwärtskompatible Änderungen

Das Ignorieren von Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis kann sich auf die Benutzeroberfläche Ihrer App auf einigen Geräten auswirken, insbesondere auf Elemente, die für kleine Layouts im Hochformat entwickelt wurden. Es kann beispielsweise zu Problemen wie gestreckten Layouts und Animationen und Komponenten außerhalb des Bildschirms kommen. Annahmen zum Seitenverhältnis oder zur Ausrichtung können zu visuellen Problemen mit Ihrer App führen. Weitere Informationen dazu, wie Sie diese vermeiden und das adaptive Verhalten Ihrer App verbessern können

Wenn die Geräteausrichtung zugelassen wird, werden Aktivitäten häufiger neu erstellt. Dadurch können Nutzerdaten verloren gehen, wenn sie nicht ordnungsgemäß gespeichert werden. Informationen zum korrekten Speichern des UI Status finden Sie unter UI-Status speichern.

Details zur Implementierung

Die folgenden Manifestattribute und Runtime-APIs werden auf Geräten mit großen Displays im Vollbild- und Multifenstermodus ignoriert:

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

Die folgenden Werte für screenOrientation, setRequestedOrientation() und getRequestedOrientation() werden ignoriert:

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

In Bezug auf die Größenänderung des Displays haben android:resizeableActivity="false", android:minAspectRatio und android:maxAspectRatio keine Auswirkungen.

Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, werden Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis auf großen Displays standardmäßig ignoriert. Jede App, die noch nicht vollständig bereit ist, kann dieses Verhalten vorübergehend überschreiben, indem sie sich abmeldet. Dadurch wird das vorherige Verhalten beibehalten und die App wird im Kompatibilitätsmodus platziert.

Ausnahmen

Die Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis von Android 16 gelten in den folgenden Situationen nicht:

• Spiele (basierend auf dem android:appCategory Flag)
• Nutzer, die in den Einstellungen für das Seitenverhältnis des Geräts explizit das Standardverhalten der App aktivieren
• Displays, die kleiner als sw600dp sind

Vorübergehend abmelden

Wenn Sie eine bestimmte Aktivität abmelden möchten, deklarieren Sie die Manifest-Property PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY:

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

Wenn zu viele Teile Ihrer App nicht für Android 16 bereit sind, können Sie sich vollständig abmelden, indem Sie dieselbe Property auf Anwendungsebene anwenden:

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

Wichtig: Die Abmeldung ist vorübergehend und gilt nicht, wenn Sie in einer zukünftigen Android-Version auf API-Level 37 ausgerichtet sind. Bei Apps, die auf API-Level 37 ausgerichtet sind, werden Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis auf Displays mit mindestens sw600dp ignoriert.

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 解析。

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

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

2. 没有操作的 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>

注意： 该属性也可以在 <application> 标记以及组件标记（例如 <activity>、<activity-alias>、<receiver>、<service>、<provider>）中指定，并且组件中的属性可用于替换 <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

Um die Mali-GPU-Oberfläche zu härten, wurden Mali-GPU-IOCTLs, die veraltet sind oder ausschließlich für die GPU-Entwicklung vorgesehen sind, in Produktions-Builds blockiert. Außerdem wurden IOCTLs, die für das GPU-Profiling verwendet werden, auf den Shell-Prozess oder debugfähige Anwendungen beschränkt. Weitere Informationen zur Richtlinie auf Plattformebene finden Sie im SAC-Update.

Diese Änderung betrifft Pixel-Geräte mit der Mali-GPU (Pixel 6–9). Arm hat in der Version r54p2 in Documentation/ioctl-categories.rst eine offizielle Kategorisierung der IOCTLs vorgenommen. Diese Liste wird auch in zukünftigen Treiberversionen gepflegt.

Diese Änderung hat keine Auswirkungen auf unterstützte Grafik-APIs (einschließlich Vulkan und OpenGL) und wird sich voraussichtlich nicht auf Entwickler oder bestehende Anwendungen auswirken. GPU-Profiling-Tools wie Streamline Performance Analyzer und Android GPU Inspector sind nicht betroffen.

Test

Wenn Sie eine SELinux-Verweigerung sehen, die der folgenden ähnelt, ist Ihre Anwendung wahrscheinlich von dieser Änderung betroffen:

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

Wenn Ihre Anwendung blockierte IOCTLs verwenden muss, melden Sie bitte einen Fehler und weisen Sie ihn [e-mail] zu.

FAQ

1. Gilt diese Richtlinienänderung für alle OEMs? Diese Änderung ist optional, aber für alle OEMs verfügbar, die diese Härtungsmethode verwenden möchten. Eine Anleitung zur Implementierung der Änderung finden Sie in der Implementierungsdokumentation.

2. Müssen Änderungen an der OEM-Codebasis vorgenommen werden, um diese Änderung zu implementieren, oder ist sie standardmäßig in einem neuen AOSP-Release enthalten? Die Änderung auf Plattformebene ist standardmäßig in einem neuen AOSP-Release enthalten. Anbieter können diese Änderung in ihre Codebasis aufnehmen, wenn sie sie anwenden möchten.

3. Sind SoCs dafür verantwortlich, die IOCTL-Liste auf dem neuesten Stand zu halten? Wenn mein Gerät beispielsweise eine ARM Mali-GPU verwendet, muss ich mich dann bei Änderungen an ARM wenden? Einzelne SoCs müssen ihre IOCTL-Listen pro Gerät nach der Treiberveröffentlichung aktualisieren. ARM aktualisiert beispielsweise die veröffentlichte IOCTL-Liste nach Treiberupdates. OEMs sollten jedoch darauf achten, dass sie die Updates in ihre SEPolicy einbeziehen und ausgewählte benutzerdefinierte IOCTLs nach Bedarf zu den Listen hinzufügen.

4. Gilt diese Änderung automatisch für alle im Handel erhältlichen Pixel-Geräte oder muss ein Nutzer etwas tun, um diese Änderung anzuwenden? Diese Änderung gilt für alle im Handel erhältlichen Pixel-Geräte mit der Mali-GPU (Pixel 6–9). Es ist keine Nutzeraktion erforderlich, um diese Änderung anzuwenden.

5. Wirkt sich die Verwendung dieser Richtlinie auf die Leistung des Kernel-Treibers aus? Diese Richtlinie wurde auf der Mali-GPU mit GFXBench getestet. Es wurden keine messbaren Änderungen an der GPU-Leistung festgestellt.

6. Muss die IOCTL-Liste mit den aktuellen Versionen des Userspace- und Kernel-Treibers übereinstimmen? Ja, die Liste der zulässigen IOCTLs muss mit den IOCTLs synchronisiert werden, die sowohl vom Userspace- als auch vom Kernel-Treiber unterstützt werden. Wenn die IOCTLs im Userspace- oder Kernel-Treiber aktualisiert werden, muss die SEPolicy-IOCTL-Liste entsprechend aktualisiert werden.

7. ARM hat IOCTLs als „eingeschränkt“ / „Instrumentierung“ kategorisiert, aber wir möchten einige davon in Produktionsanwendungsfällen verwenden und/oder andere ablehnen. Einzelne OEMs/SoCs sind dafür verantwortlich, wie sie die von ihnen verwendeten IOCTLs kategorisieren, basierend auf der Konfiguration ihrer Mali-Bibliotheken im Userspace. Die Liste von ARM kann bei der Entscheidung helfen, aber der Anwendungsfall jedes OEM/SoC kann unterschiedlich sein.

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.

Hinweis :Bei Traffic, der von Android-Webviews stammt, für die der Zugriff auf das lokale Netzwerk erforderlich ist, wird der Berechtigungsstatus von der Host-App übernommen.

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).

Hinweis :Viele Media-Streaming-Szenarien hängen vom Zugriff auf das lokale Netzwerk ab und sind von dieser Änderung betroffen. Allerdings müssen nicht alle Apps, die Casting anbieten, die neue Berechtigung anfordern. Zukünftige APIs und Anleitungen für die Verarbeitung von Casting-Szenarien werden im vierten Quartal 2025 bereitgestellt.

Entwicklerleitfaden (Opt-in)

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

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

3. Aktivieren oder deaktivieren Sie das Appcompat-Flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. 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.

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

Hinweis :In einer zukünftigen Android-Version wird diese Funktion durch eine neue Berechtigung in der Berechtigungsgruppe „Geräte in der Nähe“ geschützt.

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

Wenn Nutzer auf Geräten mit Android 16 oder höher von einer App, die auf SDK 36 oder höher ausgerichtet ist, um Berechtigungen für Fotos und Videos gebeten werden und den Zugriff auf ausgewählte Medien einschränken, werden alle Fotos, die der App gehören, in der Bildauswahl vorab ausgewählt angezeigt. Nutzer können die Auswahl dieser Elemente jederzeit aufheben. Dadurch wird der Zugriff der App auf diese Fotos und Videos widerrufen.