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

Mit Android 15 nehmen wir die folgenden Änderungen an Diensten im Vordergrund vor.

Zeitüberschreitung des Diensts „Datensynchronisierung im Vordergrund“

对于以 Android 15（API 级别 35）或更高版本为目标平台的应用，Android 15 为 dataSync 引入了新的超时行为。此行为也适用于新的 mediaProcessing 前台服务类型。

系统允许应用的 dataSync 服务在 24 小时内共运行 6 小时，之后系统会调用正在运行的服务的 Service.onTimeout(int, int) 方法（在 Android 15 中引入）。此时，服务有几秒钟的时间来调用 Service.stopSelf()。调用 Service.onTimeout() 后，该服务将不再被视为前台服务。如果服务未调用 Service.stopSelf()，系统会抛出内部异常。系统会在 Logcat 中记录此异常，并显示以下消息：

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

为避免此行为变更出现问题，您可以执行以下一项或多项操作：

  1. 让您的服务实现新的 Service.onTimeout(int, int) 方法。当应用收到回调时，请务必在几秒钟内调用 stopSelf()。（如果您不立即停止应用，系统会生成故障。）
  2. 确保应用的 dataSync 服务在任何 24 小时内总运行时间不超过 6 小时（除非用户与应用互动，重置计时器）。
  3. 仅在有直接用户互动时启动 dataSync 前台服务；由于服务启动时应用位于前台，因此您的服务在应用进入后台后有完整的 6 小时时间。
  4. 请使用替代 API，而不是使用 dataSync 前台服务。

如果您的应用的 dataSync 前台服务在过去 24 小时内运行了 6 小时，则您无法启动其他 dataSync 前台服务，除非用户已将您的应用切换到前台（这会重置计时器）。如果您尝试启动其他 dataSync 前台服务，系统会抛出 ForegroundServiceStartNotAllowedException，并显示类似“前台服务类型 dataSync 的时间限制已用尽”的错误消息。

测试

如需测试应用的行为，即使您的应用并非以 Android 15 为目标平台（只要该应用在 Android 15 设备上运行），您也可以启用数据同步超时。如需启用超时，请运行以下 adb 命令：

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

您还可以调整超时期限，以便更轻松地测试应用在达到上限时的行为方式。如需设置新的超时期限，请运行以下 adb 命令：

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

Neuer Typ für Dienste im Vordergrund zur Medienverarbeitung

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 hat

Bisher konnte eine App mit der Berechtigung SYSTEM_ALERT_WINDOW einen Dienst im Vordergrund starten, auch wenn sie sich gerade im Hintergrund befand (wie unter Ausnahmen von Einschränkungen beim Starten im Hintergrund beschrieben).

Wenn eine App auf Android 15 ausgerichtet ist, ist diese Ausnahme jetzt eingeschränkter. Die App benötigt jetzt die Berechtigung SYSTEM_ALERT_WINDOW und auch ein sichtbares Overlay-Fenster. Das bedeutet, dass die App zuerst ein TYPE_APPLICATION_OVERLAY-Fenster öffnen und das Fenster sichtbar sein muss, bevor Sie einen Dienst im Vordergrund starten.

Wenn Ihre App versucht, einen Dienst im Vordergrund aus dem Hintergrund zu starten, ohne diese neuen Anforderungen zu erfüllen (und keine andere Ausnahme vorliegt), löst das System ForegroundServiceStartNotAllowedException aus.

Wenn Ihre App die Berechtigung SYSTEM_ALERT_WINDOW deklariert und Dienste im Vordergrund aus dem Hintergrund startet, kann sich diese Änderung auf Ihre App auswirken. Wenn deine App eine ForegroundServiceStartNotAllowedException erhält, prüfe die Reihenfolge der Vorgänge in deiner App und achte darauf, dass deine App bereits ein aktives Overlay-Fenster hat, bevor sie versucht, einen Dienst im Vordergrund im Hintergrund zu starten. Du kannst mit View.getWindowVisibility() prüfen, ob dein Overlay-Fenster gerade sichtbar ist. Du kannst auch View.onWindowVisibilityChanged() überschreiben, um benachrichtigt zu werden, wenn sich die Sichtbarkeit ändert.

Testen

