Verhaltensänderungen: alle Apps

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

Die Plattform Android 16 enthält Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten für alle Apps, die auf Android 16 ausgeführt werden, unabhängig von targetSdkVersion. Sie sollten Ihre App testen und sie gegebenenfalls so ändern, dass sie diese Änderungen unterstützt.

Lesen Sie sich auch die Liste der Verhaltensänderungen durch, die sich nur auf Apps auswirken, die auf Android 16 ausgerichtet sind.

Hauptfunktion

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

JobScheduler-Kontingentoptimierungen

Ab Android 16 passen wir das Zeitkontingent für die Ausführung regelmäßiger und beschleunigter Jobs anhand der folgenden Faktoren an:

• In welchem App-Standby-Bucket sich die Anwendung befindet: In Android 16 werden aktive Standby-Buckets durch ein großzügiges Laufzeitkontingent erzwungen.
• Wenn die Ausführung des Jobs gestartet wird, während die App im Vordergrund ist: Unter Android 16 wird das Kontingent für die Joblaufzeit eingehalten, wenn Jobs gestartet werden, während die App für den Nutzer sichtbar ist, und fortgesetzt werden, nachdem die App ausgeblendet wurde.
• Wenn der Job ausgeführt wird, während ein Dienst im Vordergrund ausgeführt wird: Unter Android 16 wird das Laufzeitkontingent für Jobs eingehalten, die gleichzeitig mit einem Dienst im Vordergrund ausgeführt werden. Wenn Sie Jobs für die vom Nutzer initiierte Datenübertragung verwenden, sollten Sie stattdessen Jobs für die vom Nutzer initiierte Datenübertragung verwenden.

Diese Änderung wirkt sich auf Aufgaben aus, die mit WorkManager, JobScheduler und DownloadManager geplant wurden. Wenn Sie herausfinden möchten, warum ein Job angehalten wurde, empfehlen wir, den Grund dafür zu protokollieren. Rufen Sie dazu WorkInfo.getStopReason() auf (für JobScheduler-Jobs JobParameters.getStopReason()).

Weitere Informationen zu Best Practices für eine optimale Akkunutzung finden Sie unter Akkunutzung für APIs zur Aufgabenplanung optimieren.

Wir empfehlen außerdem, die neue JobScheduler#getPendingJobReasonsHistory API zu verwenden, die in Android 16 eingeführt wurde, um herauszufinden, warum ein Job nicht ausgeführt wurde.

Testen

Wenn Sie das Verhalten Ihrer App testen möchten, können Sie das Überschreiben bestimmter Jobkontingentoptimierungen aktivieren, solange die App auf einem Android 16-Gerät ausgeführt wird.

Wenn Sie die Erzwingung der Option „Top-Status hält sich an das Job-Laufzeitkontingent“ deaktivieren möchten, führen Sie den folgenden adb-Befehl aus:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

Wenn Sie die Erzwingung der Richtlinie „Jobs, die gleichzeitig mit einem Dienst im Vordergrund ausgeführt werden, müssen das Kontingent für die Joblaufzeit einhalten“ deaktivieren möchten, führen Sie den folgenden adb-Befehl aus:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

Wenn Sie bestimmtes Verhalten des App-Standby-Buckets testen möchten, können Sie den App-Standby-Bucket Ihrer App mit dem folgenden adb-Befehl festlegen:

adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted

Um den App-Standby-Bucket Ihrer App zu ermitteln, können Sie den folgenden adb-Befehl verwenden:

adb shell am get-standby-bucket APP_PACKAGE_NAME

Grund für das Beenden von aufgegebenen leeren Jobs

An abandoned job occurs when the JobParameters object associated with the job has been garbage collected, but JobService#jobFinished(JobParameters, boolean) has not been called to signal job completion. This indicates that the job may be running and being rescheduled without the app's awareness.

Apps that rely on JobScheduler, don't maintain a strong reference to the JobParameters object, and timeout will now be granted the new job stop reason STOP_REASON_TIMEOUT_ABANDONED, instead of STOP_REASON_TIMEOUT.

If there are frequent occurrences of the new abandoned stop reason, the system will take mitigation steps to reduce job frequency.

Apps should use the new stop reason to detect and reduce abandoned jobs.

If you're using WorkManager, AsyncTask, or DownloadManager, you aren't impacted because these APIs manage the job lifecycle on your app's behalf.

Einstellung von JobInfo#setImportantWhileForeground

Die Methode JobInfo.Builder#setImportantWhileForeground(boolean) gibt an, wie wichtig ein Job ist, wenn sich die Planungs-App im Vordergrund befindet oder vorübergehend von Einschränkungen im Hintergrund ausgenommen ist.

Diese Methode ist seit Android 12 (API-Level 31) nicht mehr unterstützt. Ab Android 16 funktioniert sie nicht mehr effektiv und der Aufruf dieser Methode wird ignoriert.

