Verhaltensänderungen: Apps, die auf Android 15 oder höher ausgerichtet sind

Wie bei früheren Releases enthält Android 15 Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps, die auf Android 15 oder höher ausgerichtet sind. Wenn Ihre App auf Android 15 oder höher ausgerichtet ist, sollten Sie sie gegebenenfalls so ändern, dass sie diese Verhaltensweisen korrekt unterstützt.

Lesen Sie sich auch die Liste der Verhaltensänderungen durch, die sich auf alle Apps auswirken, die unter Android 15 ausgeführt werden, unabhängig von der targetSdkVersion Ihrer App.

Hauptfunktion

In Android 15 wurden verschiedene Kernfunktionen des Android-Systems geändert oder erweitert.

Änderungen an Diensten im Vordergrund

Wir nehmen unter Android 15 die folgenden Änderungen an Diensten im Vordergrund vor.

Verhalten bei Zeitüberschreitung bei der Datensynchronisierung im Vordergrund

Unter Android 15 wird für dataSync ein neues Zeitlimit für Apps eingeführt, die auf Android 15 (API-Level 35) oder höher ausgerichtet sind. Dies gilt auch für den neuen Diensttyp mediaProcessing im Vordergrund.

Das System erlaubt es den dataSync-Diensten einer App, innerhalb eines Zeitraums von 24 Stunden insgesamt 6 Stunden lang ausgeführt zu werden. Danach ruft das System die Methode Service.onTimeout(int, int) des laufenden Dienstes auf (in Android 15 eingeführt). In dieser Zeit hat der Dienst einige Sekunden Zeit, Service.stopSelf() aufzurufen. Wenn Service.onTimeout() aufgerufen wird, gilt der Dienst nicht mehr als Dienst im Vordergrund. Wenn der Dienst Service.stopSelf() nicht aufruft, löst das System eine interne Ausnahme aus. Die Ausnahme wird in Logcat mit der folgenden Meldung protokolliert:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"

So vermeiden Sie Probleme mit dieser Verhaltensänderung:

  1. Lassen Sie Ihren Dienst die neue Service.onTimeout(int, int)-Methode implementieren. Wenn Ihre App den Callback empfängt, müssen Sie innerhalb weniger Sekunden stopSelf() anrufen. Wenn Sie die App nicht sofort beenden, generiert das System einen Fehler.
  2. Die dataSync-Dienste Ihrer App dürfen innerhalb eines 24-Stunden-Zeitraums nicht länger als insgesamt 6 Stunden ausgeführt werden, es sei denn, der Nutzer interagiert mit der App und setzt den Timer zurück.
  3. Starten Sie dataSync Dienste im Vordergrund nur als Folge einer direkten Nutzerinteraktion. Da sich Ihre App beim Start des Dienstes im Vordergrund befindet, hat Ihr Dienst die vollen sechs Stunden Zeit, nachdem die App in den Hintergrund gewechselt ist.
  4. Verwenden Sie stattdessen eine alternative API.dataSync

Wenn die dataSync-Dienste im Vordergrund Ihrer App in den letzten 24 Stunden sechs Stunden lang ausgeführt wurden, können Sie keinen weiteren dataSync-Dienst im Vordergrund starten, es sei denn, der Nutzer hat Ihre App in den Vordergrund gebracht (wodurch der Timer zurückgesetzt wird). Wenn Sie versuchen, einen weiteren dataSync-Vordergrunddienst zu starten, gibt das System ForegroundServiceStartNotAllowedException mit einer Fehlermeldung zurück, z. B. „Zeitlimit für den Typ ‚dataSync‘ des Vordergrunddienstes bereits überschritten“.

Testen

Sie können Zeitüberschreitungen für die Datensynchronisierung aktivieren, um das Verhalten Ihrer App zu testen, auch wenn Ihre App nicht auf Android 15 ausgerichtet ist, solange die App auf einem Android 15-Gerät ausgeführt wird. Führen Sie den folgenden Befehl adb aus, um Zeitüberschreitungen zu aktivieren:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

Sie können auch die Zeitüberschreitung anpassen, um das Verhalten Ihrer App nach Erreichen des Limits leichter zu testen. Führen Sie den folgenden adb-Befehl aus, um ein neues Zeitlimit festzulegen:

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

Neuer Typ von Dienst zur Medienverarbeitung im Vordergrund

In Android 15 wird der neue Diensttyp mediaProcessing eingeführt. Dieser Diensttyp eignet sich für Vorgänge wie das Transcodieren von Mediendateien. Eine Medien-App könnte beispielsweise eine Audiodatei herunterladen und sie vor der Wiedergabe in ein anderes Format konvertieren. Sie können einen mediaProcessing-Dienst im Vordergrund verwenden, damit die Conversion auch dann fortgesetzt wird, wenn die App im Hintergrund ausgeführt wird.