Um das Verhalten deiner App zu testen, kannst du diese neuen Einschränkungen auch dann aktivieren, wenn deine App nicht auf Android 15 ausgerichtet ist, solange sie auf einem Android 15-Gerät ausgeführt wird. Wenn Sie diese neuen Einschränkungen für den Start von Diensten im Vordergrund aus dem Hintergrund aktivieren möchten, führen Sie den folgenden adb-Befehl aus:

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

Apps that target Android 15 (API level 35) and higher can no longer change the global state or policy of Do Not Disturb (DND) on a device (either by modifying user settings, or turning off DND mode). Instead, apps must contribute an AutomaticZenRule, which the system combines into a global policy with the existing most-restrictive-policy-wins scheme. Calls to existing APIs that previously affected global state (setInterruptionFilter, setNotificationPolicy) result in the creation or update of an implicit AutomaticZenRule, which is toggled on and off depending on the call-cycle of those API calls.

Note that this change only affects observable behavior if the app is calling setInterruptionFilter(INTERRUPTION_FILTER_ALL) and expects that call to deactivate an AutomaticZenRule that was previously activated by their owners.

Änderungen an der OpenJDK API

In Android 15 werden die Kernbibliotheken von Android weiter aktualisiert, um sie an die Funktionen der neuesten OpenJDK-LTS-Releases anzupassen.

Einige dieser Änderungen können sich auf die App-Kompatibilität für Apps auswirken, die auf Android 15 (API-Level 35) ausgerichtet sind:

  • Änderungen an APIs für die Stringformatierung: Die Validierung von Argumentindex, Flags, Breite und Genauigkeit ist jetzt bei der Verwendung der folgenden String.format()- und Formatter.format()-APIs strenger:

    Beispielsweise wird die folgende Ausnahme geworfen, wenn der Argumentindex 0 verwendet wird (%0 im Formatstring):

    IllegalFormatArgumentIndexException: Illegal format argument index = 0

    In diesem Fall kann das Problem durch Verwendung eines Argumentindexes von 1 (%1 im Formatstring) behoben werden.

  • Änderungen am Komponententyp von Arrays.asList(...).toArray(): Bei Verwendung von Arrays.asList(...).toArray() ist der Komponententyp des resultierenden Arrays jetzt ein Object – nicht der Typ der Elemente des zugrunde liegenden Arrays. Der folgende Code führt daher zu einem ClassCastException:

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

    Wenn Sie in diesem Fall String als Komponententyp im resultierenden Array beibehalten möchten, können Sie stattdessen Collection.toArray(Object[]) verwenden:

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

  • Änderungen bei der Verarbeitung von Sprachcodes: Bei der Verwendung der Locale API werden Sprachcodes für Hebräisch, Jiddisch und Indonesisch nicht mehr in ihre veralteten Formen umgewandelt (Hebräisch: iw, Jiddisch: ji und Indonesisch: in). Geben Sie den Sprachcode für eine dieser Sprachen stattdessen mit den Codes aus ISO 639-1 an (Hebräisch: he, Jiddisch: yi und Indonesisch: id).

  • Änderungen an Zufallszahlenfolgen: Aufgrund der Änderungen unter https://bugs.openjdk.org/browse/JDK-8301574 geben die folgenden Random.ints()-Methoden jetzt eine andere Zahlenfolge zurück als die Random.nextInt()-Methoden:

    Im Allgemeinen sollte diese Änderung nicht zu einem Absturz der App führen. Ihr Code sollte jedoch nicht davon ausgehen, dass die von Random.ints()-Methoden generierte Sequenz mit Random.nextInt() übereinstimmt.

