Änderungen beim Verhalten: Apps, die auf Android 15 oder höher ausgerichtet sind

Wie bei früheren Releases umfasst Android 15 Verhaltensänderungen, die sich auf für Ihre App. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps, die die auf Android 15 oder höher ausgerichtet sind. Wenn deine App auf Android 15 oder höher ausgerichtet ist, sollten Sie Ihre App an diese Verhaltensweisen anpassen, wobei zutreffend sind.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die alle Apps betreffen die Android 15 ausgeführt wird, unabhängig von der targetSdkVersion Ihrer App.

Hauptfunktion

Mit Android 15 werden verschiedene Hauptfunktionen des Android-Systems modifiziert oder erweitert.

Änderungen an Diensten im Vordergrund

我们将在 Android 15 中对前台服务进行以下更改。

数据同步前台服务超时行为

Mit Android 15 wird dataSync für App-Targeting ein neues Verhalten bei Zeitüberschreitungen eingeführt Android 15 (API-Level 35) oder höher Dies gilt auch für das neue mediaProcessing-Typ des Dienstes im Vordergrund.

Das System lässt die Ausführung der dataSync-Dienste einer App für insgesamt 6 Stunden zu innerhalb von 24 Stunden. Danach ruft das System die Methode Service.onTimeout(int, int) (in Android eingeführt) 15). Derzeit hat der Dienst einige Sekunden Zeit, um anzurufen Service.stopSelf() Wenn Service.onTimeout() aufgerufen wird, gilt nicht mehr als Dienst im Vordergrund. Wenn der Dienst nicht Service.stopSelf() aufrufen, gibt das System eine interne Ausnahme aus. Die 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]"

Um Probleme mit dieser Verhaltensänderung zu vermeiden, können Sie einen oder mehrere der Folgendes:

  1. Lassen Sie Ihren Dienst die neue Service.onTimeout(int, int)-Methode implementieren. Wenn deine App den Callback empfängt, musst du stopSelf() innerhalb einer ein paar Sekunden. Wenn Sie die App nicht sofort beenden, erstellt das System eine Fehler.)
  2. Achte darauf, dass die dataSync-Dienste deiner App nicht länger als insgesamt ausgeführt werden 6 Stunden innerhalb von 24 Stunden (es sei denn, der Nutzer interagiert mit der App, Timer zurücksetzen).
  3. Aufgrund des direkten Nutzers nur dataSync Dienste im Vordergrund starten Interaktion; da Ihre App beim Start des Dienstes im Vordergrund ausgeführt wird, hat Ihr Dienst die vollen sechs Stunden, nachdem die App in den Hintergrund gewechselt ist.
  4. Verwenden Sie anstelle eines dataSync-Dienstes im Vordergrund einen alternative API.

Wenn die dataSync Dienste im Vordergrund Ihrer App in den letzten 6 Stunden 24, können Sie keinen weiteren dataSync-Dienst im Vordergrund starten, es sei denn, der Nutzer Ihre App in den Vordergrund gebracht hat, wodurch der Timer zurückgesetzt wird. Wenn Sie versuchen, einen dataSync-Dienst im Vordergrund startet, ForegroundServiceStartNotAllowedException mit einer Fehlermeldung wie „Das Zeitlimit für den Dienst im Vordergrund wurde bereits ausgeschöpft“ angezeigt. geben Sie „dataSync“ ein.

Testen

Um das Verhalten Ihrer App zu testen, können Sie Zeitüberschreitungen für die Datensynchronisierung aktivieren, auch wenn Ihre App nicht auf Android 15 ausgerichtet ist (sofern die App auf einem Gerät). Führen Sie den folgenden adb-Befehl 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, damit Sie einfacher testen können, Das Verhalten der Anwendung verhält sich, wenn das Limit erreicht ist. Um ein neues Zeitlimit festzulegen, führen Sie den folgenden adb-Befehl:

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

新建媒体处理前台服务类型