Das System lässt zu, dass die mediaProcessing-Dienste einer App insgesamt 6 Stunden innerhalb von 24 Stunden ausgeführt werden. Anschließend ruft das System die Service.onTimeout(int, int)-Methode des laufenden Dienstes auf (in Android 15 eingeführt). Derzeit hat der Dienst einige Sekunden Zeit, um Service.stopSelf() aufzurufen. Wenn der Dienst Service.stopSelf() nicht aufruft, löst das System eine interne Ausnahme aus. Die Ausnahme wird in Logcat mit der folgenden Meldung protokolliert:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"

Sie können eine Ausnahme vermeiden, indem Sie einen der folgenden Schritte ausführen:

  1. Implementieren Sie in Ihrem Dienst die neue Service.onTimeout(int, int)-Methode. Wenn Ihre App den Callback empfängt, müssen Sie innerhalb weniger Sekunden stopSelf() anrufen. Wenn Sie die App nicht sofort beenden, generiert das System einen Fehler.
  2. Die mediaProcessing-Dienste Ihrer App dürfen innerhalb eines 24-Stunden-Zeitraums insgesamt nicht länger als 6 Stunden ausgeführt werden, es sei denn, der Nutzer interagiert mit der App und setzt den Timer zurück.
  3. Starten Sie mediaProcessing Dienste im Vordergrund nur als Folge einer direkten Nutzerinteraktion. Da sich Ihre App beim Start des Dienstes im Vordergrund befindet, hat Ihr Dienst die vollen sechs Stunden Zeit, nachdem die App in den Hintergrund gewechselt ist.
  4. Verwende anstelle eines mediaProcessing-Dienstes im Vordergrund eine alternative API wie WorkManager.

Wenn die mediaProcessing-Dienste im Vordergrund Ihrer App in den letzten 24 Stunden sechs Stunden lang ausgeführt wurden, können Sie keinen weiteren mediaProcessing-Dienst im Vordergrund starten, es sei denn, der Nutzer hat Ihre App in den Vordergrund gebracht (wodurch der Timer zurückgesetzt wird). Wenn Sie versuchen, einen weiteren mediaProcessing-Vordergrunddienst zu starten, löst das System ForegroundServiceStartNotAllowedException mit einer Fehlermeldung wie „Zeitlimit für den Typ „mediaProcessing“ des Dienstes im Vordergrund bereits überschritten“ aus.

Weitere Informationen zum Diensttyp mediaProcessing finden Sie unter Änderungen an Diensttypen im Vordergrund für Android 15: Medienverarbeitung.

Testen

Wenn du das Verhalten deiner App testen möchtest, kannst du Zeitüberschreitungen bei der Medienverarbeitung aktivieren, auch wenn deine App nicht auf Android 15 ausgerichtet ist, solange sie auf einem Android 15-Gerät ausgeführt wird. Führen Sie den folgenden Befehl adb aus, um Zeitüberschreitungen zu aktivieren:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

Sie können auch das Zeitlimit anpassen, um zu testen, wie sich Ihre Anwendung verhält, wenn das Limit erreicht ist. Führen Sie den folgenden adb-Befehl aus, um ein neues Zeitlimit festzulegen:

adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds

Einschränkungen für BOOT_COMPLETED Übertragungsempfänger, die Dienste im Vordergrund starten

在启动 BOOT_COMPLETED 广播接收器方面存在新限制 前台服务。BOOT_COMPLETED 接收器能启动 以下类型的前台服务:

如果 BOOT_COMPLETED 接收器尝试启动任何上述类型的前台 服务,系统会抛出 ForegroundServiceStartNotAllowedException

测试

如需测试应用的行为,您可以启用这些新限制,即使您的应用并未以 Android 15 为目标平台(只要应用在 Android 15 设备上运行)也是如此。运行以下 adb 命令:

adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name

如需在不重启设备的情况下发送 BOOT_COMPLETED 广播,请运行以下 adb 命令:

adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name

Einschränkungen beim Starten von Diensten im Vordergrund, während eine App die Berechtigung „SYSTEM_ALERT_WINDOW“ enthält

以前,如果应用拥有 SYSTEM_ALERT_WINDOW 权限,即使应用当前在后台运行,也可以启动前台服务(如免于后台启动限制中所述)。

如果应用以 Android 15 为目标平台,则此豁免范围现在更窄。现在,应用需要具有 SYSTEM_ALERT_WINDOW 权限,并且需要有一个可见的叠加窗口。也就是说,应用需要先启动 TYPE_APPLICATION_OVERLAY 窗口,并且该窗口需要处于可见状态,然后您才能启动前台服务。

