Diese Seite wurde von der Cloud Translation API übersetzt.

Verhaltensänderungen: alle Apps

Die Android 16-Plattform umfasst Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten für alle Apps, wenn sie unter Android 16 ausgeführt werden, unabhängig von targetSdkVersion. Sie sollten Ihre App testen und sie bei Bedarf anpassen, um diese Änderungen zu unterstützen.

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

Hauptfunktion

Android 16 (API-Level 36) umfasst die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems modifizieren oder erweitern.

JobScheduler-Kontingentoptimierungen

Starting in Android 16, we're adjusting regular and expedited job execution runtime quota based on the following factors:

Which app standby bucket the application is in: in Android 16, active standby buckets will start being enforced by a generous runtime quota.
If the job starts execution while the app is in a top state: in Android 16, Jobs started while the app is visible to the user and continues after the app becomes invisible, will adhere to the job runtime quota.
If the job is executing while running a Foreground Service: in Android 16, jobs that are executing concurrently with a foreground service will adhere to the job runtime quota. If you're leveraging jobs for user initiated data transfer, consider using user initiated data transfer jobs instead.

This change impacts tasks scheduled using WorkManager, JobScheduler, and DownloadManager. To debug why a job was stopped, we recommend logging why your job was stopped by calling WorkInfo.getStopReason() (for JobScheduler jobs, call JobParameters.getStopReason()).

For information about how your app's state affects the resources it can use, see Power management resource limits. For more information on battery-optimal best practices, refer to guidance on optimize battery use for task scheduling APIs.

We also recommend leveraging the new JobScheduler#getPendingJobReasonsHistory API introduced in Android 16 to understand why a job has not executed.

Testing

To test your app's behavior, you can enable override of certain job quota optimizations as long as the app is running on an Android 16 device.

To disable enforcement of "top state will adhere to job runtime quota", run the following adb command:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

To disable enforcement of "jobs that are executing while concurrently with a foreground service will adhere to the job runtime quota", run the following adb command:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

To test certain app standby bucket behavior, you can set the app standby bucket of your app using the following adb command:

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

To understand the app standby bucket your app is in, you can get the app standby bucket of your app using the following adb command:

adb shell am get-standby-bucket APP_PACKAGE_NAME

Grund für das Beenden leerer 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.

Vollständige Einstellung von JobInfo#setImportantWhileForeground

The JobInfo.Builder#setImportantWhileForeground(boolean) method indicates the importance of a job while the scheduling app is in the foreground or when temporarily exempted from background restrictions.

This method has been deprecated since Android 12 (API level 31). Starting in Android 16, it no longer functions effectively and calling this method will be ignored.

This removal of functionality also applies to JobInfo#isImportantWhileForeground(). Starting in Android 16, if the method is called, the method returns false.

Bereich der Priorität für geordnete Broadcasts nicht mehr global

Android apps are allowed to define priorities on broadcast receivers to control the order in which the receivers receive and process the broadcast. For manifest-declared receivers, apps can use the android:priority attribute to define the priority and for context-registered receivers, apps can use the IntentFilter#setPriority() API to define the priority. When a broadcast is sent, the system delivers it to receivers in order of their priority, from highest to lowest.

In Android 16, broadcast delivery order using the android:priority attribute or IntentFilter#setPriority() across different processes will not be guaranteed. Broadcast priorities will only be respected within the same application process rather than across all processes.

Also, broadcast priorities will be automatically confined to the range (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1). Only system components will be allowed to set SYSTEM_LOW_PRIORITY, SYSTEM_HIGH_PRIORITY as broadcast priority.

Your app might be impacted if it does either of the following:

Your application has declared multiple processes with the same broadcast intent, and has expectations around receiving those intents in a certain order based on the priority.
Your application process interacts with other processes and has expectations around receiving a broadcast intent in a certain order.

If the processes need to coordinate with each other, they should communicate using other coordination channels.

Interne Änderungen an ART

Android 16 includes the latest updates to the Android Runtime (ART) that improve the Android Runtime's (ART's) performance and provide support for additional Java features. Through Google Play System updates, these improvements are also available to over a billion devices running Android 12 (API level 31) and higher.

As these changes are released, libraries and app code that rely on internal structures of ART might not work correctly on devices running Android 16, along with earlier Android versions that update the ART module through Google Play system updates.

Relying on internal structures (such as non-SDK interfaces) can always lead to compatibility problems, but it's particularly important to avoid relying on code (or libraries containing code) that leverages internal ART structures, since ART changes aren't tied to the platform version the device is running on and they go out to over a billion devices through Google Play system updates.

All developers should check whether their app is impacted by testing their apps thoroughly on Android 16. In addition, check the known issues to see if your app depends on any libraries that we've identified that rely on internal ART structures. If you do have app code or library dependencies that are affected, seek public API alternatives whenever possible and request public APIs for new use cases by creating a feature request in our issue tracker.

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

Mit Android 15 wurde die Unterstützung von 16‑KB-Speicherseiten eingeführt, um die Leistung der Plattform zu optimieren. Android 16 bietet einen Kompatibilitätsmodus, mit dem einige Apps, die für Arbeitsspeicherseiten mit 4 KB entwickelt wurden, auf einem Gerät ausgeführt werden können, das für Arbeitsspeicherseiten mit 16 KB konfiguriert ist.

