Verhaltensänderungen: alle Apps

Die Android 16-Plattform enthält Verhaltensänderungen, die sich auf deine 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. Du solltest deine App testen und sie dann gegebenenfalls an diese Änderungen anpassen.

Sieh dir 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) enthält die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems ändern oder erweitern.

Kontingentoptimierungen für JobScheduler

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 Abbrechen leerer Jobs

Ein abgebrochener Job tritt auf, wenn das mit dem Job verknüpfte JobParameters-Objekt durch den Garbage Collector gelöscht wurde, JobService#jobFinished(JobParameters, boolean) aber nicht aufgerufen wurde, um den Jobabschluss zu signalisieren. Dies bedeutet, dass der Job möglicherweise ausgeführt und ohne Wissen der App neu geplant wird.

Apps, die auf JobScheduler angewiesen sind, pflegen keine starke Referenz zum JobParameters-Objekt. Bei Zeitüberschreitungen wird jetzt der neue Jobstoppgrund STOP_REASON_TIMEOUT_ABANDONED statt STOP_REASON_TIMEOUT zugewiesen.

Wenn der neue Grund für die Fahrtbeendigung häufig auftritt, ergreift das System Maßnahmen zur Behebung des Problems, um die Häufigkeit der Jobs zu reduzieren.

Apps sollten den neuen Grund für das Beenden verwenden, um abgebrochene Jobs zu erkennen und zu reduzieren.

Wenn Sie WorkManager, AsyncTask oder DownloadManager verwenden, sind Sie nicht betroffen, da diese APIs den Job-Lebenszyklus im Namen Ihrer App verwalten.

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.

Der Prioritätsbereich für geordnete Broadcasts ist 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 包含 Android 运行时 (ART) 的最新更新，这些更新可提升 Android 运行时 (ART) 的性能，并支持更多 Java 功能。通过 Google Play 系统更新，搭载 Android 12（API 级别 31）及更高版本的 10 亿多部设备也将受益于这些改进。

发布这些变更后，依赖于 ART 内部结构的库和应用代码在搭载 Android 16 的设备以及通过 Google Play 系统更新来更新 ART 模块的较低 Android 版本上可能无法正常运行。

依赖于内部结构（例如非 SDK 接口）始终会导致兼容性问题，但避免依赖于利用内部 ART 结构的代码（或包含代码的库）尤为重要，因为 ART 更改与设备所运行的平台版本无关，并且会通过 Google Play 系统更新推送到超过 10 亿部设备。

所有开发者都应在 Android 16 上对其应用进行全面测试，以检查其应用是否受到影响。此外，请查看已知问题，了解您的应用是否依赖于我们发现的任何依赖于内部 ART 结构的库。如果您的应用代码或库依赖项受到影响，请尽可能寻找公共 API 替代方案，并在问题跟踪器中创建功能请求，为新用例请求公共 API。

Kompatibilitätsmodus für Seitengrößen 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.

Nutzererfahrung und System-UI

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

Einstellung störender Bedienungshilfen-Ankündigungen

Unter Android 16 werden Ansagen für Bedienungshilfen nicht mehr unterstützt. Sie werden durch die Verwendung von announceForAccessibility oder das Senden von Bedienungshilfenereignissen vom Typ TYPE_ANNOUNCEMENT gekennzeichnet. Dies kann zu inkonsistenten Nutzererfahrungen für Nutzer von TalkBack und dem Android-Screenreader führen. Alternativen können die Anforderungen einer größeren Anzahl von Nutzern in einer Vielzahl von Hilfstechnologien von Android besser erfüllen.

Beispiele für Alternativen:

• Verwenden Sie für erhebliche Änderungen an der Benutzeroberfläche, z. B. Fensteränderungen, Activity.setTitle(CharSequence) und setAccessibilityPaneTitle(java.lang.CharSequence). Verwenden Sie in der Funktion „Schreiben“ die Taste Modifier.semantics { paneTitle = "paneTitle" }.
• Verwenden Sie setAccessibilityLiveRegion(int), um Nutzer über Änderungen an wichtigen UI-Elementen zu informieren. Verwenden Sie in der Zeichenansicht Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]} . Sie sollten sparsam verwendet werden, da sonst jedes Mal, wenn eine Ansicht aktualisiert wird, eine Benachrichtigung generiert wird.
• Wenn du Nutzer über Fehler informieren möchtest, sende eine AccessibilityEvent vom Typ AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR und setze AccessibilityNodeInfo#setError(CharSequence) oder verwende TextView#setError(CharSequence).