如果您的应用尝试从后台启动前台服务,但不符合这些新要求(并且没有其他豁免情况),系统会抛出 ForegroundServiceStartNotAllowedException

如果您的应用声明了 SYSTEM_ALERT_WINDOW 权限并从后台启动前台服务,则可能会受到此变更的影响。如果您的应用获得了 ForegroundServiceStartNotAllowedException,请检查应用的操作顺序,并确保应用在尝试从后台启动前台服务之前已具有有效的叠加层窗口。您可以通过调用 View.getWindowVisibility() 检查叠加层窗口当前是否可见,也可以替换 View.onWindowVisibilityChanged(),以便在可见性发生变化时收到通知。

测试

如需测试应用的行为,您可以启用这些新限制,即使您的应用并未以 Android 15 为目标平台(只要应用在 Android 15 设备上运行)也是如此。如需针对从后台启动前台服务启用这些新限制,请运行以下 adb 命令:

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

Änderungen bei der Möglichkeit von Apps, den globalen Status des Modus „Bitte nicht stören“ zu ändern

以 Android 15 为目标平台的应用无法再更改设备上的全局状态或勿扰 (DND) 政策(通过修改用户设置或关闭 DND 模式)。相反,应用必须提供一个 AutomaticZenRule,系统会将后者合并到一个具有现有最严格的政策胜出方案的全局政策中。调用之前影响全局状态的现有 API(setInterruptionFiltersetNotificationPolicy)会导致创建或更新隐式 AutomaticZenRule,该 AutomaticZenRule 根据这些 API 调用的调用周期而开启或关闭。

请注意,只有在应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL) 且预期调用会停用之前由其所有者激活的 AutomaticZenRule 时,此变更才会影响可观察的行为。

Änderungen an der OpenJDK API

Android 15 将继续更新 Android 的核心库,以与最新 OpenJDK LTS 版本中的功能保持一致。

其中一些变更可能会影响以 Android 15(API 级别 35)为目标平台的应用的兼容性:

  • 对字符串格式化 API 的更改:现在,使用以下 String.format()Formatter.format() API 时,对参数索引、标志、宽度和精度的验证更为严格:

    例如,如果使用参数索引 0(格式字符串中的 %0),系统会抛出以下异常:

    IllegalFormatArgumentIndexException: Illegal format argument index = 0
    

    在这种情况下,可以通过使用参数编号 1(格式字符串中的 %1)来解决此问题。

  • Arrays.asList(...).toArray() 的组件类型变更:使用 Arrays.asList(...).toArray() 时,生成数组的组件类型现在为 Object,而不是底层数组元素的类型。因此,以下代码会抛出 ClassCastException

    String[] elements = (String[]) Arrays.asList("one", "two").toArray();
    

    对于这种情况,如需将 String 保留为生成的数组中的组件类型,您可以改用 Collection.toArray(Object[])

    String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
    
  • 语言代码处理方式变更:使用 Locale API 时,希伯来语、意第绪语和印度尼西亚语的语言代码不再转换为已废弃的形式(希伯来语:iw、意第绪语:ji、印度尼西亚语:in)。在为其中一种语言区域指定语言代码时,请改用 ISO 639-1 中的代码(希伯来语:he、意第绪语:yi、印度尼西亚语:id)。

  • 对随机 int 序列的更改:在 https://bugs.openjdk.org/browse/JDK-8301574 中进行更改后,以下 Random.ints() 方法现在返回的数字序列与 Random.nextInt() 方法返回的序列不同:

    通常,此更改不会导致应用出现破坏行为,但您的代码不应预期从 Random.ints() 方法生成的序列与 Random.nextInt() 匹配。

