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 anpassen, um diese Änderungen zu unterstützen.

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

An abandoned job occurs when the JobParameters object associated with the job has been garbage collected, but JobService#jobFinished(JobParameters, boolean) has not been called to signal job completion. This indicates that the job may be running and being rescheduled without the app's awareness.

Apps that rely on JobScheduler, don't maintain a strong reference to the JobParameters object, and timeout will now be granted the new job stop reason STOP_REASON_TIMEOUT_ABANDONED, instead of STOP_REASON_TIMEOUT.

If there are frequent occurrences of the new abandoned stop reason, the system will take mitigation steps to reduce job frequency.

Apps should use the new stop reason to detect and reduce abandoned jobs.

If you're using WorkManager, AsyncTask, or DownloadManager, you aren't impacted because these APIs manage the job lifecycle on your app's behalf.

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 应用可以为广播接收器定义优先级，以控制接收器接收和处理广播的顺序。对于清单声明的接收器，应用可以使用 android:priority 属性来定义优先级；对于上下文注册的接收器，应用可以使用 IntentFilter#setPriority() API 来定义优先级。发送广播时，系统会按接收器的优先级（从高到低）将其传送给接收器。

在 Android 16 中，无法保证使用 android:priority 属性或 IntentFilter#setPriority() 在不同进程中传送广播的顺序。广播优先级仅在同一应用进程内有效，而不会跨所有进程有效。

此外，广播优先级将自动限制在 (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1) 的范围内。只有系统组件才能将 SYSTEM_LOW_PRIORITY、SYSTEM_HIGH_PRIORITY 设置为广播优先级。

如果您的应用执行以下任一操作，可能会受到影响：

  1. 您的应用声明了具有相同广播 intent 的多个进程，并且希望根据优先级以特定顺序接收这些 intent。
  2. 您的应用进程与其他进程交互，并期望以特定顺序接收广播 intent。

如果进程需要相互协调，则应使用其他协调渠道进行通信。

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.

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

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 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 Inhaber 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 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 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 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-Weiterleitungsmanipulationen 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 gerät.

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

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 Behandlung von Anleiheverlusten

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.