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.

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.

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

Vor der Ausrichtung auf Android 16 wurde bei scheduleAtFixedRate eine Aufgabenausführung verpasst, wenn sich die App nicht in einem gültigen Prozesslebenszyklus befand. In diesem Fall wurden alle verpassten Ausführungen sofort ausgeführt, sobald die App zu einem gültigen Lebenszyklus zurückkehrte.

Wenn Sie Ihre App auf Android 16 ausrichten, wird bei einer verpassten Ausführung von scheduleAtFixedRate höchstens eine Ausführung sofort ausgeführt, wenn die App zu einem gültigen Lebenszyklus zurückkehrt. Durch diese Verhaltensänderung soll sich die App-Leistung verbessern. Testen Sie dieses Verhalten in Ihrer App, um festzustellen, ob sie davon betroffen ist. Sie können auch das App-Kompatibilitäts-Framework verwenden und das STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS-Kompatibilitätsflag aktivieren.

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>

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.

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

Im Rahmen der Verbesserten Verarbeitung von Verbindungsverlusten werden in Android 16 außerdem zwei neue Intents eingeführt, um Apps besser über Verbindungsverluste und Verschlüsselungsänderungen zu informieren.

Für Apps, die auf Android 16 ausgerichtet sind, ist jetzt Folgendes möglich:

• Sie erhalten eine ACTION_KEY_MISSING-Intent, wenn ein Verlust der Remote-Bindung erkannt wird. So können Sie Nutzern informativeres Feedback geben und entsprechende Maßnahmen ergreifen.
• Sie erhalten eine ACTION_ENCRYPTION_CHANGE-Intent, wenn sich der Verschlüsselungsstatus des Links ändert. Dazu gehören Änderungen des Verschlüsselungsstatus, des Verschlüsselungsalgorithmus und der Größe des Verschlüsselungsschlüssels. Apps müssen davon ausgehen, dass die Verknüpfung wiederhergestellt wurde, wenn die Verknüpfung nach Erhalt der ACTION_ENCRYPTION_CHANGE-Intent erfolgreich verschlüsselt wurde.

Anpassung an unterschiedliche OEM-Implementierungen

Diese neuen Intents werden in Android 16 eingeführt, ihre Implementierung und Übertragung kann jedoch je nach Gerätehersteller (OEM) variieren. Damit Ihre App auf allen Geräten einheitlich und zuverlässig funktioniert, sollten Entwickler die Verarbeitung von Verbindungsverlusten so gestalten, dass sie sich an diese potenziellen Abweichungen anpasst.

Wir empfehlen folgende App-Verhaltensweisen:

• Wenn die ACTION_KEY_MISSING-Intent gesendet wird:

  Die ACL-Verbindung (Asynchronous Connectionless) wird vom System getrennt, die Informationen zur Bindung für das Gerät bleiben jedoch erhalten (wie hier beschrieben).

  Ihre App sollte diese Intent als primäres Signal für die Erkennung von Verbindungsverlusten verwenden und den Nutzer auffordern, zu bestätigen, dass sich das Remotegerät in Reichweite befindet, bevor das Gerät vergessen oder neu gekoppelt wird.

  Wenn die Verbindung eines Geräts nach dem Empfang von ACTION_KEY_MISSING getrennt wird, sollte deine App vorsichtig sein, bevor sie eine neue Verbindung herstellt, da das Gerät möglicherweise nicht mehr mit dem System verbunden ist.

• Wenn die ACTION_KEY_MISSING-Intent NICHT gesendet wird:

  Die ACL-Verbindung bleibt bestehen und die Informationen zur Kopplung des Geräts werden vom System entfernt, genau wie bei Android 15.

  In diesem Fall sollte Ihre App die vorhandenen Mechanismen zur Verarbeitung von Verbindungsverlusten wie in früheren Android-Releases fortsetzen, um Verbindungsverluste zu erkennen und zu verwalten.

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>

Weitere Informationen zu den unterstützten Flags:

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 android-partner-security@google.com 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

Auf Geräte im LAN kann jede App zugreifen, die die Berechtigung INTERNET hat. Dadurch können Apps ganz einfach eine Verbindung zu lokalen Geräten herstellen. Das hat aber auch Auswirkungen auf den Datenschutz, z. B. die Erstellung eines Fingerabdrucks des Nutzers und die Verwendung als Proxy für den Standort.

Das Projekt „Schutzmaßnahmen für lokale Netzwerke“ soll die Privatsphäre der Nutzer schützen, indem der Zugriff auf das lokale Netzwerk an eine neue Laufzeitberechtigung geknüpft wird.

Release-Plan

Diese Änderung wird zwischen zwei Releases bereitgestellt, 25Q2 und 26Q2. Entwickler müssen diese Anleitung für 25Q2 befolgen und Feedback geben, da diese Schutzmaßnahmen in einem späteren Android-Release erzwungen werden. Außerdem müssen sie Szenarien, die auf impliziten Zugriff auf das lokale Netzwerk angewiesen sind, gemäß der folgenden Anleitung aktualisieren und sich darauf vorbereiten, dass Nutzer die neue Berechtigung ablehnen und widerrufen.

Auswirkungen

Derzeit ist LNP eine Opt-in-Funktion. Das bedeutet, dass nur die Apps betroffen sind, für die die Funktion aktiviert wurde. Das Ziel der Opt-in-Phase ist, dass App-Entwickler verstehen, welche Teile ihrer App vom impliziten Zugriff auf das lokale Netzwerk abhängen, damit sie sich darauf vorbereiten können, sie für die nächste Version mit Berechtigungen zu schützen.

Apps sind betroffen, wenn sie über Folgendes 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 Zugriffsberechtigung für das lokale Netzwerk erforderlich. In der folgenden Tabelle sind einige gängige Fälle aufgeführt:

Diese Einschränkungen sind tief im Netzwerkstack 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 implementiert sind. Für den Versuch, Dienste im lokalen Netzwerk aufzulösen (also 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 Server (über Port 53) keine Berechtigung für den Zugriff auf das lokale Netzwerk erforderlich.
• Anwendungen, die die Ausgabeauswahl als In-App-Auswahl verwenden, benötigen keine Berechtigungen für das lokale Netzwerk. Weitere Informationen dazu folgen im 4. Quartal 2025.

Entwicklerhinweise (Opt-in)

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

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

3. Aktivieren 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 du APIs verwendest, die lokale Netzwerkvorgänge außerhalb deines 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. Gehe zu Einstellungen > Apps > [App-Name] > Berechtigungen > Geräte in der Nähe > Zulassen.

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

Sobald die Schutzmaßnahmen für lokale Netzwerke erzwungen werden, wirkt sich das auf den Netzwerkverkehr der App aus.

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 sich aus diesen Einschränkungen ergeben, werden an den aufrufenden Socket zurückgegeben, wenn er „send“ oder eine „send“-Variante an 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 broadcastfähige Netzwerkschnittstelle wie WLAN oder Ethernet verwendet, jedoch keine Mobilfunk- (WWAN) oder VPN-Verbindungen.

Folgende 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
• Stub-Netzwerke 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.

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.