Die neue SequencedCollection API kann sich auf die Kompatibilität Ihrer App auswirken, nachdem Sie compileSdk in der Build-Konfiguration Ihrer App auf Android 15 (API-Level 35) aktualisiert haben:

  • Überschneidung mit den Erweiterungsfunktionen MutableList.removeFirst() und MutableList.removeLast() in kotlin-stdlib

    Der Typ List in Java wird dem Typ MutableList in Kotlin zugeordnet. Da die APIs List.removeFirst() und List.removeLast() in Android 15 (API-Ebene 35) eingeführt wurden, löst der Kotlin-Compiler Funktionsaufrufe wie list.removeFirst() statisch auf die neuen List APIs statt auf die Erweiterungsfunktionen in kotlin-stdlib auf.

    Wenn eine App neu kompiliert wird, wobei compileSdk auf 35 und minSdk auf 34 oder niedriger festgelegt ist, und dann auf Android 14 oder niedriger ausgeführt wird, wird ein Laufzeitfehler ausgegeben:

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

    Mit der vorhandenen NewApi-Lint-Option im Android Gradle-Plug-in können diese neuen API-Nutzungen erkannt werden.

    ./gradlew lint

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

    Um die Laufzeitausnahme und die Lint-Fehler zu beheben, können die Funktionsaufrufe removeFirst() und removeLast() in Kotlin durch removeAt(0) und removeAt(list.lastIndex) ersetzt werden. Wenn Sie Android Studio Ladybug | 2024.1.3 oder höher verwenden, können Sie diese Fehler auch schnell beheben.

    Entfernen Sie @SuppressLint("NewApi") und lintOptions { disable 'NewApi' }, wenn die Lint-Option deaktiviert wurde.

  • Überschneidung mit anderen Methoden in Java

    Den vorhandenen Typen wurden neue Methoden hinzugefügt, z. B. List und Deque. Diese neuen Methoden sind möglicherweise nicht mit den Methoden mit demselben Namen und denselben Argumenttypen in anderen Schnittstellen und Klassen kompatibel. Bei einer Kollision der Methodensignatur mit Inkompatibilität gibt der javac-Compiler einen Buildzeitfehler aus. Beispiel:

    Beispiel für Fehler 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

    Beispiel für Fehlermeldung 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

    Beispiel für Fehler 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

    Um diese Buildfehler zu beheben, sollte die Klasse, die diese Schnittstellen implementiert, die Methode mit einem kompatiblen Rückgabetyp überschreiben. Beispiel:

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

Sicherheit

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

Eingeschränkte TLS-Versionen

Unter Android 15 ist die Verwendung der TLS-Versionen 1.0 und 1.1 eingeschränkt. Diese Versionen wurden bereits in Android eingestellt, sind aber jetzt für Apps, die auf Android 15 ausgerichtet sind, nicht mehr zulässig.

Start von sicheren Hintergrundaktivitäten

Android 15 protects users from malicious apps and gives them more control over their devices by adding changes that prevent malicious background apps from bringing other apps to the foreground, elevating their privileges, and abusing user interaction. Background activity launches have been restricted since Android 10 (API level 29).

Other changes

In addition to the restriction for UID matching, these other changes are also included:

  • Change PendingIntent creators to block background activity launches by default. This helps prevent apps from accidentally creating a PendingIntent that could be abused by malicious actors.
  • Don't bring an app to the foreground unless the PendingIntent sender allows it. This change aims to prevent malicious apps from abusing the ability to start activities in the background. By default, apps are not allowed to bring the task stack to the foreground unless the creator allows background activity launch privileges or the sender has background activity launch privileges.
  • Control how the top activity of a task stack can finish its task. If the top activity finishes a task, Android will go back to whichever task was last active. Moreover, if a non-top activity finishes its task, Android will go back to the home screen; it won't block the finish of this non-top activity.
  • Prevent launching arbitrary activities from other apps into your own task. This change prevents malicious apps from phishing users by creating activities that appear to be from other apps.
  • Block non-visible windows from being considered for background activity launches. This helps prevent malicious apps from abusing background activity launches to display unwanted or malicious content to users.

Sicherere Absichten

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

Nutzerfreundlichkeit und Systemoberfläche

Android 15 enthält einige Änderungen, die eine einheitlichere und intuitivere Nutzererfahrung schaffen sollen.

Änderungen am Fenstereinzug

In Android 15 gibt es zwei Änderungen im Zusammenhang mit Fenstereinblendungen: Vollbild wird standardmäßig erzwungen. Außerdem gibt es Konfigurationsänderungen, z. B. an der Standardkonfiguration der Systemleisten.

Edge-to-Edge-Erzwingung

Apps are edge-to-edge by default on devices running Android 15 if the app is targeting Android 15 (API level 35).

An app that targets Android 14 and is not edge-to-edge on an Android 15 device.


An app that targets Android 15 (API level 35) and is edge-to-edge on an Android 15 device. This app mostly uses Material 3 Compose Components that automatically apply insets. This screen is not negatively impacted by the Android 15 edge-to-edge enforcement.