Weitere Informationen zu den empfohlenen Alternativen finden Sie in der Referenzdokumentation zur eingestellten announceForAccessibility API.

Unterstützung für die 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 Besitzer virtueller Geräte

Ein virtueller Geräteinhaber ist eine vertrauenswürdige oder privilegierte App, die ein virtuelles Gerät erstellt und verwaltet. Besitzer virtueller Geräte führen Apps auf einem virtuellen Gerät aus und übertragen sie dann auf das Display eines Remote-Geräts, z. B. eines PCs, eines Virtual-Reality-Geräts oder eines Infotainmentsystems im Auto. Der Inhaber des virtuellen Geräts verwendet ein lokales Gerät wie ein Smartphone.

Der Inhaber des virtuellen Geräts auf dem Smartphone erstellt ein virtuelles Gerät, das die App auf einem Remote-Display anzeigt.

App-spezifische Überschreibungen

Auf Geräten mit Android 16 (API-Level 36) können Besitzer virtueller Geräte App-Einstellungen auf ausgewählten virtuellen Geräten überschreiben, die sie verwalten. Um beispielsweise das App-Layout zu verbessern, kann der Inhaber eines virtuellen Geräts Einschränkungen für Ausrichtung, Seitenverhältnis und Größe ignorieren, wenn Apps auf einen externen Bildschirm projiziert werden.

Häufige wichtige Änderungen

Das Verhalten von Android 16 kann sich auf die Benutzeroberfläche Ihrer App auf Geräten mit großen Bildschirmen wie Autodisplays oder Chromebooks auswirken, insbesondere auf Layouts, die für kleine Displays im Hochformat entwickelt wurden. Informationen dazu, wie Sie Ihre App für alle Geräteformfaktoren anpassen, finden Sie unter Adaptive Layouts.

Referenzen

Streaming von Companion-Apps

Sicherheit

Android 16 (API-Level 36) enthält Änderungen, die die Systemsicherheit verbessern, um 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-Weiterleitungs-Exploits 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 Sicherheitsfunktionen 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.

Wichtig :Das Deaktivieren von Sicherheitsfunktionen sollte mit Vorsicht und nur dann erfolgen, wenn es unbedingt erforderlich ist, da es das Risiko von Sicherheitslücken erhöhen kann. Bewerten Sie sorgfältig die potenziellen Auswirkungen auf die Sicherheit Ihrer App, bevor Sie diese API verwenden.

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

Sie können die removeLaunchSecurityProtection()-Methode 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

Die Verwendung von Reflection für den Zugriff auf die Methode removeLaunchSecurityProtection() wird zwar nicht empfohlen, ist aber möglich.

Achtung :Durch die Verwendung von Reflection kann Ihr Code anfälliger für Fehler werden, insbesondere wenn sich die zugrunde liegende API in zukünftigen Android-Versionen ändert. Aktualisieren Sie Ihr Compile-SDK nach Möglichkeit auf Android 16 (API-Level 36) oder höher, um die API direkt zu verwenden.

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 Time-outs bei der Suche benachrichtigt

In Android 16 wird beim Verknüpfen von Geräten ein neues Verhalten eingeführt, um den Standortdatenschutz der Nutzer vor schädlichen Apps zu schützen. Alle Companion-Apps, die unter Android 16 ausgeführt werden, werden nicht mehr direkt über RESULT_DISCOVERY_TIMEOUT über das Zeitlimit für die Suche informiert. Stattdessen wird der Nutzer über ein visuelles Dialogfeld über Zeitüberschreitungen informiert. Wenn der Nutzer das Dialogfeld schließt, wird die App über den Zuordnungsfehler mit RESULT_USER_REJECTED informiert.

Außerdem wurde die Suchdauer von ursprünglich 20 Sekunden auf 60 Sekunden verlängert. Die Gerätesuche kann vom Nutzer jederzeit beendet werden. Wenn innerhalb der ersten 20 Sekunden nach Beginn der Suche mindestens ein Gerät gefunden wurde, sucht die CDM nicht mehr nach weiteren Geräten.

Konnektivität

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

Verbesserte Verarbeitung von Verbindungsverlusten

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.