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 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 wird vollständig eingestellt

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

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 enthält die folgenden Änderungen, die für eine einheitlichere und intuitivere Nutzererfahrung sorgen 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 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 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 er Apps auf ein externes Display projiziert.

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 enthält Änderungen, die die Systemsicherheit verbessern und Apps und Nutzer vor schädlichen Apps schützen sollen.

Verbesserte Sicherheit gegen Angriffe durch Weiterleitung von Intents

Android 16 bietet standardmäßig Schutz vor allgemeinen Intent-Weiterleitungsangriffen. Dabei sind nur minimale Kompatibilitäts- und Entwickleränderungen erforderlich.

Wir führen standardmäßig Lösungen zur Sicherheitshärtung ein, um Intent Ausnutzungen umzuleiten. 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 Unterbrechungen kommen könnte.

Eine Intent-Weiterleitung unter Android tritt auf, wenn ein Angreifer den Inhalt eines Intents teilweise oder vollständig steuern kann, mit dem eine neue Komponente im Kontext einer anfälligen App gestartet wird, während die Opfer-App einen nicht vertrauenswürdigen Intent auf untergeordneter Ebene in einem Extras-Feld eines Intents („oberste 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 potenziell zu Datendiebstahl und Ausführung beliebigen Codes führen kann.

Weiterleitungen für Intents deaktivieren

Android 16 enthält eine neue API, mit der Apps die Sicherheitsvorkehrungen beim Starten deaktivieren können. Dies kann in bestimmten Fällen erforderlich sein, wenn das standardmäßige Sicherheitsverhalten legitime Anwendungsfälle beeinträchtigt.

Für Anwendungen, die auf Android 16 oder höher ausgerichtet sind

Sie können die Methode removeLaunchSecurityProtection() direkt auf das Intent-Objekt anwenden.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }
Für Anwendungen, die auf Android 15 (API-Level 35) oder niedriger ausgerichtet sind

Sie können zwar Reflection verwenden, um auf die Methode removeLaunchSecurityProtection() zuzugreifen, wir empfehlen dies jedoch nicht.

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