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

Wie bei früheren Releases 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 von der targetSdkVersion Ihrer App.

Nutzererfahrung und System-UI

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

Deaktivierung der randlosen Darstellung wird entfernt

In Android 15 wurde die randlose Darstellung für Apps erzwungen, die auf Android 15 (API-Level 35) ausgerichtet sind. Sie konnten die Funktion jedoch deaktivieren, indem Sie R.attr#windowOptOutEdgeToEdgeEnforcement auf true gesetzt haben. Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, wird R.attr#windowOptOutEdgeToEdgeEnforcement eingestellt und deaktiviert. Die randlose Anzeige kann dann nicht mehr deaktiviert werden.

• 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 du deine App unter Android 16 testen möchtest, muss sie das Edge-to-Edge-Format unterstützen. Entferne alle Verwendungen von R.attr#windowOptOutEdgeToEdgeEnforcement, damit deine App auch auf einem Android 15-Gerät das Edge-to-Edge-Format unterstützt. Informationen zur Unterstützung des randlosen Designs finden Sie in den Leitfäden zu Compose und Ansichten.

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“-Geste (Zurück zum Startbildschirm, Aufgabenwechsel und Aktivitätenwechsel) 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, oder deaktivieren Sie die Funktion vorübergehend, indem Sie das Attribut android:enableOnBackInvokedCallback im Tag <application> oder <activity> der Datei AndroidManifest.xml Ihrer App auf false setzen.

Animation für die intelligente „Zurück“-Geste zum Startbildschirm

Die vorausschauende Animation für den Wechsel zwischen Aktivitäten.

Die vorausschauende Animation für den Wechsel zwischen Aufgaben.

Einstellung und Deaktivierung von Elegant Font APIs

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 Festpreis

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

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

Geräteformfaktoren

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

Adaptive Layouts

Android-Apps werden mittlerweile auf einer Vielzahl von Geräten (z. B. Smartphones, Tablets, faltbaren Geräten, Computern, Autos und Fernsehern) und in verschiedenen Fenstermodi auf großen Bildschirmen (z. B. im Splitscreen-Modus und im Desktop-Freiform-Fenster) ausgeführt. Entwickler sollten daher 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 für Ausrichtung, Größenänderung und Seitenverhältnis ignorieren

Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, gelten die Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis nicht mehr für Displays mit einer Mindestbreite von >= 600 dp. Apps füllen 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 Standardverhalten der Plattform eingeführt. Android bewegt sich auf ein Modell zu, bei dem Apps sich an verschiedene Ausrichtungen, Displaygrößen und Seitenverhältnisse anpassen sollen. Einschränkungen wie eine feste Ausrichtung oder eine eingeschränkte Größenänderung beeinträchtigen die Anpassungsfähigkeit der App. Entwickle eine adaptive App, um 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 funktionsgefährdende Änderungen

Das Ignorieren von Einschränkungen für die Ausrichtung, Größenänderung und das Seitenverhältnis kann sich auf einigen Geräten auf die Benutzeroberfläche Ihrer App auswirken, insbesondere auf Elemente, die für kleine Layouts im Hochformat entwickelt wurden. Beispielsweise können Probleme wie gestreckte Layouts und Animationen und Komponenten außerhalb des Bildschirms auftreten. Annahmen über das Seitenverhältnis oder die Ausrichtung können zu Darstellungsproblemen in deiner App führen. Weitere Informationen dazu, wie du diese Probleme vermeiden und das adaptive Verhalten deiner App verbessern kannst.

Wenn die Geräterotation zugelassen wird, wird die Aktivität häufiger neu erstellt. Das kann dazu führen, dass der Nutzerstatus verloren geht, wenn er nicht ordnungsgemäß gespeichert wird. Informationen zum korrekten Speichern des UI-Status finden Sie unter UI-Status speichern.

Details zur Implementierung

Die folgenden Manifestattribute und Laufzeit-APIs werden auf Geräten mit großen Displays 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

