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 Laufzeitkontingent für die reguläre und beschleunigte Ausführung von Jobs basierend auf den 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 der Job ausgeführt wird, während sich die App im Vordergrund befindet: In Android 16 werden Jobs, die gestartet werden, während die App für den Nutzer sichtbar ist, und die fortgesetzt werden, nachdem die App nicht mehr sichtbar ist, an das Job-Laufzeitkontingent gehalten.
  • Wenn der Job während der Ausführung eines Dienstes im Vordergrund ausgeführt wird: In Android 16 wird das Joblaufzeitkontingent für Jobs, die gleichzeitig mit einem Dienst im Vordergrund ausgeführt werden, eingehalten. Wenn Sie Jobs für vom Nutzer initiierte Datenübertragungen verwenden, sollten Sie stattdessen vom Nutzer initiierte Datenübertragungsjobs verwenden.

Diese Änderung wirkt sich auf Aufgaben aus, die mit WorkManager, JobScheduler und DownloadManager geplant werden. Wenn Sie herausfinden möchten, warum ein Job angehalten wurde, empfehlen wir, den Grund dafür zu protokollieren, indem Sie WorkInfo.getStopReason() aufrufen (für JobScheduler-Jobs rufen Sie JobParameters.getStopReason() auf).

Informationen dazu, wie sich der Status Ihrer App auf die Ressourcen auswirkt, die sie verwenden kann, finden Sie unter Ressourcenbeschränkungen für die Energieverwaltung. Weitere Informationen zu Best Practices für die Akkuoptimierung 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 zu verstehen, warum ein Job nicht ausgeführt wurde.

Testen

Wenn Sie das Verhalten Ihrer App testen möchten, können Sie bestimmte Optimierungen des Jobkontingents überschreiben, solange die App auf einem Android 16-Gerät ausgeführt wird.

Führen Sie den folgenden adb-Befehl aus, um die Erzwingung von „Der oberste Status entspricht dem Kontingent für die Joblaufzeit“ zu deaktivieren:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

Führen Sie den folgenden adb-Befehl aus, um die Erzwingung von „Jobs, die gleichzeitig mit einem Vordergrunddienst ausgeführt werden, halten sich an das Job-Laufzeitkontingent“ zu deaktivieren:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

Wenn Sie das Verhalten bestimmter App-Stand-by-Buckets testen möchten, können Sie den App-Stand-by-Bucket Ihrer App mit dem folgenden adb-Befehl festlegen:

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

Mit dem folgenden adb-Befehl können Sie den App-Standby-Bucket Ihrer App abrufen:

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 für die Priorität von Broadcasts 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 Änderungen an ART

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

Nutzererfahrung und System-UI

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

Störende Ansagen von Bedienungshilfen werden eingestellt

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

Android 16 brings predictive back support to the 3-button navigation for apps that have properly migrated to predictive back. Long-pressing the back button initiates a predictive back animation, giving you a preview of where the back swipe takes you.

This behavior applies across all areas of the system that support predictive back animations, including the system animations (back-to-home, cross-task, and cross-activity).

The predictive back animations in 3-button navigation mode.

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

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 Eigentümer des virtuellen Geräts befindet sich auf einem lokalen Gerät, z. B. einem 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 und dazu beitragen, Apps und Nutzer vor schädlichen Apps zu schützen.

Verbesserter Schutz vor Angriffen, bei denen Intents umgeleitet werden

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.

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.

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 在配套设备配对流程期间引入了一种新行为，以防恶意应用侵犯用户的位置信息隐私。在 Android 16 上运行的所有配套应用都不再直接通过 RESULT_DISCOVERY_TIMEOUT 收到发现超时通知。而是通过可视对话框通知用户超时事件。当用户关闭对话框时，系统会通过 RESULT_USER_REJECTED 提醒应用关联失败。

搜索时长也从原来的 20 秒延长到了 30 秒，并且用户可以在搜索期间的任何时间停止设备发现。如果在开始搜索的前 20 秒内发现了至少 1 部设备，CDM 会停止搜索其他设备。

Konnektivität

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

Verbesserte Verarbeitung von Anleiheverlusten

从 Android 16 开始，蓝牙堆栈已更新，以便在检测到远程配对丢失时提高安全性和用户体验。以前，系统会自动解除配对并启动新的配对流程，这可能会导致意外重新配对。在许多情况下，我们发现应用未以一致的方式处理债券损失事件。

为了统一体验，Android 16 改进了系统的绑定丢失处理。如果之前配对的蓝牙设备在重新连接时无法进行身份验证，系统会断开关联，保留本地配对信息，并显示系统对话框，告知用户配对已断开并指示他们重新配对。