Mit Android 15 wird ein neuer Typ von Diensten im Vordergrund eingeführt: mediaProcessing. Dieses Diensttyp eignet sich für Vorgänge wie das Transcodieren von Mediendateien. Für Eine Medien-App könnte z. B. eine Audiodatei herunterladen und sie in ein in einem anderen Format ansehen. Du kannst einen mediaProcessing-Vordergrund verwenden um sicherzustellen, dass die Conversion auch dann fortgesetzt wird, wenn sich die App im Hintergrund.

Das System lässt zu, dass die mediaProcessing-Dienste einer App insgesamt 6 Mal ausgeführt werden. innerhalb von 24 Stunden. Danach ruft das System die Methode Service.onTimeout(int, int) (in Android eingeführt) 15). Derzeit hat der Dienst einige Sekunden Zeit, um anzurufen Service.stopSelf() Wenn der Dienst nicht Service.stopSelf() aufrufen, gibt das System eine interne Ausnahme aus. Die 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]"

Führen Sie einen der folgenden Schritte aus, um diese Ausnahme zu vermeiden:

  1. Lassen Sie Ihren Dienst die neue Service.onTimeout(int, int)-Methode implementieren. Wenn deine App den Callback empfängt, musst du stopSelf() innerhalb einer ein paar Sekunden. Wenn Sie die App nicht sofort beenden, erstellt das System eine Fehler.)
  2. Die mediaProcessing-Dienste deiner App dürfen höchstens Summe von 6 Stunden innerhalb von 24 Stunden (es sei denn, der Nutzer interagiert mit der App, Timer zurücksetzen).
  3. Aufgrund des direkten Nutzers nur mediaProcessing Dienste im Vordergrund starten Interaktion; da Ihre App beim Start des Dienstes im Vordergrund ausgeführt wird, 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 6 Stunden lang in der den letzten 24 $, können Sie keinen mediaProcessing-Dienst im Vordergrund starten, es sei denn, der Nutzer Ihre App in den Vordergrund gebracht hat, wodurch der Timer zurückgesetzt wird. Wenn Sie einen anderen mediaProcessing-Dienst im Vordergrund zu starten, ForegroundServiceStartNotAllowedException mit einer Fehlermeldung wie „Das Zeitlimit für den Dienst im Vordergrund wurde bereits ausgeschöpft“ angezeigt. geben Sie mediaProcessing ein.

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

Testen

Um das Verhalten Ihrer App zu testen, können Sie Zeitüberschreitungen bei der Medienverarbeitung aktivieren, selbst wenn deine App nicht auf Android 15 ausgerichtet ist (sofern die App auf einem Android 15-Gerät). Führen Sie den folgenden adb-Befehl 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, damit Sie einfacher testen können, Das Verhalten der Anwendung verhält sich, wenn das Limit erreicht ist. Um ein neues Zeitlimit festzulegen, führen Sie den folgenden adb-Befehl:

adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds

对启动前台服务的 BOOT_COMPLETED 广播接收器实施限制

在启动 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

限制在应用拥有 SYSTEM_ALERT_WINDOW 权限时启动前台服务

