Verhaltensänderungen: alle Apps

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

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.

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 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 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 4‑KB-Arbeitsspeicherseiten entwickelt wurden, auf einem Gerät ausgeführt werden können, das für 16‑KB-Arbeitsspeicherseiten konfiguriert ist.

Wenn Android erkennt, dass Ihre App Speicherseiten mit 4 KB hat, wird automatisch der Kompatibilitätsmodus verwendet und dem Nutzer ein Benachrichtigungsdialogfeld angezeigt. Wenn Sie die android:pageSizeCompat-Property in der AndroidManifest.xml so festlegen, dass der Abwärtskompatibilitätsmodus aktiviert wird, wird der Dialog beim Starten Ihrer App nicht angezeigt. 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 Blogpost zur Aktualisierung 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 eine einheitlichere und intuitivere Nutzererfahrung schaffen sollen.

Einstellung von störenden Ansagen zu Bedienungshilfen

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:

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

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

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

Ein virtueller Geräteeigentümer ist eine vertrauenswürdige oder privilegierte App, die ein virtuelles Gerät erstellt und verwaltet. Inhaber virtueller Geräte führen Apps auf einem virtuellen Gerät aus und projizieren sie dann auf das Display eines Remote-Geräts wie eines Computers, eines Virtual-Reality-Geräts oder eines Infotainmentsystems im Auto. Der Inhaber des virtuellen Geräts befindet sich auf einem lokalen Gerät, z. B. einem Smartphone.

Der Eigentümer des virtuellen Geräts auf dem Smartphone erstellt ein virtuelles Gerät, das die App auf das Remote-Display projiziert.

App-spezifische Überschreibungen

Auf Geräten mit Android 16 (API-Level 36) können Eigentümer 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 bei Ausrichtung, Seitenverhältnis und Größe ignorieren, wenn Apps auf ein externes Display projiziert werden.

Häufige funktionsgefährdende Ä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 adaptiv gestalten, finden Sie unter Adaptive Layouts.

Referenzen

Streaming von Companion-Apps

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.