在您更新应用 build 配置中的 compileSdk 以使用 Android 15(API 级别 35)后,新的 SequencedCollection API 可能会影响应用的兼容性:

  • kotlin-stdlib 中的 MutableList.removeFirst()MutableList.removeLast() 扩展函数发生冲突

    Java 中的 List 类型会映射到 Kotlin 中的 MutableList 类型。由于 List.removeFirst()List.removeLast() API 已在 Android 15(API 级别 35)中引入,因此 Kotlin 编译器会将函数调用(例如 list.removeFirst())静态解析为新的 List API,而不是 kotlin-stdlib 中的扩展函数。

    如果将应用重新编译并将 compileSdk 设置为 35 且将 minSdk 设置为 34 或更低级别,然后在 Android 14 及更低版本上运行该应用,系统会抛出运行时错误:

    java.lang.NoSuchMethodError: No virtual method
    removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
    

    Android Gradle 插件中现有的 NewApi lint 选项可以捕获这些新的 API 用法。

    ./gradlew lint
    
    MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
          list.removeFirst()
    

    如需修复运行时异常和 lint 错误,可以在 Kotlin 中将 removeFirst()removeLast() 函数调用分别替换为 removeAt(0)removeAt(list.lastIndex)。如果您使用的是 Android Studio Ladybug | 2024.1.3 或更高版本,则该版本还提供了针对这些错误的快速修复选项。

    如果 lint 选项已停用,请考虑移除 @SuppressLint("NewApi")lintOptions { disable 'NewApi' }

  • 与 Java 中的其他方法冲突

    现有类型中添加了新方法,例如 ListDeque。这些新方法可能与其他接口和类中具有相同名称和参数类型的方法不兼容。如果方法签名发生冲突且不兼容,javac 编译器会输出构建时错误。例如:

    错误示例 1:

    javac MyList.java
    
    MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List
      public void removeLast() {
                  ^
      return type void is not compatible with Object
      where E is a type-variable:
        E extends Object declared in interface List
    

    错误示例 2:

    javac MyList.java
    
    MyList.java:7: error: types Deque<Object> and List<Object> are incompatible;
    public class MyList implements  List<Object>, Deque<Object> {
      both define reversed(), but with unrelated return types
    1 error
    

    错误示例 3:

    javac MyList.java
    
    MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible;
    public static class MyList implements List<Object>, MyInterface<Object> {
      class MyList inherits unrelated defaults for getFirst() from types List and MyInterface
      where E#1,E#2 are type-variables:
        E#1 extends Object declared in interface List
        E#2 extends Object declared in interface MyInterface
    1 error
    

    如需修复这些构建错误,实现这些接口的类应使用兼容的返回类型替换该方法。例如:

    @Override
    public Object getFirst() {
        return List.super.getFirst();
    }
    

Sicherheit

Android 15 enthält Änderungen, die die Systemsicherheit verbessern und Apps und Nutzer vor schädlichen Apps schützen sollen.

Start von sicheren Hintergrundaktivitäten

Android 15 可保护用户免受恶意应用的侵害,并让用户更好地控制 来防止恶意后台应用 将其他应用置于前台、提升其权限以及滥用 用户互动自以下时间以来,后台活动启动一直受到限制 Android 10(API 级别 29)。

禁止与堆栈中的顶部 UID 不匹配的应用启动 activity

恶意应用可以在同一任务中启动另一个应用的 activity,然后 叠加在上面,营造出像该应用一样的错觉。这个“任务” 劫持"攻击绕过了当前的后台启动限制, 会发生在同一个可见任务中。为了降低这种风险,Android 15 新增了 用于阻止与堆栈中的顶层 UID 不匹配的应用启动的标志 活动。如需选择启用应用的所有活动,请更新 allowCrossUidActivitySwitchFromBelow 属性:AndroidManifest.xml

<application android:allowCrossUidActivitySwitchFromBelow="false" >

如果满足以下所有条件,则启用新的安全措施:

  • 执行启动的应用以 Android 15 为目标平台。
  • 任务堆栈顶部的应用以 Android 15 为目标平台。
  • 所有可见活动都已选择启用新保护措施

如果启用了安全措施,应用可能会返回主屏幕,而不是返回 最后一个可见应用(如果他们自行完成任务)。

其他变更

除了限制 UID 匹配之外,这些其他变更也 包括:

  • 更改 PendingIntent 创作者,以阻止后台活动启动,具体方法是: 默认。这有助于防止应用意外创建 可能被恶意操作者滥用的 PendingIntent
  • 请勿将应用调到前台,除非 PendingIntent 发送者 允许它。此变更旨在防止恶意应用滥用 在后台启动 activity 的功能。默认情况下,应用 允许将任务堆栈转到前台,除非创建者允许 后台活动启动权限或发送者有后台活动 启动权限
  • 控制任务堆栈的顶层 activity 完成其任务的方式。如果 顶层 activity 完成一项任务后,Android 会返回到之前执行的 上次活动时间。此外,如果非顶层 activity 完成其任务,Android 将 返回主屏幕;因此不会阻碍这个非顶层的 活动。
  • 防止将其他应用中的任意 activity 启动到您自己的 activity 任务。这项变更旨在防止恶意应用 看起来像是来自其他应用的活动
  • 禁止将不可见窗口视为后台活动 发布。这有助于防止恶意应用滥用后台 activity 来向用户显示不需要或恶意的内容。

Sicherere Intents

Mit Android 15 werden neue optionale Sicherheitsmaßnahmen eingeführt, um Intents sicherer und robuster zu machen. Mit diesen Änderungen sollen potenzielle Sicherheitslücken und Missbrauch von Intents verhindert werden, die von schädlichen Apps ausgenutzt werden können. In Android 15 wurden zwei wichtige Verbesserungen an der Sicherheit von Intents vorgenommen:

  • Intent-Filter des Ziels abgleichen: Intents, die auf bestimmte Komponenten ausgerichtet sind, müssen genau den Intent-Filterspezifikationen des Ziels entsprechen. Wenn Sie einen Intent senden, um die Aktivität einer anderen App zu starten, muss die Ziel-Intent-Komponente mit den deklarierten Intent-Filtern der Empfangsaktivität übereinstimmen.
  • Intents müssen Aktionen haben: Intents ohne Aktion werden nicht mehr mit Intent-Filtern abgeglichen. Das bedeutet, dass Intents, die zum Starten von Aktivitäten oder Diensten verwendet werden, eine klar definierte Aktion haben müssen.

Wenn Sie prüfen möchten, wie Ihre App auf diese Änderungen reagiert, verwenden Sie StrictMode in Ihrer App. Wenn Sie detaillierte Protokolle zu Verstößen bei der Nutzung von Intent sehen möchten, fügen Sie die folgende Methode hinzu:

Kotlin


fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        .detectUnsafeIntentLaunch()
        .build()
    )
}

Java


public void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
            .detectUnsafeIntentLaunch()
            .build());
}