Bisher konnte eine App mit der Berechtigung SYSTEM_ALERT_WINDOW gestartet werden. auch wenn die App derzeit im Hintergrund ausgeführt wurde (als die unter Ausnahmen von Einschränkungen beim Start im Hintergrund erläutert werden.

Wenn eine App auf Android 15 ausgerichtet ist, ist diese Ausnahme jetzt enger gefasst. Die App benötigt jetzt um die Berechtigung SYSTEM_ALERT_WINDOW zu haben und auch ein sichtbares Overlay zu haben . Das heißt, die App muss zuerst eine TYPE_APPLICATION_OVERLAY Fenster und das Fenster muss sichtbar sein, bevor Sie einen Dienst im Vordergrund starten.

Wenn Ihre App versucht, einen Dienst im Vordergrund aus dem Hintergrund zu starten, die diese neuen Anforderungen erfüllen (und es gibt keine andere Ausnahme), System gibt ForegroundServiceStartNotAllowedException aus.

Wenn in Ihrer App die Berechtigung SYSTEM_ALERT_WINDOW deklariert ist und startet Dienste im Vordergrund aus dem Hintergrund. ändern können. Wenn deine App eine ForegroundServiceStartNotAllowedException erhält, prüfe Reihenfolge der Vorgänge Ihrer App und achten Sie darauf, dass Ihre App bereits über eine aktive um einen Dienst im Vordergrund aus dem Hintergrund. Sie können überprüfen, ob das Overlay-Fenster derzeit sichtbar ist. indem du View.getWindowVisibility() anrufst oder du kann View.onWindowVisibilityChanged() überschreiben , um bei Änderungen der Sichtbarkeit benachrichtigt zu werden.

Testen

Um das Verhalten Ihrer App zu testen, können Sie diese neuen Einschränkungen auch dann aktivieren, wenn Ihre Die App ist nicht auf Android 15 ausgerichtet (sofern sie auf einem Android 15-Gerät läuft) Gerät). Um diese neuen Einschränkungen beim Starten von Diensten im Vordergrund zu aktivieren im Hintergrund führen Sie den folgenden adb-Befehl aus:

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

Änderungen daran, wann Apps den globalen Status des Modus „Bitte nicht stören“ ändern können

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

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

OpenJDK API-Änderungen

Unter Android 15 werden die Kernbibliotheken von Android weiter aktualisiert, um sie aufeinander abzustimmen. mit den Funktionen der aktuellen OpenJDK LTS-Releases.

Einige dieser Änderungen können sich auf die Kompatibilität von Apps mit Ausrichtung auf Apps auswirken Android 15 (API-Level 35):

  • Änderungen an APIs zur Stringformatierung: Validierung von Argumentindex, Flags, Breite und Genauigkeit sind jetzt strenger bei Verwendung von String.format() und Formatter.format() API:

    Die folgende Ausnahme wird beispielsweise ausgelöst, wenn ein Argumentindex von 0 verwendet wird (%0 im Formatstring):

    IllegalFormatArgumentIndexException: Illegal format argument index = 0

    In diesem Fall kann das Problem mit einem Argumentindex von 1 (%1) behoben werden. in der Formatzeichenfolge).

  • Änderungen am Komponententyp von Arrays.asList(...).toArray(): bei Verwendung Arrays.asList(...).toArray() ist der Komponententyp des resultierenden Arrays jetzt ein Object-Element, nicht den Typ der Elemente des zugrunde liegenden Arrays. Die Funktion Der folgende Code löst eine ClassCastException aus:

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

    Um in diesem Fall String als Komponententyp in der resultierenden Array verwenden, 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 Verwendung der Locale API: Die Sprachcodes für Hebräisch, Jiddisch und Indonesisch werden nicht mehr konvertiert. in ihre veralteten Formen (Hebräisch: iw, Jiddisch: ji und Indonesisch: in). Verwenden Sie bei der Angabe des Sprachcodes für eines dieser Gebiete die Codes aus ISO 639-1 (Hebräisch: he, Jiddisch: yi und Indonesisch: id).

  • Änderungen an zufälligen int-Sequenzen: Die Änderungen in https://bugs.openjdk.org/browse/JDK-8301574, der folgende Random.ints()-Methoden geben jetzt eine andere Zahlenfolge zurück als Die Random.nextInt()-Methoden bieten Folgendes:

    Generell sollte diese Änderung nicht zum Absturz von Apps führen, Code sollte nicht die von Random.ints()-Methoden generierte Sequenz erwarten, Übereinstimmung mit Random.nextInt().

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

  • Kollision mit MutableList.removeFirst() und MutableList.removeLast()-Erweiterungsfunktionen 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-Level 35) eingeführt. Der Kotlin-Compiler löst Funktionsaufrufe wie list.removeFirst() statisch in den List-APIs anstelle der Erweiterungsfunktionen in kotlin-stdlib

    Wenn eine Anwendung neu kompiliert wird, wobei compileSdk auf 35 und minSdk auf 34 oder niedriger, und dann wird die App unter Android 14 und niedriger ausgeführt, eine Laufzeit ausgegeben:

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

    Die vorhandene Lint-Option NewApi im Android-Gradle-Plug-in kann diese abfangen neuen API-Nutzungen.

    ./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 Lint-Fehler zu beheben, verwenden die removeFirst() und removeLast()-Funktionsaufrufe können durch removeAt(0) und removeAt(list.lastIndex) in Kotlin. Wenn Sie Android Studio Ladybug | 2024.1.3 oder höher ist, können Sie das Problem Option für diese Fehler.

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

  • Kollision 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 kompatibel mit den Methoden mit demselben Namen und denselben Argumenttypen in anderen Schnittstellen und Kurse. Bei einer Kollision einer Methodensignatur mit Inkompatibilität gibt der Compiler javac einen Build-Zeitfehler aus. Für Beispiel:

    Beispielfehler 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

    Beispielfehler 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 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 Build-Fehler 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.getLast();
}