This is a breaking change that might negatively impact your app's UI. The changes affect the following UI areas:

  • Gesture handle navigation bar
    • Transparent by default.
    • Bottom offset is disabled so content draws behind the system navigation bar unless insets are applied.
    • setNavigationBarColor and R.attr#navigationBarColor are deprecated and don't affect gesture navigation.
    • setNavigationBarContrastEnforced and R.attr#navigationBarContrastEnforced continue to have no effect on gesture navigation.
  • 3-button navigation
    • Opacity set to 80% by default, with color possibly matching the window background.
    • Bottom offset disabled so content draws behind the system navigation bar unless insets are applied.
    • setNavigationBarColor and R.attr#navigationBarColor are set to match the window background by default. The window background must be a color drawable for this default to apply. This API is deprecated but continues to affect 3-button navigation.
    • setNavigationBarContrastEnforced and R.attr#navigationBarContrastEnforced is true by default, which adds an 80% opaque background across 3-button navigation.
  • Status bar
    • Transparent by default.
    • The top offset is disabled so content draws behind the status bar unless insets are applied.
    • setStatusBarColor and R.attr#statusBarColor are deprecated and have no effect on Android 15.
    • setStatusBarContrastEnforced and R.attr#statusBarContrastEnforced are deprecated but still have an effect on Android 15.
  • Display cutout
    • layoutInDisplayCutoutMode of non-floating windows must be LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. SHORT_EDGES, NEVER, and DEFAULT are interpreted as ALWAYS so that users don't see a black bar caused by the display cutout and appear edge-to-edge.

The following example shows an app before and after targeting Android 15 (API level 35), and before and after applying insets.

An app that targets Android 14 and is not edge-to-edge on an Android 15 device.
An app that targets Android 15 (API level 35) and is edge-to-edge on an Android 15 device. However, many elements are now hidden by the status bar, 3-button navigation bar, or display cutout due to the Android 15 edge-to-edge enforcements. Hidden UI includes the Material 2 top app bar, floating action buttons, and list items.
An app that targets Android 15 (API level 35), is edge to edge on an Android 15 device and applies insets so that UI is not hidden.
What to check if your app is already edge-to-edge

If your app is already edge-to-edge and applies insets, you are mostly unimpacted, except in the following scenarios. However, even if you think you aren't impacted, we recommend you test your app.

  • You have a non-floating window, such as an Activity that uses SHORT_EDGES, NEVER or DEFAULT instead of LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. If your app crashes on launch, this might be due to your splashscreen. You can either upgrade the core splashscreen dependency to 1.2.0-alpha01 or later or set window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always.
  • There might be lower-traffic screens with occluded UI. Verify these less-visited screens don't have occluded UI. Lower-traffic screens include:
    • Onboarding or sign-in screens
    • Settings pages
What to check if your app is not already edge-to-edge

If your app is not already edge-to-edge, you are most likely impacted. In addition to the scenarios for apps that are already edge-to-edge, you should consider the following:

  • If your app uses Material 3 Components ( androidx.compose.material3) in compose, such as TopAppBar, BottomAppBar, and NavigationBar, these components are likely not impacted because they automatically handle insets.
  • If your app is using Material 2 Components ( androidx.compose.material) in Compose, these components don't automatically handle insets. However, you can get access to the insets and apply them manually. In androidx.compose.material 1.6.0 and later, use the windowInsets parameter to apply the insets manually for BottomAppBar, TopAppBar, BottomNavigation, and NavigationRail. Likewise, use the contentWindowInsets parameter for Scaffold.
  • If your app uses views and Material Components (com.google.android.material), most views-based Material Components such as BottomNavigationView, BottomAppBar, NavigationRailView, or NavigationView, handle insets and require no additional work. However, you need to add android:fitsSystemWindows="true" if using AppBarLayout.
  • For custom composables, apply the insets manually as padding. If your content is within a Scaffold, you can consume insets using the Scaffold padding values. Otherwise, apply padding using one of the WindowInsets.
  • If your app is using views and BottomSheet, SideSheet or custom containers, apply padding using ViewCompat.setOnApplyWindowInsetsListener. For RecyclerView, apply padding using this listener and also add clipToPadding="false".
What to check if your app must offer custom background protection

If your app must offer custom background protection to 3-button navigation or the status bar, your app should place a composable or view behind the system bar using WindowInsets.Type#tappableElement() to get the 3-button navigation bar height or WindowInsets.Type#statusBars.

Additional edge-to-edge resources

See the Edge to Edge Views and Edge to Edge Compose guides for additional considerations on applying insets.

Deprecated APIs

The following APIs are deprecated but not disabled:

The following APIs are deprecated and disabled:

Stabile Konfiguration

If your app targets Android 15 (API level 35) or higher, Configuration no longer excludes the system bars. If you use the screen size in the Configuration class for layout calculation, you should replace it with better alternatives like an appropriate ViewGroup, WindowInsets, or WindowMetricsCalculator depending on your need.

Configuration has been available since API 1. It is typically obtained from Activity.onConfigurationChanged. It provides information like window density, orientation, and sizes. One important characteristic about the window sizes returned from Configuration is that it previously excluded the system bars.

The configuration size is typically used for resource selection, such as /res/layout-h500dp, and this is still a valid use case. However, using it for layout calculation has always been discouraged. If you do so, you should move away from it now. You should replace the use of Configuration with something more suitable depending on your use case.

If you use it to calculate the layout, use an appropriate ViewGroup, such as CoordinatorLayout or ConstraintLayout. If you use it to determine the height of the system navbar, use WindowInsets. If you want to know the current size of your app window, use computeCurrentWindowMetrics.

The following list describes the fields affected by this change:

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

对于以 Android 15（API 级别 35）为目标平台的应用，elegantTextHeight TextView 属性默认会变为 true，将默认使用的紧凑字体替换为一些具有较大垂直测量的脚本，使其更易于阅读。紧凑字体旨在防止布局中断；Android 13（API 级别 33）允许文本布局利用 fallbackLineSpacing 属性拉伸垂直高度，从而防止许多此类中断。

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

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

Breite von TextViews ändert sich bei komplexen Buchstabenformen

在以前的 Android 版本中，某些具有复杂形状的手写字体或语言可能会在上一个或下一个字符的区域绘制字母。在某些情况下，此类字母会在开头或结尾处被剪裁。从 Android 15 开始，TextView 会分配宽度，以便为此类字母绘制足够的空间，并允许应用请求向左额外添加内边距以防止剪裁。

由于此更改会影响 TextView 确定宽度的方式，因此如果应用以 Android 15（API 级别 35）或更高版本为目标平台，TextView 会默认分配更多宽度。您可以通过对 TextView 调用 setUseBoundsForWidth API 来启用或停用此行为。

由于添加左内边距可能会导致现有布局未对齐，因此默认情况下不会添加内边距，即使以 Android 15 或更高版本为目标平台的应用也是如此。不过，您可以通过调用 setShiftDrawingOffsetForStartOverhang 添加额外的内边距以防止剪裁。

以下示例展示了这些更改如何改进某些字体和语言的文本布局。

采用手写体字体的英语文本的标准布局。部分字母被截断。对应的 XML 如下：

<TextView
    android:fontFamily="cursive"
    android:text="java" />
相同英语文本的布局，增加了宽度和内边距。以下是相应的 XML：

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />
泰语文本的标准布局。部分字母被截断。 以下是相应的 XML：

<TextView
    android:text="คอมพิวเตอร์" />
相同泰语文本的布局，增加了宽度和内边距。以下是相应的 XML：

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

Gebietsschema-sensitive Standardzeilenhöhe für EditText

In previous versions of Android, the text layout stretched the height of the text to meet the line height of the font that matched the current locale. For example, if the content was in Japanese, because the line height of the Japanese font is slightly larger than the one of a Latin font, the height of the text became slightly larger. However, despite these differences in line heights, the EditText element was sized uniformly, regardless of the locale being used, as illustrated in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText is the same, even though these languages have different line heights from each other.

For apps targeting Android 15 (API level 35), a minimum line height is now reserved for EditText to match the reference font for the specified Locale, as shown in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText now includes space to accommodate the default line height for these languages' fonts.

If needed, your app can restore the previous behavior by specifying the useLocalePreferredLineHeightForMinimum attribute to false, and your app can set custom minimum vertical metrics using the setMinimumFontMetrics API in Kotlin and Java.

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 (API-Level 35) ausgerichtet sind, müssen die oberste App sein oder einen Dienst im Vordergrund ausführen, um den Audiofokus anfordern zu können. Wenn eine App versucht, den Fokus anzufordern, ohne eine dieser Anforderungen zu erfüllen, 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 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 15, some of these changes might not immediately affect you. However, while it's possible for your app to access some non-SDK interfaces depending on your app's target API level, using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you can't find an alternative to using a non-SDK interface for a feature in your app, you should request a new public 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.