Nutzererfahrung und System-UI

Android 15 enthält einige Änderungen, die für eine einheitlichere und intuitivere Nutzererfahrung sorgen sollen.

Änderungen am Fenstereinsatz

In Android 15 gibt es zwei Änderungen im Zusammenhang mit Fenstereinsätzen: Edge-to-Edge-Änderungen werden standardmäßig erzwungen. Außerdem gibt es Konfigurationsänderungen, z. B. die Standardkonfiguration von Systemleisten.

Edge-to-Edge-Erzwingung

Apps sind auf Geräten mit Android 15 standardmäßig Edge-to-Edge-Apps, wenn sie auf Android 15 (API-Level 35) ausgerichtet sind.

Eine App, die auf Android 14 ausgerichtet ist und kein Edge-to-Edge-Gerät auf einem Android 15-Gerät ist.


Eine App, die auf Android 15 (API-Level 35) ausgerichtet ist und auf einem Android 15-Gerät randlos angezeigt wird. In dieser App werden hauptsächlich Material 3 Compose-Komponenten verwendet, die automatisch Einzüge anwenden. Dieser Bildschirm ist von der Erzwingung des Vollbildmodus in Android 15 nicht negativ betroffen.

Diese nicht abwärtskompatible Änderung kann sich negativ auf die Benutzeroberfläche Ihrer App auswirken. Die Änderungen betreffen die folgenden Bereiche der Benutzeroberfläche:

  • Navigationsleiste mit Touch-Griff
    • Standardmäßig transparent.
    • Der vertikale Versatz ist deaktiviert, sodass Inhalte hinter der Navigationsleiste des Systems dargestellt werden, es sei denn, Einzüge werden angewendet.
    • setNavigationBarColor und R.attr#navigationBarColor sind eingestellt und haben keine Auswirkungen auf die Gestennavigation.
    • setNavigationBarContrastEnforced und R.attr#navigationBarContrastEnforced haben weiterhin keine Auswirkungen auf die Gestennavigation.
  • Bedienung über 3 Schaltflächen
    • Die Deckkraft ist standardmäßig auf 80% eingestellt und die Farbe entspricht möglicherweise dem Fensterhintergrund.
    • Offset am unteren Rand ist deaktiviert, sodass Inhalte hinter der Systemnavigationsleiste angezeigt werden, sofern keine Einfügungen angewendet werden.
    • setNavigationBarColor und R.attr#navigationBarColor sind standardmäßig auf den Fensterhintergrund abgestimmt. Der Fensterhintergrund muss ein farbiges Drawable sein, damit diese Standardeinstellung angewendet werden kann. Diese API wird eingestellt, hat aber weiterhin Auswirkungen auf die Navigation mit drei Schaltflächen.
    • setNavigationBarContrastEnforced und R.attr#navigationBarContrastEnforced sind standardmäßig aktiviert. Dadurch wird der Navigationsbereich mit drei Schaltflächen einen 80% opaken Hintergrund haben.
  • Statusleiste
    • Standardmäßig transparent.
    • Der obere Versatz ist deaktiviert, sodass Inhalte hinter der Statusleiste dargestellt werden, es sei denn, es werden Einzüge angewendet.
    • setStatusBarColor und R.attr#statusBarColor werden nicht mehr unterstützt und haben keine Auswirkungen auf Android 15.
    • setStatusBarContrastEnforced und R.attr#statusBarContrastEnforced sind eingestellt, wirken sich aber weiterhin auf Android 15 aus.
  • Displayausschnitt
    • layoutInDisplayCutoutMode von nicht frei schwebenden Fenstern muss LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS sein. SHORT_EDGES, NEVER und DEFAULT werden als ALWAYS interpretiert, damit Nutzer keine schwarze Leiste sehen, die durch den Displayausschnitt verursacht wird, und die Inhalte randlos angezeigt werden.