Wenn Ihre App auf einem Gerät mit Android 16 oder höher ausgeführt wird und Android erkennt, dass Ihre App 4‑KB-ausgerichtete Arbeitsspeicherseiten hat, wird automatisch der Kompatibilitätsmodus verwendet und dem Nutzer ein Benachrichtigungsdialogfeld angezeigt. Wenn Sie die android:pageSizeCompat-Eigenschaft in der AndroidManifest.xml so festlegen, dass der Abwärtskompatibilitätsmodus aktiviert wird, wird das Dialogfeld beim Starten Ihrer App nicht angezeigt. Wenn Sie das Attribut android:pageSizeCompat verwenden möchten, kompilieren Sie Ihre App mit dem Android 16 SDK.

Für eine optimale Leistung, Zuverlässigkeit und Stabilität sollte Ihre App weiterhin auf 16 KB ausgerichtet sein. Weitere Informationen finden Sie in unserem aktuellen Blogpost zum Aktualisieren Ihrer Apps, damit sie Speicherseiten mit 16 KB unterstützen.

Das Dialogfeld für den Kompatibilitätsmodus, das angezeigt wird, wenn das System erkennt, dass eine App mit 4‑KB-Ausrichtung bei einer 16‑KB-Ausrichtung optimaler ausgeführt werden könnte.

Nutzerfreundlichkeit und System-UI

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

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

Die Animationen für intelligente „Zurück“-Touch-Geste im Modus mit 3 Schaltflächen

Automatische Designs für App-Symbole

Ab Android 16 QPR2 werden App-Symbole automatisch mit Designs versehen, um einen einheitlichen Startbildschirm zu schaffen. Das passiert, wenn eine App kein eigenes thematisiertes App-Symbol bereitstellt. Apps können das Design ihres thematischen App-Symbols steuern, indem sie eine monochrome Ebene in ihr adaptives Symbol einfügen und in Android Studio eine Vorschau des App-Symbols anzeigen lassen.

Formfaktoren von Geräten

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

Überschreibungen durch den Inhaber des virtuellen Geräts

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.

Virtual device owner on phone creates virtual device that projects app to remote display.

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.

Verbesserter Schutz vor Angriffen durch Intent-Umleitung

Android 16 bietet Standardsicherheit gegen allgemeine Intent-Umleitungsangriffe. Es sind nur minimale Kompatibilitäts- und Entwickleränderungen erforderlich.

Wir führen standardmäßig Sicherheitslösungen ein, um Intent-Weiterleitungsmanipulationen zu verhindern. In den meisten Fällen treten bei Apps, die Intents verwenden, keine Kompatibilitätsprobleme auf. Wir haben während des gesamten Entwicklungsprozesses Messwerte erfasst, um zu beobachten, bei welchen Apps es zu Problemen kommen könnte.

Intent-Umleitung in Android tritt auf, wenn ein Angreifer den Inhalt eines Intents, der zum Starten einer neuen Komponente im Kontext einer anfälligen App verwendet wird, teilweise oder vollständig kontrollieren kann, während die Opfer-App einen nicht vertrauenswürdigen Intent auf untergeordneter Ebene in einem Extras-Feld eines Intents auf oberster Ebene startet. Dies kann dazu führen, dass die Angreifer-App private Komponenten im Kontext der Opfer-App startet, privilegierte Aktionen auslöst oder URI-Zugriff auf vertrauliche Daten erhält, was möglicherweise zu Datendiebstahl und der Ausführung von beliebigem Code führt.

Verarbeitung von Intent-Weiterleitungen deaktivieren

In Android 16 wird eine neue API eingeführt, mit der Apps die Sicherheitsvorkehrungen beim Start deaktivieren können. Dies kann in bestimmten Fällen erforderlich sein, in denen das standardmäßige Sicherheitsverhalten mit legitimen Anwendungsfällen der App in Konflikt gerät.

Für Anwendungen, die mit dem Android 16 (API‑Level 36) SDK oder höher kompiliert werden

Sie können die Methode removeLaunchSecurityProtection() direkt für das Intent-Objekt verwenden.

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

Für Anwendungen, die für Android 15 (API‑Level 35) oder niedriger kompiliert werden

Obwohl dies nicht empfohlen wird, können Sie die Reflektion verwenden, um auf die Methode removeLaunchSecurityProtection() zuzugreifen.

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

Companion-Apps werden nicht mehr über Discovery-Timeouts benachrichtigt

Android 16 introduces a new behavior during companion device pairing flow to protect the user's location privacy from malicious apps. All companion apps running on Android 16 are no longer directly notified of discovery timeout using RESULT_DISCOVERY_TIMEOUT. Instead, the user is notified of timeout events with a visual dialog. When the user dismisses the dialog, the app is alerted of the association failure with RESULT_USER_REJECTED.

The search duration has also been extended from the original 20 seconds, and the device discovery can be stopped by the user at any point during the search. If at least one device was discovered within the first 20 seconds of starting the search, the CDM stops searching for additional devices.

Konnektivität

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

Verbesserte Behandlung von Anleiheverlusten

Starting in Android 16, the Bluetooth stack has been updated to improve security and user experience when a remote bond loss is detected. Previously, the system would automatically remove the bond and initiate a new pairing process, which could lead to unintentional re-pairing. We have seen in many instances apps not taking care of the bond loss event in a consistent way.

To unify the experience, Android 16 improved the bond loss handling to the system. If a previously bonded Bluetooth device could not be authenticated upon reconnection, the system will disconnect the link, retain local bond information, and display a system dialog informing users of the bond loss and directing them to re-pair.