行為變更：指定 Android 15 以上版本的應用程式

和先前版本一樣，Android 15 也包含可能會影響應用程式的行為變更。以下行為變更僅適用於指定 Android 15 以上版本的應用程式。如果您的應用程式指定 Android 15 以上版本，建議您視情況修改應用程式，以支援這些行為。

此外，無論應用程式的 targetSdkVersion 為何，請務必查看影響所有在 Android 15 上執行的應用程式行為變更清單。

核心功能

Android 15 修改或擴充了 Android 系統的各種核心功能。

前景服務異動

We are making the following changes to foreground services with Android 15.

• Data sync foreground service timeout behavior
• New media processing foreground service type
• Restrictions on BOOT_COMPLETED broadcast receivers launching foreground services
• Restrictions on starting foreground services while an app holds the SYSTEM_ALERT_WINDOW permission

Data sync foreground service timeout behavior

对于以 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]"

注意 ：6 小时的时间限制由应用的所有 dataSync 前台服务共享。例如，如果应用运行 dataSync 服务四小时，然后启动其他 dataSync 服务，则第二个服务将只能运行两小时。不过，如果用户将应用调到前台，计时器会重置，并且应用将有 6 小时的可用时间。

为避免因行为变更而导致问题，您可以执行以下一项或多项操作：

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

New media processing foreground service type

Android 15 引入了一种新的前台服务类型 mediaProcessing。此服务类型适用于转码媒体文件等操作。例如，媒体应用可能会下载音频文件，并需要先将其转换为其他格式，然后才能播放。您可以使用 mediaProcessing 前台服务，确保即使应用在后台运行时转换也会继续。

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

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

注意 ：6 小时的时间限制由应用的所有mediaProcessing前台服务共享。例如，如果应用运行 mediaProcessing 服务四小时，然后启动其他 mediaProcessing 服务，则第二个服务将只能运行两小时。不过，如果用户将应用调到前台，计时器会重置，并且应用将有 6 小时的可用时间。

为避免出现此异常，您可以执行以下任一操作：

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

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

如需详细了解 mediaProcessing 服务类型，请参阅 Android 15 前台服务类型变更：媒体处理。

测试

如需测试应用的行为，您可以启用媒体处理超时，即使您的应用并非以 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 media_processing_fgs_timeout_duration duration-in-milliseconds

Restrictions on BOOT_COMPLETED broadcast receivers launching foreground services

There are new restrictions on BOOT_COMPLETED broadcast receivers launching foreground services. BOOT_COMPLETED receivers are not allowed to launch the following types of foreground services:

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (this restriction has been in place for microphone since Android 14)

If a BOOT_COMPLETED receiver tries to launch any of those types of foreground services, the system throws ForegroundServiceStartNotAllowedException.

Testing

To test your app's behavior, you can enable these new restrictions even if your app is not targeting Android 15 (as long as the app is running on an Android 15 device). Run the following adb command:

adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name

To send a BOOT_COMPLETED broadcast without restarting the device, run the following adb command:

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

Restrictions on starting foreground services while an app holds the SYSTEM_ALERT_WINDOW permission

先前，如果應用程式擁有 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

應用程式可修改「零打擾」模式全域狀態的時間異動

以 Android 15（API 级别 35）及更高版本为目标平台的应用无法再更改设备上的勿扰 (DND) 功能的全局状态或政策（无论是通过修改用户设置还是关闭勿扰模式）。相反，应用必须提供 AutomaticZenRule，系统会将其与现有的“最严格的政策优先”方案合并为一个全局政策。对之前会影响全局状态的现有 API 的调用（setInterruptionFilter、setNotificationPolicy）会导致创建或更新隐式 AutomaticZenRule，该 AutomaticZenRule 会根据这些 API 调用的调用周期开启和关闭。

请注意，只有当应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL) 并希望该调用停用之前由其所有者激活的 AutomaticZenRule 时，此更改才会影响可观察到的行为。

OpenJDK API 變更

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

以下变更可能会影响以 Android 15（API 级别 35）为目标平台的应用的兼容性：