Sicherheit

Unter Android 15 werden Änderungen vorgenommen, die die Systemsicherheit fördern und zum Schutz von Apps beitragen und Nutzer vor schädlichen Apps.

Sichere Starts von 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 Intents

Android 15 引入了新的安全措施，可让 intent 更加安全且更安全 稳健。这些变更旨在防范潜在的漏洞和 可能会被恶意应用利用的 intent 滥用。有两个主要的 Android 15 中对 intent 安全性的改进：

  • 匹配目标 intent 过滤器：针对特定组件的 intent 准确匹配目标的 intent 过滤器规范。如果您发送 intent 来启动另一个应用的 activity，则目标 intent 组件需要 与接收 activity 声明的 intent 过滤器保持一致。
  • intent 必须具有操作：没有操作的 intent 将不再匹配 任何 intent 过滤器。也就是说，用于启动 activity 或 服务都必须有明确定义的操作。
  • 待处理 intent：待处理 intent 的创建者为 被视为封装 intent 的发送者，而非待处理 intent 的发送者 意图
。

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 umfasst einige Änderungen, die eine einheitlichere, eine intuitive User Experience bieten.

Änderungen am eingefügten Fenster

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

在搭载 Android 15 的设备上，应用会默认采用全屏 以 Android 15（API 级别 35）为目标平台。

<ph type="x-smartling-placeholder">
</ph>
一款以 Android 14 为目标平台且在 Android 设备上未处于无边框的应用 Android 15 设备。


<ph type="x-smartling-placeholder">
</ph>
一款以 Android 15（API 级别 35）为目标平台且采用无边框的应用 在 Android 15 设备上。此应用主要使用 Material 3 Compose 组件 自动应用边衬区此屏幕不会受到 Android 15 全屏强制执行。