Im folgenden Beispiel wird eine App vor und nach der Ausrichtung auf Android 15 (API-Ebene 35) sowie vor und nach dem Anwenden von Einsätzen gezeigt.

Eine App, die auf Android 14 ausgerichtet ist und auf einem Android 15-Gerät nicht bildschirmfüllend ist.
Eine App, die auf Android 15 (API-Level 35) ausgerichtet ist und auf einem Gerät mit Android 15 Edge-to-Edge ist. Aufgrund der randlosen Erzwingungen von Android 15 werden jedoch viele Elemente jetzt durch die Statusleiste, die Navigationsleiste mit drei Schaltflächen oder die Display-Aussparung ausgeblendet. Die ausgeblendete Benutzeroberfläche umfasst die obere App-Leiste in Material 2, schwebende Aktionsschaltflächen und Listenelemente.
Eine App, die auf Android 15 (API-Level 35) ausgerichtet ist, auf einem Android 15-Gerät randlos angezeigt wird und Einzüge verwendet, damit die Benutzeroberfläche nicht ausgeblendet wird.
Prüfen, ob Ihre App bereits bildschirmfüllend ist

Wenn Ihre App bereits randlos ist und Einzüge verwendet, sind Sie in den folgenden Fällen davon nicht betroffen: Auch wenn Sie der Meinung sind, dass Sie nicht betroffen sind, empfehlen wir Ihnen, Ihre App zu testen.

  • Sie haben ein nicht schwebendes Fenster, z. B. ein Activity, das SHORT_EDGES, NEVER oder DEFAULT anstelle von LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS verwendet. Wenn Ihre App beim Starten abstürzt, kann das an Ihrem Splashscreen liegen. Sie können die Abhängigkeit des Core-Splashscreens auf 1.2.0-alpha01 oder höher aktualisieren oder window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always festlegen.
  • Es kann sein, dass es Bildschirme mit weniger Zugriffen gibt, auf denen die Benutzeroberfläche verdeckt ist. Prüfen Sie, ob die Benutzeroberfläche auf diesen weniger besuchten Bildschirmen nicht verdeckt ist. Beispiele für Bildschirme mit weniger Zugriffen:
    • Einrichtungs- oder Anmeldebildschirme
    • Einstellungsseiten
Was Sie prüfen sollten, wenn Ihre App noch nicht bildschirmfüllend ist

Wenn Ihre App noch nicht auf dem neuesten Stand ist, sind Sie höchstwahrscheinlich betroffen. Zusätzlich zu den Szenarien für Anwendungen, die bereits Edge-to-Edge-Anwendungen haben, sollten Sie Folgendes berücksichtigen:

  • Wenn Ihre App Material 3-Komponenten (androidx.compose.material3) beim Schreiben verwendet, z. B. TopAppBar, BottomAppBar und NavigationBar, sind diese Komponenten wahrscheinlich nicht betroffen, da sie Einfügungen automatisch verarbeiten.
  • Wenn Ihre App Material 2-Komponenten (androidx.compose.material) in Compose verwendet, verarbeiten diese Komponenten nicht automatisch Einfügungen. Sie können jedoch auf die Einleger zugreifen und sie manuell anwenden. In androidx.compose.material 1.6.0 und höher können Sie mit dem Parameter windowInsets die Einzüge manuell für BottomAppBar, TopAppBar, BottomNavigation und NavigationRail anwenden. Verwenden Sie den Parameter contentWindowInsets auch für Scaffold.
  • Wenn Ihre App Ansichten und Material Components (com.google.android.material) verwendet, werden die meisten auf Ansichten basierenden Material Components wie BottomNavigationView, BottomAppBar, NavigationRailView oder NavigationView für Einzüge verwendet und erfordern keine zusätzlichen Arbeiten. Wenn Sie AppBarLayout verwenden, müssen Sie jedoch android:fitsSystemWindows="true" hinzufügen.
  • Bei benutzerdefinierten Composeables müssen Sie die Einzüge manuell als Abstand anwenden. Wenn sich Ihr Inhalt in einem Scaffold befindet, können Sie Einfügungen mithilfe der Scaffold-Padding-Werte aufnehmen. Andernfalls können Sie mithilfe von WindowInsets ein Abstandselement hinzufügen.
  • Wenn Ihre App Ansichten und BottomSheet-, SideSheet- oder benutzerdefinierte Container verwendet, wenden Sie mit ViewCompat.setOnApplyWindowInsetsListener einen Abstand an. Wenden Sie für RecyclerView mit diesem Listener einen Abstand an und fügen Sie clipToPadding="false" hinzu.
