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.

Nutzerfreundlichkeit 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 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

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.

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.

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

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.

Formfaktoren von Geräten

Android 16 (API-Level 36) enthält die folgenden Änderungen für Apps, die auf Geräten mit großen Bildschirmen 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 für Ausrichtung, Größenänderung und Seitenverhältnis ignorieren

Für Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, enthält Android 16 Änderungen daran, 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.

Diese Änderung führt zu einem neuen Standardverhalten der Plattform. 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 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 in 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. Das kann dazu führen, dass der Nutzerstatus verloren geht, 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 wiederhergestellt, bei dem die App in den Kompatibilitätsmodus versetzt wird.

Ausnahmen

Die Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis unter 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>

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, sollten die entsprechenden detaillierten Berechtigungen angefordert werden:

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

Bei mobilen Apps, die zur Verwendung von READ_HEART_RATE und anderen detaillierten Berechtigungen migriert werden, muss auch eine Aktivität deklariert werden, um die Datenschutzerklärung der App anzuzeigen. Das ist dieselbe Anforderung wie bei Health Connect.

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 Bindung und Änderungen an 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

All apps targeting Android 16 are now able to unpair bluetooth devices using a public API in CompanionDeviceManager. If a companion device is being managed as a CDM association, then the app can trigger bluetooth bond removal by using the new removeBond(int) API on the associated device. The app can monitor the bond state changes by listening to the bluetooth device broadcast event ACTION_BOND_STATE_CHANGED.

Sicherheit

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

Sperrung der MediaStore-Version

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this API.

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. Mit Android 16 wird die Steuerung nun auf die empfangende App verlagert. Entwickler können sich über ihr App-Manifest für eine strenge Intent-Auflösung entscheiden.

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 Methoden für die Intent-Verarbeitung in ihre Apps zu integrieren.

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 „Sichere 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 erfolgen, um potenzielle Kompatibilitätsprobleme mit bestehenden Apps zu vermeiden.

Implementierung

Entwickler müssen die strengere Intent-Abstimmung 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 wird:

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

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. Das deutet auf ein potenzielles Problem hin, das sich auf die App auswirken könnte und das behoben werden muss.

Logcat-Filter:

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

Datenschutz

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

Berechtigung für das lokale Netzwerk

Devices on the LAN can be accessed by any app that has the INTERNET permission. This makes it easy for apps to connect to local devices but it also has privacy implications such as forming a fingerprint of the user, and being a proxy for location.

The Local Network Protections project aims to protect the user's privacy by gating access to the local network behind a new runtime permission.

Release plan

This change will be deployed between two releases, 25Q2 and TBD respectively. It is imperative that developers follow this guidance for 25Q2 and share feedback because these protections will be enforced at a later Android release. Moreover, they will need to update scenarios which depend on implicit local network access by using the following guidance and prepare for user rejection and revocation of the new permission.

Impact

At the current stage, LNP is an opt-in feature which means only the apps that opt in will be affected. The goal of the opt-in phase is for app developers to understand which parts of their app depend on implicit local network access such that they can prepare to permission guard them for the next release.

Apps will be affected if they access the user's local network using:

• Direct or library use of raw sockets on local network addresses (e.g. mDNS or SSDP service discovery protocol)
• Use of framework level classes that access the local network (e.g. NsdManager)

Traffic to and from a local network address requires local network access permission. The following table lists some common cases:

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in native or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network (i.e. those with a .local suffix) will require local network permission.

Exceptions to the rules above:

• If a device's DNS server is on a local network, traffic to or from it (at port 53) doesn't require local network access permission.
• Applications using Output Switcher as their in-app picker won't need local network permissions (more guidance to come in 2025Q4).

Developer Guidance (Opt-in)

To opt into local network restrictions, do the following:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reboot The device

Now your app's access to the local network is restricted and any attempt to access the local network will lead to socket errors. If you are using APIs that perform local network operations outside of your app process (ex: NsdManager), they won't be impacted during the opt-in phase.

To restore access, you must grant your app permission to NEARBY_WIFI_DEVICES.

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. Go to Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow.

Now your app's access to the local network should be restored and all your scenarios should work as they did prior to opting the app in.

Once enforcement for local network protection begins, here is how the app network traffic will be impacted.

Use the following command to toggle-off the App-Compat flag

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errors

Errors arising from these restrictions will be returned to the calling socket whenever it invokes send or a send variant to a local network address.

Example errors:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Local Network Definition

A local network in this project refers to an IP network that utilizes a broadcast-capable network interface, such as Wi-Fi or Ethernet, but excludes cellular (WWAN) or VPN connections.

The following are considered local networks:

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
• Directly-connected routes
• Stub networks like Thread
• Multiple-subnets (TBD)

Additionally, both multicast addresses (224.0.0.0/4, ff00::/8) and the IPv4 broadcast address (255.255.255.255) are classified as local network addresses.

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.