android:resizeableActivity="false", android:minAspectRatio und android:maxAspectRatio haben keine Auswirkungen auf die Anpassbarkeit der Displaygröße.

Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, werden Einschränkungen für die Ausrichtung, Größenänderung und das Seitenverhältnis auf großen Bildschirmen standardmäßig ignoriert. Apps, die noch nicht vollständig bereit sind, können dieses Verhalten vorübergehend deaktivieren. Sie werden dann wie bisher im Kompatibilitätsmodus ausgeführt.

Ausnahmen

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

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

Vorübergehend deaktivieren

Wenn Sie eine bestimmte Aktivität deaktivieren möchten, deklarieren Sie das Manifestattribut 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 :Die Deaktivierung ist vorübergehend und gilt nicht, wenn in einer zukünftigen Android-Version das API-Level 37 als Ziel festgelegt wird. Das bedeutet, dass bei Apps, die auf API-Level 37 ausgerichtet sind, die Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis auf Displays mit einer Größe von mindestens sw600dp ignoriert werden.

Gesundheit und Fitness

Android 16 (API-Level 36) enthält die folgenden Änderungen im Zusammenhang mit Gesundheits- und Fitnessdaten.

Berechtigungen für Gesundheits- und Fitnessdaten

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 verwendet 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 Typen von Diensten im Vordergrund:

• HEART_RATE_BPM von Gesundheitsdiensten unter Wear OS
• Sensor.TYPE_HEART_RATE von Android Sensor Manager
• heartRateAccuracy und heartRateBpm von ProtoLayout auf Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH, wobei die entsprechende android.permission.health-Berechtigung 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, Sauerstoffsättigung 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 auf die Verwendung von READ_HEART_RATE und anderen detaillierten Berechtigungen umgestellt werden, müssen außerdem eine Aktivität deklarieren, um die Datenschutzerklärung der App anzuzeigen. Diese Anforderung gilt auch für Health Connect.

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

Verbindung

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

Neue Intents zur Verarbeitung von 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, die Bluetooth-Verbindung zu entfernen

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

Die Funktion „Safer Intents“ ist eine mehrstufige Sicherheitsinitiative, die die Sicherheit des Intent-Auflösungsmechanismus von Android verbessern soll. Das Ziel besteht darin, Apps vor schädlichen Aktionen zu schützen, indem während der Intent-Verarbeitung Prüfungen hinzugefügt und Intents gefiltert werden, die bestimmte Kriterien nicht erfüllen.

In Android 15 lag der Fokus auf der sendenden App. Mit Android 16 wird die Kontrolle auf die empfangende App übertragen. Entwickler können die strikte Intent-Auflösung über ihr App-Manifest aktivieren.

Es werden zwei wichtige Änderungen vorgenommen:

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

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

Diese Änderungen gelten nur, wenn mehrere Apps beteiligt sind, und wirken sich nicht auf die Intent-Verarbeitung innerhalb einer einzelnen App aus.

Auswirkungen

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

• Sie kennen die Funktion „Sicherere Intents“ und ihre Vorteile.
• Sie müssen sich aktiv dafür entscheiden, strengere Praktiken für die Intent-Verarbeitung in ihre Apps zu integrieren.

Durch diesen Opt-in-Ansatz wird das Risiko minimiert, dass vorhandene Apps, die möglicherweise auf dem aktuellen, weniger sicheren Intent-Auflösungsverhalten basieren, nicht mehr funktionieren.

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

Die Funktion „Safer Intents“ kann die Sicherheit des Android-Ökosystems erheblich verbessern, da sie es schädlichen Apps erschwert, Sicherheitslücken im Intent-Auflösungsmechanismus auszunutzen.

Die Umstellung auf die Opt-out-Option und die obligatorische Durchsetzung muss jedoch sorgfältig geplant werden, um potenzielle Kompatibilitätsprobleme mit vorhandenen Apps zu vermeiden.

Implementierung

Entwickler müssen den strengeren Intent-Abgleich explizit aktivieren, indem sie das Attribut intentMatchingFlags in ihrem App-Manifest verwenden. Hier ist ein Beispiel, bei dem die Funktion für die gesamte App aktiviert, aber für einen Empfänger deaktiviert ist:

<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 im <application>-Tag als auch in den Komponenten-Tags wie <activity>, <activity-alias>, <receiver>, <service> und <provider> angegeben werden. Das Attribut für die Komponente kann verwendet werden, um das Attribut im <application>-Tag zu überschreiben.

