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 an diese Änderungen anpassen.

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

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 für Jobs, die gleichzeitig mit einem Dienst im Vordergrund ausgeführt werden, das Kontingent für die Joblaufzeit eingehalten. 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 zu protokollieren. Rufen Sie dazu WorkInfo.getStopReason() auf (für JobScheduler-Jobs JobParameters.getStopReason()).

Informationen dazu, wie sich der Status Ihrer App auf die nutzbaren Ressourcen auswirkt, finden Sie unter Ressourcenlimits für die Energieverwaltung. Weitere Informationen zu Best Practices für eine optimale Akkunutzung finden Sie im Leitfaden zum Optimieren der Akkunutzung für APIs zur Aufgabenplanung.

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 Job-Laufzeitkontingent 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 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

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.

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:

  1. 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.
  2. 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 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 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.

Störende Ansagen von Bedienungshilfen werden eingestellt

Android 16 废弃了无障碍功能通告，其特征是使用 announceForAccessibility 或调度 TYPE_ANNOUNCEMENT 无障碍功能事件。这可能会给 TalkBack 和 Android 屏幕阅读器用户带来不一致的用户体验，而替代方案可以更好地满足各种 Android 辅助技术的用户需求。

替代方案示例：

已废弃的 announceForAccessibility API 的参考文档中包含有关建议替代方案的更多详细信息。

Unterstützung der Bedienung über 3 Schaltflächen

Android 16 为已正确迁移到预测性返回的应用的三按钮导航栏引入了预测性返回支持。长按返回按钮会启动预测性返回动画，让您预览返回滑动手势会打开的界面。

此行为适用于系统中支持预测性返回动画的所有区域，包括系统动画（返回主屏幕、跨任务和跨 activity）。

“三按钮”导航模式下的预测性返回动画。

Unterstützung der Bedienung über 3 Schaltflächen

Beginning with Android 16 QPR 2, Android automatically applies themes to app icons to create a cohesive home screen experience. This occurs if an app does not provide its own themed app icon. Apps can control the design of their themed app icon by including a monochrome layer within their adaptive icon and previewing what their app icon will look like in Android Studio.

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

虚拟设备所有者是创建和管理虚拟设备的受信任应用或特权应用。虚拟设备所有者在虚拟设备上运行应用，然后将应用投影到远程设备的显示屏上，例如个人电脑、虚拟现实设备或车载信息娱乐系统。虚拟设备所有者位于本地设备上，例如手机。

手机上的虚拟设备所有者创建将应用投影到远程显示屏的虚拟设备。

按应用替换项

在搭载 Android 16（API 级别 36）的设备上，虚拟设备所有者可以替换其管理的特定虚拟设备上的应用设置。例如，为了改进应用布局，虚拟设备所有者在将应用投影到外部显示屏上时，可以忽略屏幕方向、宽高比和可调整大小性限制。

常见的重大更改

Android 16 行为可能会影响应用在汽车显示屏或 Chromebook 等大屏幕设备上的界面，尤其是那些专为竖屏小显示屏设计的布局。如需了解如何让应用适应所有设备类型，请参阅关于自适应布局。

参考编号

配套应用串流

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

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

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