Prüfen, ob Ihre App benutzerdefinierten Hintergrundschutz bieten muss

Wenn Ihre App einen benutzerdefinierten Hintergrundschutz für die Bedienung über 3 Schaltflächen oder die Statusleiste bieten muss, sollte in Ihrer App eine zusammensetzbare Funktion oder Ansicht hinter der Systemleiste platziert werden. Verwenden Sie dazu WindowInsets.Type#tappableElement(), um die Höhe der Navigationsleiste mit 3 Schaltflächen oder WindowInsets.Type#statusBars zu ermitteln.

Weitere Ressourcen für die Bildbearbeitung

Weitere Informationen zum Anwenden von Einfügungen finden Sie in den Leitfäden Edge to Edge View und Edge to Edge Compose.

Eingestellte APIs

Die folgenden APIs wurden verworfen, aber nicht deaktiviert:

Die folgenden APIs werden eingestellt und deaktiviert:

Stabile Konfiguration

Wenn Ihre App auf Android 15 (API-Level 35) oder höher ausgerichtet ist, werden die Systemleisten von Configuration nicht mehr ausgeschlossen. Wenn Sie die Bildschirmgröße in der Configuration-Klasse für die Layoutberechnung verwenden, sollten Sie sie je nach Bedarf durch bessere Alternativen wie ViewGroup, WindowInsets oder WindowMetricsCalculator ersetzen.

Configuration ist seit API 1 verfügbar. Sie wird normalerweise aus Activity.onConfigurationChanged abgerufen. Sie enthält Informationen wie Fensterdichte, -ausrichtung und -größe. Ein wichtiges Merkmal der von Configuration zurückgegebenen Fenstergrößen ist, dass zuvor die Systemleisten ausgeschlossen wurden.

Die Konfigurationsgröße wird in der Regel für die Ressourcenauswahl verwendet, z. B. für /res/layout-h500dp. Dies ist weiterhin ein gültiger Anwendungsfall. Es wurde jedoch immer davon abgeraten, es zur Berechnung des Layouts zu verwenden. In diesem Fall sollten Sie sich jetzt davon abwenden. Je nach Anwendungsfall sollten Sie Configuration durch einen geeigneteren Wert ersetzen.

Wenn Sie es zum Berechnen des Layouts verwenden, verwenden Sie eine geeignete ViewGroup, z. B. CoordinatorLayout oder ConstraintLayout. Wenn Sie damit die Höhe der System-Navigationsleiste festlegen möchten, verwenden Sie WindowInsets. Wenn Sie die aktuelle Größe Ihres App-Fensters ermitteln möchten, verwenden Sie computeCurrentWindowMetrics.

In der folgenden Liste werden die Felder beschrieben, die von dieser Änderung betroffen sind:

Das Attribut „elegantTextHeight“ hat standardmäßig den Wert „true“.

对于以 Android 15 为目标平台的应用,elegantTextHeight TextView 属性默认变为 true,将默认使用的紧凑字体替换为一些具有较大垂直指标的脚本,并且这种字体更易于阅读。紧凑字体的引入是为了防止破坏布局;Android 13(API 级别 33)允许文本布局利用 fallbackLineSpacing 属性拉伸垂直高度,以防止许多此类破坏。

在 Android 15 中,紧凑字体仍保留在系统中,因此您的应用可以将 elegantTextHeight 设置为 false,以获得与之前相同的行为,但即将在未来版本中提供支持。因此,如果您的应用支持以下文字:阿拉伯语、老挝语、缅甸、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语,请将 elegantTextHeight 设置为 true,以测试应用。

以 Android 14(API 级别 34)及更低版本为目标平台的应用的 elegantTextHeight 行为。
以 Android 15 为目标平台的应用的 elegantTextHeight 行为。

Breite des TextViews ändert sich bei komplexen Buchstabenformen