Weitere Informationen zu den unterstützten Flags:

Flag-Name	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 Konflikte gelöst, indem dem Flag „none“ Vorrang gegeben wird
allowNullAction	Lockert die Abgleichsregeln, damit Intents ohne Aktion abgeglichen werden können. Dieses Flag wird in Verbindung mit „enforceIntentFilter“ verwendet, um ein bestimmtes Verhalten zu erzielen.

Testen und Fehler beheben

Wenn die Maßnahme aktiv ist, sollten Apps korrekt funktionieren, wenn der Intent-Aufrufer den Intent ordnungsgemäß 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 weist auf ein potenzielles Problem hin, das sich auf die App auswirken könnte und behoben werden muss.

Logcat-Filter:

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

GPU-Syscall-Filterung

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 die für das GPU-Profiling verwendeten IOCTLs 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 Mali-GPU (Pixel 6 bis Pixel 9). Arm hat eine offizielle Kategorisierung seiner IOCTLs in Documentation/ioctl-categories.rst der Version r54p2 bereitgestellt. Diese Liste wird in zukünftigen Treiberversionen weiterhin gepflegt.

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

Test

Wenn Sie eine SELinux-Ablehnung wie die folgende sehen, 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 deine Anwendung blockierte IOCTLs verwenden muss, melde bitte einen Fehler und weise 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 Methode zur Erhöhung der Sicherheit 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 Funktion zu implementieren, oder ist sie standardmäßig in einer neuen AOSP-Version enthalten? Die Änderung auf Plattformebene wird standardmäßig mit einem neuen AOSP-Release eingeführt. Anbieter können diese Änderung in ihrer Codebasis aktivieren, wenn sie sie anwenden möchten.

3. Sind SoC-Hersteller dafür verantwortlich, die IOCTL-Liste auf dem neuesten Stand zu halten? Wenn mein Gerät beispielsweise eine ARM Mali-GPU verwendet, müsste ich mich dann für Änderungen an ARM wenden? Die einzelnen SoC-Anbieter müssen ihre IOCTL-Listen pro Gerät bei der Treiberveröffentlichung aktualisieren. Beispielsweise aktualisiert ARM seine veröffentlichte IOCTL-Liste, wenn Treiber aktualisiert werden. OEMs sollten jedoch darauf achten, die Aktualisierungen in ihre SEPolicy zu übernehmen und bei Bedarf ausgewählte benutzerdefinierte IOCTLs zu den Listen hinzuzufügen.

4. Gilt diese Änderung automatisch für alle auf dem Markt erhältlichen Pixel-Geräte oder müssen Nutzer etwas tun, um sie zu aktivieren? Diese Änderung gilt für alle auf dem Markt befindlichen Pixel-Geräte mit Mali-GPU (Pixel 6 bis Pixel 9). Nutzer müssen nichts weiter tun, um diese Änderung zu übernehmen.

5. Wirkt sich die Verwendung dieser Richtlinie auf die Leistung des Kerneltreibers aus? Diese Richtlinie wurde auf der Mali-GPU mit GFXBench getestet und es wurde keine messbare Änderung der GPU-Leistung beobachtet.

6. Muss die IOCTL-Liste mit den aktuellen Userspace- und Kerneltreiberversionen übereinstimmen? Ja, die Liste der zulässigen IOCTLs muss mit den IOCTLs synchronisiert werden, die sowohl von den Userspace- als auch von den Kernel-Treibern unterstützt werden. Wenn die IOCTLs im Nutzerbereich oder im Kerneltreiber aktualisiert werden, muss die SEPolicy-IOCTL-Liste entsprechend aktualisiert werden.

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

Datenschutz

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

Berechtigung für das lokale Netzwerk

任何拥有 INTERNET 权限的应用都可以访问 LAN 中的设备。 这让应用可以轻松连接到本地设备，但也会带来隐私问题，例如生成用户指纹，以及推断出位置信息。

本地网络保护项目旨在通过新的运行时权限控制对本地网络的访问，从而保护用户隐私。

发布计划