这是一项可能会对应用的界面产生负面影响的破坏性更改。通过 更改会影响以下界面区域：

  • 手势手柄导航栏 <ph type="x-smartling-placeholder">
      </ph>
    • 默认透明。
    • 底部偏移量已停用，因此内容绘制在系统导航栏后面 栏。
    • setNavigationBarColor和R.attr#navigationBarColor 已弃用，不会影响手势导航。
    • setNavigationBarContrastEnforced和 R.attr#navigationBarContrastEnforced不会对 手势导航。
  • “三按钮”导航 <ph type="x-smartling-placeholder">
      </ph>
    • 默认不透明度设为 80%，颜色可能与窗口一致 背景。
    • 底部偏移值已停用，因此内容绘制在系统导航栏后面 除非应用了边衬区。
    • setNavigationBarColor和R.attr#navigationBarColor 默认设置为与窗口背景匹配。窗口背景 必须是颜色可绘制对象，才能应用此默认值。此 API 是 但会继续影响“三按钮”导航。
    • setNavigationBarContrastEnforced和 R.attr#navigationBarContrastEnforced 默认为 true，这会添加一个 “三按钮”导航模式显示 80% 不透明的背景。
  • 状态栏 <ph type="x-smartling-placeholder">
      </ph>
    • 默认透明。
    • 顶部偏移量已停用，因此除非 边衬区。
    • setStatusBarColor和R.attr#statusBarColor 已废弃，对 Android 15 没有任何影响。
    • setStatusBarContrastEnforced和 R.attr#statusBarContrastEnforced 已弃用，但仍具有 对 Android 15 的影响。
  • 刘海屏 <ph type="x-smartling-placeholder">
      </ph>
    • layoutInDisplayCutoutMode 的非浮动窗口必须是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS。SHORT_EDGES、NEVER和 系统会将 DEFAULT 解释为 ALWAYS，这样用户就不会看到黑色图标 长条形尺寸，显示为无边框。

以下示例显示了定位前后的应用 Android 15（API 级别 35）以及应用边衬区之前和之后。

<ph type="x-smartling-placeholder">
</ph>
一款以 Android 14 为目标平台且在 Android 设备上未处于无边框的应用 Android 15 设备。
。 <ph type="x-smartling-placeholder">
</ph>
一款以 Android 15（API 级别 35）为目标平台且为无边框应用 在 Android 15 设备上。不过，许多元素 栏、“三按钮”导航栏或刘海屏（由于 Android 15） 全屏强制措施。隐藏界面包含 Material 2 顶部应用栏、悬浮操作按钮和列表项。
。 <ph type="x-smartling-placeholder">
</ph>
如果应用以 Android 15（API 级别 35）为目标平台， Android 15 设备并应用边衬区，这样界面就不会 已隐藏。
检查应用是否已采用全屏的检查步骤

如果您的应用已经采用无边框且应用了边衬区， 基本未受影响，但下列情况除外。但即使您认为 您不会受到影响，但我们建议您测试自己的应用。

  • 您的非浮动窗口（例如 Activity）使用 SHORT_EDGES、NEVER 或 DEFAULT，而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS。如果您的应用在启动时崩溃 可能是启动画面所致您可以升级核心 初始屏幕依赖项更改为 1.2.0-alpha01 或更高版本，或者设置 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always。
  • 可能会有流量较低的屏幕显示被遮挡的界面。验证这些 访问较少的屏幕也不会显示被遮挡的界面。流量较低的屏幕包括： <ph type="x-smartling-placeholder">
      </ph>
    • 初始配置或登录屏幕
    • “设置”页面
如何检查应用尚未实现无边框