Das Entfernen der Funktion gilt auch für JobInfo#isImportantWhileForeground(). Ab Android 16 gibt die Methode bei einem Aufruf false zurück.

Prioritätsbereich für die geordnete Übertragung nicht mehr global

Android-Apps dürfen Prioritäten für Broadcastempfänger festlegen, um die Reihenfolge zu steuern, in der die Empfänger die Übertragung empfangen und verarbeiten. Für im Manifest deklarierte Empfänger können Apps das Attribut android:priority verwenden, um die Priorität zu definieren. Für im Kontext registrierte Empfänger können Apps die IntentFilter#setPriority() API verwenden, um die Priorität zu definieren. Wenn eine Übertragung gesendet wird, liefert das System sie an Empfänger in der Reihenfolge ihrer Priorität, von der höchsten zur niedrigsten.

Unter Android 16 kann die Reihenfolge der Übermittlung von Nachrichten mit dem Attribut android:priority oder IntentFilter#setPriority() in verschiedenen Prozessen nicht garantiert werden. Broadcastprioritäten werden nur innerhalb desselben Anwendungsvorgangs und nicht für alle Prozesse berücksichtigt.

Außerdem werden die Übertragungsprioritäten automatisch auf den Bereich (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY − 1) beschränkt. Nur Systemkomponenten dürfen SYSTEM_LOW_PRIORITY oder SYSTEM_HIGH_PRIORITY als Übertragungspriorität festlegen.

Ihre App ist möglicherweise betroffen, wenn sie

1. Ihre Anwendung hat mehrere Prozesse mit demselben Broadcast-Intent deklariert und erwartet, dass diese Intents in einer bestimmten Reihenfolge basierend auf der Priorität empfangen werden.
2. Ihr Anwendungsvorgang interagiert mit anderen Prozessen und erwartet, dass eine Broadcastabsicht in einer bestimmten Reihenfolge empfangen wird.

Wenn die Prozesse miteinander koordiniert werden müssen, sollten sie über andere Koordinationskanäle kommunizieren.

Interne ART-Änderungen

Android 16 enthält die neuesten Updates für die Android Runtime (ART), die die Leistung der Android Runtime (ART) verbessern und Unterstützung für zusätzliche Java-Funktionen bieten. Über Google Play-Systemupdates sind diese Verbesserungen auch für über eine Milliarde Geräte mit Android 12 (API-Level 31) und höher verfügbar.

Wenn diese Änderungen veröffentlicht werden, funktionieren Bibliotheken und App-Code, die auf internen Strukturen von ART basieren, möglicherweise nicht richtig auf Geräten mit Android 16 und früheren Android-Versionen, bei denen das ART-Modul über Google Play-Systemupdates aktualisiert wird.

Die Verwendung interner Strukturen (z. B. nicht SDK-Schnittstellen) kann immer zu Kompatibilitätsproblemen führen. Es ist jedoch besonders wichtig, Code (oder Bibliotheken mit Code) zu vermeiden, der interne ART-Strukturen nutzt, da ART-Änderungen nicht an die Plattformversion gebunden sind, auf der das Gerät ausgeführt wird, und über Google Play-Systemupdates auf über eine Milliarde Geräte angewendet werden.

Alle Entwickler sollten prüfen, ob ihre App betroffen ist, indem sie ihre Apps gründlich unter Android 16 testen. Sehen Sie sich außerdem die bekannten Probleme an, um herauszufinden, ob Ihre App von Bibliotheken abhängt, die wir als abhängig von internen ART-Strukturen identifiziert haben. Wenn Sie App-Code oder Bibliotheksabhängigkeiten haben, die betroffen sind, suchen Sie nach öffentlichen API-Alternativen und fordern Sie öffentliche APIs für neue Anwendungsfälle an, indem Sie eine Funktionsanfrage in unserem Issue Tracker erstellen.

Kompatibilitätsmodus für Seitengröße von 16 KB

Android 15 introduced support for 16 KB memory pages to optimize performance of the platform. Android 16 adds a compatibility mode, allowing some apps built for 4 KB memory pages to run on a device configured for 16 KB memory pages.

If Android detects that your app has 4 KB aligned memory pages, it automatically uses compatibility mode and display a notification dialog to the user. Setting the android:pageSizeCompat property in the AndroidManifest.xml to enable the backwards compatibility mode will prevent the display of the dialog when your app launches. For best performance, reliability, and stability, your app should still be 16 KB aligned. Check out our recent blog post on updating your apps to support 16 KB memory pages for more details.

Nutzerfreundlichkeit und System-UI

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

Einstellung von störenden Ansagen zu Bedienungshilfen

Android 16 deprecates accessibility announcements, characterized by the use of announceForAccessibility or the dispatch of TYPE_ANNOUNCEMENT accessibility events. These can create inconsistent user experiences for users of TalkBack and Android's screen reader, and alternatives better serve a broader range of user needs across a variety of Android's assistive technologies.

Examples of alternatives:

• For significant UI changes like window changes, use Activity.setTitle(CharSequence) and setAccessibilityPaneTitle(java.lang.CharSequence). In Compose, use Modifier.semantics { paneTitle = "paneTitle" }
• To inform the user of changes to critical UI, use setAccessibilityLiveRegion(int). In Compose, use Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]} . These should be used sparingly as they may generate announcements every time a View is updated.
• To notify users about errors, send an AccessibilityEvent of type AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR and set AccessibilityNodeInfo#setError(CharSequence), or use TextView#setError(CharSequence).

The reference documentation for the deprecated announceForAccessibility API includes more details about suggested alternatives.

Unterstützung der Bedienung über 3 Schaltflächen

In Android 16 wird die Navigation mit drei Schaltflächen für Apps, die ordnungsgemäß zur vorausschauenden Navigation migriert wurden, um die Unterstützung der vorausschauenden Navigation erweitert. Wenn Sie lange auf die Schaltfläche „Zurück“ drücken, wird eine intelligente „Zurück“-Geste für die Systemanimation gestartet. Sie sehen dann eine Vorschau, zu welcher Seite Sie durch Wischen nach hinten gelangen.

Dieses Verhalten gilt für alle Bereiche des Systems, die intelligente „Zurück“-Gesten unterstützen, einschließlich der Systemanimationen (Zurück zum Startbildschirm, zwischen Aufgaben und zwischen Aktivitäten wechseln).

Formfaktoren von Geräten

Android 16 (API-Level 36) enthält die folgenden Änderungen für Apps, die von Eigentümern virtueller Geräte auf Displays projiziert werden.

Überschreibungen des virtuellen Geräteeigentümers

A virtual device owner is a trusted or privileged app that creates and manages a virtual device. Virtual device owners run apps on a virtual device and then project the apps to the display of a remote device, such as a personal computer, virtual reality device, or car infotainment system. The virtual device owner is on a local device, such as a mobile phone.

Per-app overrides

On devices running Android 16 (API level 36), virtual device owners can override app settings on select virtual devices that the virtual device owners manage. For example, to improve app layout, a virtual device owner can ignore orientation, aspect ratio, and resizability restrictions when projecting apps onto an external display.

Common breaking changes

The Android 16 behavior might impact your app's UI on large screen form factors such as car displays or Chromebooks, especially layouts that were designed for small displays in portrait orientation. To learn how to make your app adaptive for all device form factors, see About adaptive layouts.

References

Companion app streaming

Sicherheit

Android 16 (API-Level 36) enthält Änderungen, die die Systemsicherheit verbessern und dazu beitragen, Apps und Nutzer vor schädlichen Apps zu schützen.

Verbesserte Sicherheit gegen Angriffe durch Weiterleitung von Intents

Android 16 provides default security against general Intent redirection attacks, with minimum compatibility and developer changes required.

We are introducing by-default security hardening solutions to Intent redirection exploits. In most cases, apps that use intents normally won't experience any compatibility issues; we've gathered metrics throughout our development process to monitor which apps might experience breakages.

Intent redirection in Android occurs when an attacker can partly or fully control the contents of an intent used to launch a new component in the context of a vulnerable app, while the victim app launches an untrusted sub-level intent in an extras field of an ("top-level") Intent. This can lead to the attacker app launching private components in the context of the victim app, triggering privileged actions, or gaining URI access to sensitive data, potentially leading to data theft and arbitrary code execution.

Opt out of Intent redirection handling

Android 16 introduces a new API that allows apps to opt out of launch security protections. This might be necessary in specific cases where the default security behavior interferes with legitimate app use cases.

For applications compiling against Android 16 (API level 36) SDK or higher

You can directly use the removeLaunchSecurityProtection() method on the Intent object.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }

For applications compiling against Android 15 (API level 35) or lower

While not recommended, you can use reflection to access the removeLaunchSecurityProtection() method.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
    val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
    removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
    // Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }

Konnektivität

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

Verbesserte Abwicklung von verlorenen Kautionen

Ab Android 16 wurde der Bluetooth-Stack aktualisiert, um die Sicherheit und Nutzerfreundlichkeit zu verbessern, wenn ein Verlust der Remote-Bindung erkannt wird. Bisher entfernte das System die Verknüpfung automatisch und startete einen neuen Kopplungsvorgang, was zu einer unbeabsichtigten erneuten Kopplung führen konnte. Wir haben in vielen Fällen festgestellt, dass Apps das Ereignis „Verlust der Bindung“ nicht einheitlich behandeln.

Um die Nutzung zu vereinheitlichen, wurde in Android 16 die Verarbeitung von Verbindungsverlusten für das System verbessert. Wenn ein zuvor gekoppeltes Bluetooth-Gerät bei der erneuten Verbindung nicht authentifiziert werden konnte, trennt das System die Verbindung, behält lokale Kopplungsinformationen bei und zeigt ein Systemdialogfeld an, in dem Nutzer über den Verbindungsverlust informiert und aufgefordert werden, eine neue Kopplung vorzunehmen.