此项变更将在 25Q2 和 26Q2 这两个版本之间部署。 开发者必须在 25Q2 遵循此指南并分享反馈，因为这些保护措施将在后续 Android 版本中强制执行。 此外，他们还需要根据以下指南更新依赖于隐式本地网络访问权限的场景，并为用户拒绝和撤消新权限做好准备。

影响

在当前阶段，LNP 是一项选择性启用的功能，这意味着只有选择启用该功能的应用才会受到影响。选择启用阶段的目标是让应用开发者了解其应用的哪些部分依赖于隐式本地网络访问，以便他们可以准备在下一个版本中为其设置权限保护。

如果应用使用以下方式访问用户的本地网络，则会受到影响：

• 在本地网络地址上直接或通过库使用原始套接字（例如 mDNS 或 SSDP 服务发现协议）
• 使用访问本地网络的框架级类（例如 NsdManager）

发往和来自本地网络地址的流量需要本地网络访问权限。下表列出了一些常见情况：

应用底层网络操作	需要本地网络权限
建立传出 TCP 连接	是
接受传入的 TCP 连接	是
发送 UDP 单播、多播、广播	是
接收传入的 UDP 单播、多播、广播	是

这些限制在网络栈深处实现，因此适用于所有网络 API。这包括在原生或托管代码中创建的套接字、Cronet 和 OkHttp 等网络库，以及在这些库之上实现的任何 API。尝试解析本地网络上的服务（即带有 .local 后缀的服务）需要本地网络权限。

注意： 源自需要本地网络访问权限的 Android WebView 的流量将继承宿主应用的权限状态

上述规则的例外情况：

• 如果设备的 DNS 服务器位于本地网络中，则进出该服务器（通过端口 53）的流量不需要本地网络访问权限。
• 使用输出切换器作为应用内选择器的应用不需要本地网络权限（更多指南将于 2025 年第 4 季度发布）。

注意： 许多媒体投放场景都依赖于对本地网络的访问，并且会受到此项变更的影响。不过，并非所有提供投屏功能的应用都需要请求这项新权限。25Q4 中将提供用于处理投屏场景的未来 API 和指南。

开发者指南（选择启用）

如需选择启用本地网络限制，请执行以下操作：

1. 将设备刷写到搭载 25Q2 Beta 3 或更高版本的 build。
2. 安装要测试的应用。

3. 在 adb 中切换 Appcompat 标志：

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. 重启设备

现在，您的应用对本地网络的访问权限受到限制，任何访问本地网络的尝试都会导致套接字错误。如果您使用的 API 在应用进程之外执行本地网络操作（例如 NsdManager），则在选择启用阶段不会受到影响。

如需恢复访问权限，您必须向应用授予NEARBY_WIFI_DEVICES权限。

1. 确保应用在其清单中声明 NEARBY_WIFI_DEVICES 权限。
2. 依次前往设置 > 应用 > [应用名称] > 权限 > 附近的设备 > 允许。

注意： 在未来的 Android 版本中，此功能将由“附近的设备”权限组中的新权限进行保护

现在，您的应用对本地网络的访问权限应该已恢复，并且所有场景都应该像选择启用该应用之前一样正常运行。

本地网络保护强制执行后，应用网络流量将受到以下影响。

权限	出站 LAN 请求	出站/入站互联网请求	入站 LAN 请求
已授予	Works	Works	Works
未授予	最差排行榜	Works	最差排行榜

使用以下命令关闭应用兼容性标志

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

错误

每当调用套接字调用 send 或 send 变体到本地网络地址时，这些限制引起的错误都会返回给调用套接字。

错误示例：

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

本地网络定义

此项目中的本地网络是指利用支持广播的网络接口（例如 Wi-Fi 或以太网）的 IP 网络，但不包括移动网络 (WWAN) 或 VPN 连接。

以下网络被视为本地网络：

IPv4：

• 169.254.0.0/16 // 链路本地
• 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：

• 链路本地
• 直接连接的路由
• 桩网络（例如 Thread）
• 多个子网（待定）

此外，多播地址（224.0.0.0/4、ff00::/8）和 IPv4 广播地址 (255.255.255.255) 也被归类为本地网络地址。

Fotos, die zu einer App gehören

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.