• 对字符串格式化 API 进行了更改：现在，使用以下 String.format() 和 Formatter.format() API 时，对实参索引、标志、宽度和精度的验证要求变得更加严格：

  • String.format(String, Object[])
  • String.format(Locale, String, Object[])
  • Formatter.format(String, Object[])
  • Formatter.format(Locale, String, Object[])

  例如，当使用参数索引 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）。

• 对随机整数序列的更改：根据 https://bugs.openjdk.org/browse/JDK-8301574 中所做的更改，以下 Random.ints() 方法现在返回的数字序列与 Random.nextInt() 方法返回的数字序列不同：

  • Random.ints(long)
  • Random.ints(long, int, int)
  • Random.ints(int, int)
  • Random.ints()

  一般来说，此更改不应导致应用行为中断，但您的代码不应期望从 Random.ints() 方法生成的序列与 Random.nextInt() 相匹配。

新的 SequencedCollection API 可能会影响您应用的兼容性，具体取决于您是否在应用的 build 配置中更新 compileSdk 以使用 Android 15（API 级别 35）：

• 与 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 中的其他方法发生冲突

  现有类型中添加了新方法，例如 List 和 Deque。这些新方法可能与具有相同名称和实参类型的其他接口和类中的方法不兼容。如果方法签名发生不兼容的冲突，javac 编译器会输出 build 时错误。例如：

  错误示例 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
  

  如需修复这些 build 错误，实现这些接口的类应使用兼容的返回类型替换相应方法。例如：

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

安全性

Android 15 包含多項變更，可提升系統安全性，協助保護應用程式和使用者免受惡意應用程式侵害。

受限的 TLS 版本

Android 15 限制了对 TLS 版本 1.0 和 1.1 的使用。这些版本之前已在 Android 中被弃用，但现在不允许面向 Android 15 的应用使用。

安全啟動背景活動

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.

更安全的意圖

Android 15 引入了新的可选安全措施，以提高 intent 的安全性 和更强大的模型。这些变更旨在防范潜在的漏洞， 可能会被恶意应用利用的 intent 滥用。Android 15 对 intent 的安全性进行了两项主要改进：

• 匹配目标 intent 过滤器：针对特定组件的 intent 准确匹配目标的 intent 过滤器规范。如果您发送 intent 来启动另一个应用的 activity，则目标 intent 组件需要 与接收 activity 声明的 intent 过滤器保持一致。
• intent 必须包含操作：不含操作的 intent 将不再与任何 intent 过滤器匹配。也就是说，用于启动 activity 或 服务都必须有明确定义的操作。

重要提示：PendingIntent 充当标准 Intent 的封装容器，因此这些安全措施适用于 PendingIntent 中包含的 Intent。

要检查应用如何响应这些更改，请使用 StrictMode。要查看详细的 关于 Intent 使用违规行为的日志，请添加以下方法：

Kotlin

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

Java

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

使用者體驗和系統 UI

Android 15 包含一些變更，旨在打造更一致、直覺的使用者體驗。

視窗插邊變更

There are two changes related to window insets in Android 15: edge-to-edge is enforced by default, and there are also configuration changes, such as the default configuration of system bars.

全面实施政策

如果应用以 Android 15（API 级别 35）为目标平台，则在搭载 Android 15 的设备上默认以无边框显示。

重要提示： 如果您的应用尚未实现全屏显示，则应用的部分内容可能会被遮挡，您必须处理边衬区。根据应用的不同，这项工作可能很重要，也可能不重要。Material 3 Scaffold 组件可以减少与 Android 15 全屏强制执行兼容所需的工作。

以 Android 14 为目标平台且在 Android 15 设备上不是全屏显示的应用。

以 Android 15（API 级别 35）为目标平台且在 Android 15 设备上实现全屏显示的应用。

此应用主要使用会自动应用边衬区的 Material 3 Compose 组件。此屏幕不受 Android 15 强制执行的无边框措施的负面影响。

这是一项重大变更，可能会对应用的界面产生负面影响。这些更改会影响以下界面区域：

