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

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 ändern, dass sie diese Verhaltensweisen unterstützt.

Lesen Sie sich auch die Liste der Verhaltensänderungen durch, die sich auf alle Apps auswirken, die unter Android 16 ausgeführt werden, unabhängig von der targetSdkVersion Ihrer App.

Nutzerfreundlichkeit und System-UI

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

Deaktivierung von „Edge to Edge“ wird eingestellt

Unter Android 15 ist der Vollbildmodus für Apps, die auf Android 15 (API-Level 35) ausgerichtet sind, standardmäßig aktiviert. Sie können ihn für Ihre App jedoch deaktivieren, indem Sie R.attr#windowOptOutEdgeToEdgeEnforcement auf true festlegen. Für Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, ist R.attr#windowOptOutEdgeToEdgeEnforcement nicht mehr unterstützt und deaktiviert. Die randlose Anzeige kann für Ihre App nicht 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.

Für den Test in Android 16 Beta 3 muss Ihre App randlose Displays unterstützen. Entfernen Sie alle Verwendungen von R.attr#windowOptOutEdgeToEdgeEnforcement, damit Ihre App auch auf einem Android 15-Gerät randlos angezeigt wird. Informationen zur Unterstützung von Vollbildinhalten finden Sie in den Anleitungen Kompositionen erstellen und Ansichten.

Migration oder Deaktivierung für die Prognosefunktion 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 vorausschauenden Rückwärts-Systemanimationen (Zurück zum Startbildschirm, zwischen Aufgaben und zwischen Aktivitäten) standardmäßig aktiviert. Außerdem wird onBackPressed nicht mehr aufgerufen und KeyEvent.KEYCODE_BACK wird nicht mehr gesendet.

Wenn Ihre App das Zurück-Ereignis abfängt und Sie noch nicht zur vorausschauenden Navigation migriert sind, aktualisieren Sie Ihre App, damit sie unterstützte APIs für die Zurücknavigation verwendet. Sie können die Funktion auch vorübergehend deaktivieren, indem Sie das Attribut android:enableOnBackInvokedCallback im <application>- oder <activity>-Tag der AndroidManifest.xml-Datei Ihrer App auf false festlegen.

Elegant-Schrift-APIs werden eingestellt und deaktiviert

Apps targeting Android 15 (API level 35) have the elegantTextHeight TextView attribute set to true by default, replacing the compact font with one that is much more readable. You could override this by setting the elegantTextHeight attribute to false.

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

Hauptfunktion

Android 16 (API-Level 36) enthält die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems ändern oder erweitern.

Optimierung der Planung von Aufträgen mit fester Rate

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

Da Android-Apps jetzt auf einer Vielzahl von Geräten (z. B. Smartphones, Tablets, faltbare Geräte, Computer, Autos und Fernseher) und in Fenstermodi auf großen Bildschirmen (z. B. Splitscreen und Desktopfenster) ausgeführt werden, sollten Entwickler 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 vielen 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, gibt es Änderungen an der Verwaltung von Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis. Auf Displays mit einer Mindestbreite von mindestens 600 dp gelten diese Einschränkungen nicht mehr. Apps füllen außerdem unabhängig vom Seitenverhältnis oder der bevorzugten Ausrichtung des Nutzers das gesamte Displayfenster aus. Pillarboxing wird nicht verwendet.

Durch diese Änderung wird ein neues Standardverhalten der Plattform eingeführt. Android strebt ein Modell an, bei dem sich Apps an verschiedene Ausrichtungen, Displaygrößen und Seitenverhältnisse anpassen sollen. Einschränkungen wie eine feste Ausrichtung oder eine eingeschränkte Größe beeinträchtigen die Anpassungsfähigkeit der App. Wir empfehlen Ihnen daher, Ihre App adaptiv zu gestalten, um die bestmögliche Nutzererfahrung zu bieten.

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

Häufige funktionsgefährdende Änderungen

Wenn Sie die Einschränkungen für Ausrichtung, Größe 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 in Hochformat entwickelt wurden. Dies kann zu Problemen wie gestreckten Layouts und nicht sichtbaren Animationen und Komponenten führen. Annahmen hinsichtlich des Seitenverhältnisses oder der Ausrichtung können zu visuellen Problemen mit Ihrer App führen. Weitere Informationen dazu, wie Sie diese vermeiden und das adaptive Verhalten Ihrer App verbessern können.

