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 anpassen, 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 vom targetSdkVersion Ihrer App.

User Experience und System-UI

Android 16 (API-Level 36) enthält die folgenden Änderungen, die für eine einheitlichere, intuitive Nutzererfahrung sorgen sollen.

Deaktivierung von Edge-to-Edge-Anzeigen wird eingestellt

Android 15: Edge-to-Edge-Anzeige für Apps, die auf Android 15 ausgerichtet sind (API-Level 35): Für Apps, die auf Android 15 (API-Level 35) ausgerichtet sind, wird die Edge-to-Edge-Anzeige erzwungen. Ihre App kann jedoch deaktiviert werden, indem Sie R.attr#windowOptOutEdgeToEdgeEnforcement auf true setzen. Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, ist R.attr#windowOptOutEdgeToEdgeEnforcement eingestellt und deaktiviert. Deine App kann nicht deaktivieren, dass sie randlos angezeigt wird.

• Wenn Ihre App auf Android 16 (API-Level 36) ausgerichtet ist und auf einem Android 15-Gerät ausgeführt wird, funktioniert R.attr#windowOptOutEdgeToEdgeEnforcement weiterhin.
• Wenn Ihre App auf Android 16 (API-Level 36) ausgerichtet ist und auf einem Android 16-Gerät ausgeführt wird, ist R.attr#windowOptOutEdgeToEdgeEnforcement deaktiviert.

Wenn Sie Ihre App unter Android 16 testen, muss sie Edge-to-Edge unterstützen. Entfernen Sie alle Verwendungen von R.attr#windowOptOutEdgeToEdgeEnforcement, damit Ihre App auch auf einem Android 15-Gerät Edge-to-Edge unterstützt. Informationen zur Unterstützung von Edge-to-Edge finden Sie in den Anleitungen zu Compose und Views.

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

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back event and you haven't migrated to predictive back yet, update your app to use supported back navigation APIs, or temporarily opt out by setting the android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

The predictive back-to-home animation.

The predictive cross-activity animation.

The predictive cross-task animation.

Elegant Font APIs eingestellt und deaktiviert

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

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

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用，或针对以 Android 15（API 级别 35）为目标平台且通过将 elegantTextHeight 属性设置为 false 替换默认值的应用，

elegantTextHeight 行为。

以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其

elegantTextHeight 行为。

Hauptfunktion

Android 16 (API-Level 36) umfasst die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems modifizieren oder erweitern.

Optimierung der Arbeitsplanung mit festem Tarif

在以 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-Apps laufen jetzt auf einer Vielzahl von Geräten (z. B. Smartphones, Tablets, faltbare Geräte, Computer, Autos und Fernseher) und in verschiedenen Fenstermodi auf großen Bildschirmen (z. B. Split-Screen und Desktop-Fenster). Entwickler sollten Android-Apps entwickeln, die sich unabhängig von der Geräteausrichtung an jede Bildschirm- und Fenstergröße anpassen. Paradigmen wie die Einschränkung der Ausrichtung und Größenänderung sind in der heutigen Welt mit mehreren Geräten zu restriktiv.

Einschränkungen in Bezug auf Ausrichtung, Anpassbarkeit und Seitenverhältnis ignorieren

Für Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, enthält Android 16 Änderungen an der Art und Weise, wie das System Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis verwaltet. Auf Displays mit einer Mindestbreite von 600 dp gelten die Einschränkungen nicht mehr. Apps füllen auch das gesamte Displayfenster aus, unabhängig vom Seitenverhältnis oder der bevorzugten Ausrichtung des Nutzers. Pillarboxing wird nicht verwendet.

Mit dieser Änderung wird ein neues Standardplattformverhalten eingeführt. Android entwickelt sich zu einem Modell, bei dem Apps an verschiedene Ausrichtungen, Displaygrößen und Seitenverhältnisse angepasst werden müssen. Einschränkungen wie eine feste Ausrichtung oder eine begrenzte Anpassungsfähigkeit der Größe beeinträchtigen die Anpassungsfähigkeit von Apps. Wir empfehlen daher, Ihre App anpassungsfähig zu machen, um Nutzern die bestmögliche Nutzererfahrung zu bieten.