In früheren Android-Versionen wurden bei einigen Schriftarten mit Kurrentschrift oder Sprachen mit komplexer Schriftbildgestaltung die Buchstaben möglicherweise im Bereich des vorherigen oder nächsten Zeichens gezeichnet. In einigen Fällen wurden solche Buchstaben am Anfang oder Ende abgeschnitten. Ab Android 15 weist eine TextView eine Breite zu, um genügend Platz für solche Buchstaben zu erhalten. Außerdem können Apps auf der linken Seite zusätzliche Abstände anfordern, um das Abschneiden zu verhindern.

Da sich diese Änderung darauf auswirkt, wie TextView die Breite festlegt, weist TextView standardmäßig mehr Breite zu, wenn die App auf Android 15 (API-Level 35) oder höher ausgerichtet ist. Sie können dieses Verhalten aktivieren oder deaktivieren, indem Sie die setUseBoundsForWidth API auf TextView aufrufen.

Da das Hinzufügen eines linken Abstands zu einer Fehlausrichtung bestehender Layouts führen kann, wird der Abstand auch bei Apps, die auf Android 15 oder höher ausgerichtet sind, nicht standardmäßig hinzugefügt. Sie können jedoch zusätzliche Abstände hinzufügen, um ein Abschneiden zu verhindern. Rufen Sie dazu setShiftDrawingOffsetForStartOverhang auf.

Die folgenden Beispiele zeigen, wie sich diese Änderungen auf das Textlayout für bestimmte Schriftarten und Sprachen auswirken können.

Standardlayout für englischen Text in einer Schreibschrift. Einige Buchstaben sind abgeschnitten. Hier ist der entsprechende XML-Code:

<TextView
    android:fontFamily="cursive"
    android:text="java" />
Layout für denselben englischen Text mit zusätzlicher Breite und Rändern. Hier ist die entsprechende XML-Datei:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />
Standardlayout für thailändischen Text Einige Buchstaben sind abgeschnitten. Hier ist die entsprechende XML-Datei:

<TextView
    android:text="คอมพิวเตอร์" />
Layout für denselben thailändischen Text mit zusätzlicher Breite und zusätzlichem Abstand. Hier ist der entsprechende XML-Code:

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Localespezifische Standardzeilenhöhe für EditText

在以前的 Android 版本中,文本布局拉伸了文本的高度,使其适应与当前语言区域匹配的字体的行高。例如,如果内容是日语,由于日语字体的行高比拉丁字体的行高略大,因此文本的高度就略大了。不过,尽管行高存在这些差异,但无论使用何种语言区域,EditText 元素的大小都是一致的,如下图所示:

三个表示 EditText 元素的框,这些框可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 的文本。EditText 的高度相同,即使这两种语言的行高不同。

对于以 Android 15 为目标平台的应用,系统现在会为 EditText 预留最小行高,以匹配指定语言区域的参考字体,如下图所示:

三个表示 EditText 元素的框,这些框可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 的文本。EditText 的高度现在包含空间,可适应这些语言字体的默认行高。

如果需要,您的应用可以通过将 useLocalePreferredLineHeightForMinimum 属性设置为 false 来恢复之前的行为,并且可以通过 Kotlin 和 Java 中的 setMinimumFontMetrics API 设置自定义最小行业指标。

Kamera und Medien

Unter Android 15 werden die folgenden Änderungen am Kamera- und Medienverhalten für Apps vorgenommen, die auf Android 15 oder höher ausgerichtet sind.

Einschränkungen beim Anfordern des Audiofokus

Apps, die auf Android 15 ausgerichtet sind, müssen die Top-App sein oder einen Dienst im Vordergrund ausführen, damit der Audiofokus angefordert werden kann. Wenn eine App versucht, den Fokus anzufordern, obwohl sie eine dieser Anforderungen nicht erfüllt, gibt der Aufruf AUDIOFOCUS_REQUEST_FAILED zurück.

Weitere Informationen zum Audiofokus finden Sie unter Audiofokus verwalten.

Aktualisierte Einschränkungen für Nicht-SDKs

Android 15 包含更新后的受限非 SDK 接口列表(基于与 Android 开发者之间的协作以及最新的内部测试)。在限制使用非 SDK 接口之前,我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 15 为目标平台,其中一些变更可能不会立即对您产生影响。不过,尽管您的应用可能会根据应用的目标 API 级别访问某些非 SDK 接口,但只要您使用任何非 SDK 方法或字段,终归存在导致应用出问题的显著风险。

如果您不确定自己的应用是否使用了非 SDK 接口,则可以测试该应用,进行确认。如果您的应用依赖于非 SDK 接口,您应该开始计划迁移到 SDK 替代方案。不过,我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案,则应请求新的公共 API

Weitere Informationen zu den Änderungen in dieser Android-Version finden Sie unter Änderungen an den Einschränkungen für nicht SDK-spezifische Oberflächen in Android 15. Weitere Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.