Wenn die Gerätedrehung zulässig ist, werden Aktivitäten häufiger neu erstellt. Wenn der Nutzerstatus nicht richtig beibehalten wird, kann dies zu einem Verlust des Nutzerstatus führen. Informationen zum korrekten Speichern des UI-Status

Implementierungsdetails

Die folgenden Manifestattribute und Laufzeit-APIs werden auf Geräten mit großem Bildschirm im Vollbild- und im Multifenstermodus ignoriert:

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

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

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

Auf die Größe des Displays haben android:resizeableActivity="false", android:minAspectRatio und android:maxAspectRatio keine Auswirkungen.

Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, werden die Einschränkungen für App-Ausrichtung, Größe und Seitenverhältnis auf großen Bildschirmen standardmäßig ignoriert. Jede App, die noch nicht vollständig bereit ist, kann dieses Verhalten vorübergehend aufheben, indem sie die Funktion deaktiviert. Dies führt dazu, dass die App wie bisher in den Kompatibilitätsmodus versetzt wird.

Ausnahmen

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

• Spiele (basierend auf dem Flaggensymbol android:appCategory)
• Wenn Nutzer das Standardverhalten der App in den Seitenverhältniseinstellungen 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 Manifesteigenschaft 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 Gesundheit und Fitness

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions are transitioning to the granular permissions under android.permissions.health also used by Health Connect. Any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND now requires the corresponding android.permissions.health permission. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Wear Health Services
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from Wear ProtoLayout
• FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should now request the respective granular permissions:

• For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature: request the granular permission under android.permissions.health, such as READ_HEART_RATE instead of BODY_SENSORS.
• For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_SENSORS_BACKGROUND.

These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.

Mobile apps

Mobile apps migrating to use the READ_HEART_RATE and other granular permissions must also declare an activity to display the app's privacy policy. This is the same requirement as 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 zum Umgang mit verlorenen Geräten und Verschlüsselungsänderungen

Im Rahmen der verbesserten Verarbeitung von Verbindungsunterbrechungen werden in Android 16 außerdem zwei neue Intents eingeführt, um Apps besser über Verbindungsunterbrechungen 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-Verbindung 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 dem Empfang der ACTION_ENCRYPTION_CHANGE-Intent erfolgreich verschlüsselt wurde.

Wenn in Ihrer App derzeit benutzerdefinierte Mechanismen für die Verarbeitung von Verbindungsverlusten verwendet werden, migrieren Sie zur neuen Intent-Aktion ACTION_KEY_MISSING, um Verbindungsverluste zu erkennen und zu verwalten. Wir empfehlen, dass Ihre App den Nutzer auffordert, zu bestätigen, dass sich das Remote-Gerät in Reichweite befindet, bevor das Gerät vergessen und neu gekoppelt wird.

Wenn die Verbindung zu einem Gerät nach Erhalt der ACTION_KEY_MISSING-Intent getrennt wird, sollte Ihre App vorsichtig sein, bevor sie eine neue Verbindung zum Gerät herstellt, da dieses Gerät möglicherweise nicht mehr mit dem System verbunden ist.

Neue Möglichkeit zum Entfernen der Bluetooth-Verbindung

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.

MediaStore-Version gesperrt

Bei Apps, die auf Android 16 oder höher ausgerichtet sind, ist MediaStore#getVersion() jetzt für jede App eindeutig. Dadurch werden identifizierende Eigenschaften aus dem Versionsstring entfernt, um Missbrauch und Verwendung für Fingerprinting-Techniken zu verhindern. Apps dürfen keine Annahmen über das Format dieser Version treffen. Apps sollten Versionsänderungen bereits bei der Verwendung dieser API verarbeiten und in den meisten Fällen sollte ihr aktuelles Verhalten nicht geändert werden müssen, es sei denn, der Entwickler hat versucht, zusätzliche Informationen abzuleiten, die über den beabsichtigten Umfang dieser API hinausgehen.

Sicherere Intents

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

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

More on the supported flags:

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

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

Datenschutz

Android 16 (API-Level 36) enthält die folgenden Änderungen im Hinblick 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.

Von der App erstellte Fotos

When prompted for photo and video permissions by an app targeting SDK 36 or higher on devices running Android 16 or higher, users who choose to limit access to selected media will see any photos owned by the app pre-selected in the photo picker. Users can deselect any of these pre-selected items, which will revoke the app's access to those photos and videos.