Sie können dieses Verhalten auch mit dem App-Kompatibilitäts-Framework testen und das Kompatibilitäts-Flag UNIVERSAL_RESIZABLE_BY_DEFAULT aktivieren.

Häufige wichtige Änderungen

Wenn Sie die Einschränkungen für Ausrichtung, Anpassbarkeit und Seitenverhältnis ignorieren, kann sich das auf die Benutzeroberfläche Ihrer App auf einigen Geräten auswirken, insbesondere auf Elemente, die für kleine Layouts im Hochformat entwickelt wurden. Beispiele sind gestreckte Layouts sowie Animationen und Komponenten, die nicht auf dem Bildschirm angezeigt werden. Annahmen zum Seitenverhältnis oder zur Ausrichtung können zu visuellen Problemen mit Ihrer App führen. Weitere Informationen dazu, wie Sie diese Probleme vermeiden und das adaptive Verhalten Ihrer App verbessern können.

Wenn Sie die Geräteausrichtung zulassen, wird die Aktivität häufiger neu erstellt. Dadurch kann der Nutzerstatus verloren gehen, wenn er nicht richtig beibehalten wird. Informationen zum korrekten Speichern des UI-Zustands finden Sie unter UI-Zustände speichern.

Details zur Implementierung

Die folgenden Manifestattribute und Laufzeit-APIs werden auf Geräten mit großem Display im Vollbild- und Mehrfenstermodus 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

Die Größenanpassung des Displays wird durch android:resizeableActivity="false", android:minAspectRatio und android:maxAspectRatio nicht beeinflusst.

Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, werden die Ausrichtung, die Anpassbarkeit der Größe und die Einschränkungen des Seitenverhältnisses auf großen Bildschirmen standardmäßig ignoriert. Jede App, die noch nicht vollständig bereit ist, kann dieses Verhalten jedoch vorübergehend überschreiben, indem sie die Funktion deaktiviert. Dadurch wird das vorherige Verhalten aktiviert, bei dem die App in den Kompatibilitätsmodus versetzt wird.

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 der Flagge android:appCategory)
• Nutzer, die das Standardverhalten der App in den Einstellungen für das Seitenverhältnis des Geräts explizit aktivieren
• Bildschirme, die kleiner als sw600dp sind

Vorübergehend deaktivieren

Wenn Sie eine bestimmte Aktivität deaktivieren möchten, deklarieren Sie die Manifest-Eigenschaft 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 die Funktion vollständig deaktivieren, indem Sie dieselbe Property auf Anwendungsebene anwenden:

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

Wichtig :Der Opt-out ist vorübergehend und gilt nicht, wenn Sie in einem zukünftigen Android-Release auf API-Level 37 ausgerichtet sind. Das bedeutet, dass für Apps, die auf API-Level 37 ausgerichtet sind, Einschränkungen für Ausrichtung, Anpassbarkeit der Größe und Seitenverhältnis auf Displays mit mindestens sw600dp ignoriert werden.

Gesundheit und Fitness

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

Berechtigungen für Gesundheit und Fitness

Für Apps, die auf Android 16 (API‑Level 36) oder höher ausgerichtet sind, werden für BODY_SENSORS-Berechtigungen detailliertere Berechtigungen unter android.permissions.health verwendet, die auch von Health Connect genutzt werden. Ab Android 16 ist für alle APIs, für die bisher BODY_SENSORS oder BODY_SENSORS_BACKGROUND erforderlich war, stattdessen die entsprechende android.permissions.health-Berechtigung erforderlich. Dies betrifft die folgenden Datentypen, APIs und Arten von Vordergrunddiensten:

• HEART_RATE_BPM aus den Gesundheitsdiensten unter Wear OS
• Sensor.TYPE_HEART_RATE aus dem Android Sensor Manager
• heartRateAccuracy und heartRateBpm aus ProtoLayout unter Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH, wobei die entsprechende Berechtigung android.permission.health anstelle von BODY_SENSORS erforderlich ist

Wenn Ihre App diese APIs verwendet, sollte sie die entsprechenden detaillierten Berechtigungen anfordern:

• Für die Überwachung von Herzfrequenz, SpO2 oder Hauttemperatur während der Nutzung: Fordern Sie die detaillierte Berechtigung unter android.permissions.health an, z. B. READ_HEART_RATE anstelle von BODY_SENSORS.
• Für den Zugriff auf Sensoren im Hintergrund: Fordern Sie READ_HEALTH_DATA_IN_BACKGROUND anstelle von BODY_SENSORS_BACKGROUND an.

Diese Berechtigungen sind dieselben, die den Zugriff auf das Lesen von Daten aus Health Connect, dem Android-Datenspeicher für Gesundheits‑, Fitness- und Wellnessdaten, schützen.

Mobile Apps

Mobile Apps, die zur Verwendung von READ_HEART_RATE und anderen detaillierten Berechtigungen migriert werden, müssen auch eine Aktivität deklarieren, um die Datenschutzerklärung der App anzuzeigen. Das ist dieselbe Anforderung wie bei Health Connect.

Wichtig :Wenn Sie keine Begründung für mobile Apps angeben, wird die Berechtigung widerrufen.

Konnektivität

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

Neue Intents für den Umgang mit Verlust der Verbindung und Änderungen bei der Verschlüsselung

As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.

Apps targeting Android 16 can now:

• Receive an ACTION_KEY_MISSING intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions.
• Receive an ACTION_ENCRYPTION_CHANGE intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receiving ACTION_ENCRYPTION_CHANGE intent later.

Adapting to varying OEM implementations

While Android 16 introduces these new intents, their implementation and broadcasting can vary across different device manufacturers (OEMs). To ensure your app provides a consistent and reliable experience across all devices, developers should design their bond loss handling to gracefully adapt to these potential variations.

We recommend the following app behaviors:

• If the ACTION_KEY_MISSING intent is broadcast:

  The ACL (Asynchronous Connection-Less) link will be disconnected by the system, but the bond information for the device will be retained (as described here).

  Your app should use this intent as the primary signal for bond loss detection and guiding the user to confirm the remote device is in range before initiating device forgetting or re-pairing.

  If a device disconnects after ACTION_KEY_MISSING is received, your app should be cautious about reconnecting, as the device may no longer be bonded with the system.

• If the ACTION_KEY_MISSING intent is NOT broadcast:

  The ACL link will remain connected, and the bond information for the device will be removed by the system, same to behavior in Android 15.

  In this scenario, your app should continue its existing bond loss handling mechanisms as in previous Android releases, to detect and manage bond loss events.

Neue Möglichkeit zum Entfernen der Bluetooth-Kopplung

Alle Apps, die auf Android 16 ausgerichtet sind, können jetzt Bluetooth-Geräte über eine öffentliche API in CompanionDeviceManager entkoppeln. Wenn ein Companion-Gerät als CDM-Verknüpfung verwaltet wird, kann die App die Entfernung der Bluetooth-Verknüpfung über die neue removeBond(int) API auf dem verknüpften Gerät auslösen. Die App kann die Änderungen des Kopplungsstatus überwachen, indem sie das Bluetooth-Geräte-Broadcast-Ereignis ACTION_BOND_STATE_CHANGED überwacht.

Sicherheit

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

Sperrung der MediaStore-Version

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

Safer Intents ist eine mehrphasige Sicherheitsinitiative, die darauf abzielt, die Sicherheit des Intent-Auflösungsmechanismus von Android zu verbessern. Ziel ist es, Apps vor schädlichen Aktionen zu schützen, indem während der Verarbeitung von Intents Prüfungen durchgeführt und Intents herausgefiltert werden, die bestimmte Kriterien nicht erfüllen.