如果您的应用还没有全面屏，那么您很可能会受到影响。在 除了针对已经采用无边框的应用的情况之外， 请考虑以下事项：

  • 如果您的应用使用 Material 3 组件 ( androidx.compose.material3)，例如 TopAppBar， BottomAppBar 和 NavigationBar，那么这些组件可能不 会受到影响，因为它们会自动处理边衬区。
  • 如果您的应用使用 Material 2 组件 ( androidx.compose.material），那么这些组件 不会自动处理边衬区。不过，您可以使用边衬区 并手动应用这些设置在 androidx.compose.material 1.6.0 中 然后使用 windowInsets 参数手动应用边衬区 BottomAppBar、TopAppBar、 BottomNavigation 和 NavigationRail。 同样，对以下内容使用 contentWindowInsets 形参： Scaffold。
  • 如果您的应用使用视图和 Material 组件 (com.google.android.material)，大多数基于 View 的 Material 如 BottomNavigationView、BottomAppBar、 NavigationRailView 或 NavigationView，处理边衬区，不需要 额外工作。但是，您需要将 android:fitsSystemWindows="true" 如果使用 AppBarLayout，则会发生此错误。
  • 对于自定义可组合项，请手动将边衬区作为内边距应用。如果您的 内容位于 Scaffold 内，因此您可以使用 Scaffold 来使用边衬区 内边距值。否则，使用 WindowInsets。
  • 如果您的应用使用的是视图和 BottomSheet、SideSheet 或自定义 使用 ViewCompat.setOnApplyWindowInsetsListener。对于 RecyclerView，使用此监听器应用内边距，同时添加 clipToPadding="false"。
检查应用是否必须提供自定义后台保护的注意事项

如果您的应用必须为“三按钮”导航或 状态栏，则应用应将可组合项或视图放在系统栏后面 使用 WindowInsets.Type#tappableElement() 获取三按钮 导航栏高度或 WindowInsets.Type#statusBars。

其他无边框资源

请参阅无边框视图和无边框 Compose 了解应用边衬区的其他注意事项。

已弃用的 API

以下 API 现已弃用：

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 ist standardmäßig auf „true“ gesetzt

For apps targeting Android 15 (API level 35), the elegantTextHeight TextView attribute becomes true by default, replacing the compact font used by default with some scripts that have large vertical metrics with one that is much more readable. The compact font was introduced to prevent breaking layouts; Android 13 (API level 33) prevents many of these breakages by allowing the text layout to stretch the vertical height utilizing the fallbackLineSpacing attribute.

In Android 15, the compact font still remains in the system, so your app can set elegantTextHeight to false to get the same behavior as before, but it is unlikely to be supported in upcoming releases. So, if your app supports the following scripts: Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai, test your app by setting elegantTextHeight to true.

elegantTextHeight behavior for apps targeting Android 14 (API level 34) and lower.
elegantTextHeight behavior for apps targeting Android 15.

Änderungen der TextView-Breite für komplexe Buchstabenformen

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

由于此更改会影响 TextView 确定宽度的方式，因此 TextView 如果应用以 Android 15（API 级别 35）或 。您可以通过调用 在 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" />

Sprachspezifische 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

Android 15 nimmt folgende Änderungen am Kamera- und Medienverhalten von Apps vor die auf Android 15 oder höher ausgerichtet sind.

Einschränkungen bei der Anforderung von Audiofokus

以 Android 15 为目标平台的应用必须是顶级应用或运行前台服务，才能请求音频焦点。如果应用在不符合其中任何一项要求时尝试请求焦点，该调用将返回 AUDIOFOCUS_REQUEST_FAILED。

您可以参阅管理音频焦点，详细了解音频焦点。

Nicht-SDK-Einschränkungen aktualisiert

Android 15 enthält aktualisierte Listen mit eingeschränktem Nicht-SDK Benutzeroberflächen basierend auf der Zusammenarbeit mit Android-Entwicklern internen Tests. Wann immer möglich, achten wir darauf, dass öffentliche Alternativen bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn deine App nicht auf Android 15 ausgerichtet ist, gibt es einige dieser Änderungen nicht sofort betreffen. Es ist jedoch möglich, dass Ihre App Auf einige Nicht-SDK-Schnittstellen zugreifen abhängig vom Ziel-API-Level Ihrer App unter Verwendung eines Nicht-SDKs Methode oder Feld birgt immer ein hohes Risiko dafür, dass Ihre App beschädigt wird.

Wenn Sie nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Testen Sie Ihre App, um es herauszufinden. Wenn Ihre App kein SDK verwendet Schnittstellen, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Uns ist aber bewusst, dass es bei einigen Apps gültige Anwendungsfälle für die Nutzung von Nicht-SDK-Schnittstellen. Wenn Sie keine Alternative zur Verwendung eines Nicht-SDKs finden für eine Funktion in Ihrer App nutzen möchten, Neue öffentliche API anfordern

Weitere Informationen zu den Änderungen in diesem Android-Release finden Sie unter Aktualisierungen der Einschränkungen für Nicht-SDK-Schnittstellen in Android 15. Weitere Informationen zu Nicht-SDK-Schnittstellen im Allgemeinen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.