• 手势柄导航栏
  • 默认透明。
  • 底部偏移量处于停用状态，因此内容会绘制在系统导航栏后面，除非应用了边衬区。
  • setNavigationBarColor 和 R.attr#navigationBarColor 已被弃用，不会影响手势导航。
  • setNavigationBarContrastEnforced 和 R.attr#navigationBarContrastEnforced 继续对使用手势进行导航没有任何影响。
• “三按钮”导航
  • 默认情况下，不透明度设置为 80%，颜色可能与窗口背景颜色一致。
  • 底部偏移量处于停用状态，因此内容会绘制在系统导航栏后面，除非应用了边衬区。
  • 默认情况下，setNavigationBarColor 和 R.attr#navigationBarColor 设置为与窗口背景相匹配。窗口背景必须是颜色可绘制对象，才能应用此默认值。此 API 已弃用，但仍会影响三按钮导航。
  • setNavigationBarContrastEnforced 和 R.attr#navigationBarContrastEnforced 默认情况下为 true，这会在三按钮导航栏中添加 80% 不透明度的背景。
• 状态栏
  • 默认透明。
  • 顶部偏移量处于停用状态，因此内容会绘制在状态栏后面，除非应用了边衬区。
  • setStatusBarColor 和 R.attr#statusBarColor 已被废弃，在 Android 15 上不起作用。
  • setStatusBarContrastEnforced 和 R.attr#statusBarContrastEnforced 已废弃，但仍会对 Android 15 产生影响。
• 刘海屏
  • 非浮动窗口的 layoutInDisplayCutoutMode 必须为 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS。SHORT_EDGES、NEVER 和 DEFAULT 会被解读为 ALWAYS，这样用户就不会看到因刘海屏而产生的黑条，并且应用会显示在屏幕边缘。

以下示例展示了应用在以 Android 15（API 级别 35）为目标平台之前和之后，以及在应用边衬区之前和之后的效果。此示例并不全面，在 Android Auto 上可能会显示不同的内容。

以 Android 14 为目标平台且在 Android 15 设备上不是全屏显示的应用。

以 Android 15（API 级别 35）为目标平台且在 Android 15 设备上实现全屏显示的应用。不过，由于 Android 15 边缘到边缘的强制执行，许多元素现在会被状态栏、三按钮导航栏或刘海屏遮挡。隐藏界面包括 Material 2 顶部应用栏、悬浮操作按钮和列表项。

以 Android 15（API 级别 35）为目标平台的应用在 Android 15 设备上处于全屏显示状态，并应用边衬区，以便界面不会被隐藏。

如果应用已实现全屏显示，需要检查哪些方面

如果您的应用已实现全屏显示并应用边衬区，则除了以下情形外，您基本上不会受到影响。不过，即使您认为自己不受影响，我们仍建议您测试应用。

• 您有一个非浮动窗口，例如使用 SHORT_EDGES、NEVER 或 DEFAULT 而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS 的 Activity。如果您的应用在启动时崩溃，这可能是由启动画面引起的。您可以将核心启动画面依赖项升级到 1.2.0-alpha01 或更高版本，也可以设置 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always。
• 可能存在流量较低且界面被遮挡的屏幕。验证这些访问频率较低的界面是否没有被遮挡的界面。低流量界面包括：
  • 初始配置或登录界面
  • “设置”页面

如果您的应用尚未实现全屏显示，需要检查哪些方面

如果您的应用尚未实现全屏显示，则很可能会受到影响。除了已经实现全屏显示的 app 的场景之外，您还应考虑以下事项：