In Android 15 lag der Fokus auf der sendenden App. In Android 16 wird die Steuerung nun auf die empfangende App verlagert. Entwickler können die strenge Intent-Auflösung über ihr App-Manifest aktivieren.

Es werden zwei wichtige Änderungen eingeführt:

1. Explizite Intents müssen mit dem Intent-Filter der Zielkomponente übereinstimmen: Wenn ein Intent explizit auf eine Komponente ausgerichtet ist, muss er mit dem Intent-Filter dieser Komponente übereinstimmen.

2. Intents ohne Aktion können keinem Intent-Filter entsprechen: Intents, für die keine Aktion angegeben ist, sollten nicht in einen Intent-Filter aufgelöst werden.

Diese Änderungen gelten nur, wenn mehrere Apps beteiligt sind, und haben keine Auswirkungen auf die Verarbeitung von Intents innerhalb einer einzelnen App.

Positiv beeinflussen

Da es sich um eine Opt-in-Funktion handelt, müssen Entwickler sie explizit in ihrem App-Manifest aktivieren, damit sie wirksam wird. Daher beschränkt sich die Wirkung der Funktion auf Apps, deren Entwickler:

• Sie kennen die Funktion „Safer Intents“ und ihre Vorteile.
• Sie entscheiden sich aktiv dafür, strengere Praktiken für die Intent-Verarbeitung in ihre Apps aufzunehmen.

Dieser Opt-in-Ansatz minimiert das Risiko, dass vorhandene Apps, die möglicherweise auf dem aktuellen, weniger sicheren Verhalten bei der Intent-Auflösung basieren, nicht mehr funktionieren.

Die anfänglichen Auswirkungen in Android 16 sind möglicherweise begrenzt, aber die Initiative „Safer Intents“ hat einen Fahrplan für umfassendere Auswirkungen in zukünftigen Android-Releases. Es ist geplant, die strikte Intenterkennung zum Standardverhalten zu machen.

Die Funktion „Safer Intents“ kann die Sicherheit des Android-Ökosystems erheblich verbessern, da sie es böswilligen Apps erschwert, Sicherheitslücken im Mechanismus zur Intent-Auflösung auszunutzen.

Die Umstellung auf die Abmeldung und die obligatorische Durchsetzung muss jedoch sorgfältig verwaltet werden, um potenzielle Kompatibilitätsprobleme mit vorhandenen Apps zu beheben.

Implementierung

Entwickler müssen das strengere Intent-Matching explizit über das Attribut intentMatchingFlags in ihrem App-Manifest aktivieren. Hier ist ein Beispiel, in dem die Funktion für die gesamte App aktiviert ist, aber auf einem Empfänger deaktiviert bzw. deaktiviert wurde:

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

Hinweis :Das Attribut kann sowohl für das <application>-Tag als auch für die Komponententags wie <activity>, <activity-alias>, <receiver>, <service> und <provider> angegeben werden. Mit dem Attribut für die Komponente kann das Attribut für das <application>-Tag überschrieben werden.

Weitere Informationen zu den unterstützten Flags:

Name des Parameters	Beschreibung
enforceIntentFilter	Erzwingt einen strengeren Abgleich für eingehende Intents
Keine	Deaktiviert alle speziellen Abgleichsregeln für eingehende Intents. Wenn Sie mehrere Flags angeben, werden widersprüchliche Werte aufgelöst, indem das Flag „none“ Vorrang erhält.
allowNullAction	Die Abgleichsregeln werden gelockert, sodass Intents ohne Aktion abgeglichen werden können. Dieses Flag muss in Verbindung mit „enforceIntentFilter“ verwendet werden, um ein bestimmtes Verhalten zu erzielen.

Testen und Fehler beheben

Wenn die Erzwingung aktiv ist, sollten Apps ordnungsgemäß funktionieren, sofern der Intent-Aufrufer den Intent richtig ausgefüllt hat. Blockierte Intents lösen jedoch Warnmeldungen wie "Intent does not match component's intent filter:" und "Access blocked:" mit dem Tag "PackageManager." aus. Dies deutet auf ein potenzielles Problem hin, das sich auf die App auswirken könnte und Aufmerksamkeit erfordert.

Logcat-Filter:

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

GPU-Syscall-Filterung

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

此更改适用于使用 Mali GPU 的 Pixel 设备（Pixel 6-9）。Arm 已在其 r54p2 版本的 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 并将其分配给 [e-mail]。

常见问题解答

1. 此政策变更是否适用于所有原始设备制造商 (OEM)？ 此变更将采用选择启用模式，但任何想要使用此强化方法的 OEM 都可以使用。如需了解如何实现此变更，请参阅实现文档。

2. 是否必须在 OEM 代码库中进行更改才能实现此功能，还是默认随新的 AOSP 版本提供？ 平台级变更将默认随新的 AOSP 版本一起发布。如果供应商想要应用此变更，可以在其代码库中选择启用此变更。

3. SoC 是否负责使 IOCTL 列表保持最新状态？例如，如果我的设备使用 ARM Mali GPU，我是否需要就任何更改与 ARM 联系？ 各个 SoC 必须在驱动程序发布后根据设备更新其 IOCTL 列表。 例如，ARM 会在驱动程序更新时更新其已发布的 IOCTL 列表。 不过，OEM 应确保在 SEPolicy 中纳入这些更新，并根据需要将任何选定的自定义 IOCTL 添加到列表中。

4. 此变更是否会自动应用于所有在售 Pixel 设备，还是需要用户执行操作来切换某些设置才能应用此变更？ 此变更适用于所有使用 Mali GPU 的 Pixel 在售设备（Pixel 6-9）。用户无需采取任何行动即可应用此变更。

5. 使用此政策会影响内核驱动程序的性能吗？ 我们使用 GFXBench 在 Mali GPU 上测试了此政策，未发现 GPU 性能有任何可衡量的变化。

6. IOCTL 列表是否需要与当前的用户空间和内核驱动程序版本保持一致？ 是的，允许的 IOCTL 列表必须与用户空间和内核驱动程序支持的 IOCTL 同步。如果用户空间或内核驱动程序中的 IOCTL 发生更新，则必须更新 SEPolicy IOCTL 列表以保持一致。

7. ARM 已将 IOCTL 分类为“受限”/“检测”，但我们希望在生产用例中使用其中一些 IOCTL，并拒绝其他 IOCTL。 各个 OEM/SoC 负责根据其用户空间 Mali 库的配置来决定如何对其使用的 IOCTL 进行分类。ARM 的列表可用于帮助确定这些值，但每个 OEM/SoC 的使用情形可能有所不同。

Datenschutz

Android 16 (API-Level 36) umfasst 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. in Bezug auf 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 des Nutzers 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 bereitgestellt, 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, die auf implizitem lokalen Netzwerkzugriff basieren, gemäß der folgenden Anleitung aktualisieren und sich auf die Ablehnung und den Widerruf der neuen Berechtigung durch Nutzer vorbereiten.

Positiv beeinflussen

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-Diensterkennungsprotokoll)
• 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
Eingehendes UDP-Unicast, ‑Multicast oder ‑Broadcast empfangen	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 Apps, 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 4. 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. AppCompat-Flag in adb umschalten:

   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 diese während der Opt-in-Phase nicht betroffen.

Wenn Sie den Zugriff wiederherstellen möchten, 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. Öffnen Sie die 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 Durchsetzung 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	Microsoft Works	Microsoft Works	Microsoft Works
Nicht gewährt	Pannen	Microsoft Works	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.

Beispiele für Fehler:

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.