• 如果您的应用在 Compose 中使用 Material 3 组件 (androidx.compose.material3)，例如 TopAppBar、BottomAppBar 和 NavigationBar，这些组件很可能不会受到影响，因为它们会自动处理边衬区。
• 如果您的应用使用的是 Compose 中的 Material 2 组件 (androidx.compose.material)，这些组件不会自动处理边衬区。不过，您可以获得边衬区的访问权限，然后手动应用边衬区。在 androidx.compose.material 1.6.0 及更高版本中，使用 windowInsets 参数可为 BottomAppBar、TopAppBar、BottomNavigation 和 NavigationRail 手动应用边衬区。 同样，请为 Scaffold 使用 contentWindowInsets 参数。
• 如果您的应用使用视图和 Material 组件 (com.google.android.material)，则大多数基于视图的 Material 组件（例如 BottomNavigationView、BottomAppBar、NavigationRailView 或 NavigationView）都会处理边衬区，因此不需要执行额外的操作。不过，如果使用的是 AppBarLayout，则需要添加 android:fitsSystemWindows="true"。
• 对于自定义可组合项，请手动应用边衬区作为内边距。如果您的内容位于 Scaffold 内，则可以使用 Scaffold 内边距值来使用边衬区。否则，请使用 WindowInsets 之一应用内边距。
• 如果应用使用的是视图和 BottomSheet、SideSheet 或自定义容器，请使用 ViewCompat.setOnApplyWindowInsetsListener 应用内边距。对于 RecyclerView，请使用此监听器应用内边距，同时添加 clipToPadding="false"。

如果您的应用必须提供自定义后台保护，您需要检查哪些方面

如果您的应用必须为三按钮导航或状态栏提供自定义背景保护，则应使用 WindowInsets.Type#tappableElement() 或 WindowInsets.Type#statusBars 将可组合项或视图放置在系统栏后面，以获取三按钮导航栏高度。

其他全屏显示资源

如需了解有关应用边衬区的其他注意事项，请参阅全屏视图和全屏 Compose 指南。

已弃用的 API

以下 API 已弃用，但未停用：

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor（适用于三按钮导航，透明度为 80%）
• Window#isStatusBarContrastEnforced
• Window#setNavigationBarColor（适用于三按钮导航，透明度为 80%）
• Window#setStatusBarContrastEnforced

以下 API 已弃用并停用：

• R.attr#navigationBarColor（适用于手势导航）
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#setDecorFitsSystemWindows
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#setNavigationBarColor（适用于手势导航）
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor

稳定配置

如果您的应用以 Android 15（API 级别 35）或更高版本为目标平台，Configuration 不再排除系统栏。如果您在 Configuration 类中使用屏幕尺寸进行布局计算，则应根据需要将其替换为更好的替代方案，例如适当的 ViewGroup、WindowInsets 或 WindowMetricsCalculator。

Configuration 自 API 1 起便已开始提供。它通常从 Activity.onConfigurationChanged 中获取。它提供窗口密度、方向和大小等信息。从 Configuration 返回的窗口大小的一个重要特征是，它之前排除了系统栏。

配置大小通常用于资源选择，例如 /res/layout-h500dp，这仍然是一个有效的使用情形。不过，我们一直不建议使用它进行布局计算。如果您正在这样做，请立即远离该设备。您应根据自己的使用场景，将 Configuration 的使用替换为更合适的用法。

如果您使用它来计算布局，请使用适当的 ViewGroup，例如 CoordinatorLayout 或 ConstraintLayout。如果您使用它来确定系统导航栏的高度，请使用 WindowInsets。如果您想知道应用窗口的当前大小，请使用 computeCurrentWindowMetrics。

以下列表介绍了受此变更影响的字段：

• Configuration.screenWidthDp 和 screenHeightDp 尺寸不再排除系统栏。
• Configuration.smallestScreenWidthDp 会受到 screenWidthDp 和 screenHeightDp 更改的间接影响。
• Configuration.orientation 会受到近乎方形的设备上 screenWidthDp 和 screenHeightDp 更改的间接影响。
• Display.getSize(Point) 间接受到 Configuration 中的更改影响。此方法已从 API 级别 30 开始弃用。
• 自 API 级别 33 以来，Display.getMetrics() 一直以这种方式运行。

elegantTextHeight 屬性預設為 true

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.

複雜字母形狀的 TextView 寬度變化

在舊版 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" />

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.

相機和媒體

Android 15 對指定 Android 15 以上版本的應用程式，進行了下列攝影機和媒體行為變更。

要求音訊焦點的限制

Apps that target Android 15 (API level 35) must be the top app or running a foreground service in order to request audio focus. If an app attempts to request focus when it does not meet one of these requirements, the call returns AUDIOFOCUS_REQUEST_FAILED.

You can learn more about audio focus at Manage audio focus.

更新非 SDK 限制

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

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

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

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 15. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.