行为变更：面向 Android 15 或更高版本的应用

与之前的版本一样，Android 15 包含可能影响您应用的行为变更。以下行为变更专门适用于面向 Android 15 或更高版本的应用。如果您的应用面向 Android 15 或更高版本，则应酌情修改您的应用以正确支持这些行为。

务必同时查看影响在 Android 15 上运行的所有应用的行为变更列表，无论您的应用targetSdkVersion如何。

核心功能

Android 15 修改或扩展了 Android 系统的各种核心功能。

前台服务变更

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

• 数据同步前台服务超时行为
• 新增媒体处理前台服务类型
• 对 BOOT_COMPLETED 广播接收器启动前台服务的限制
• 当应用持有 SYSTEM_ALERT_WINDOW 权限时启动前台服务的限制

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

Android 15 为面向 Android 15（API 级别 35）或更高版本的应用引入了新的 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 前台服务；由于服务启动时您的应用在前台，因此在应用进入后台后，您的服务将有完整的六小时。
4. 不使用 dataSync 前台服务，而是使用替代 API。

如果您的应用的 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

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

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]"

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

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

如果您的应用的 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

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

对 BOOT_COMPLETED 广播接收器启动前台服务有新的限制。BOOT_COMPLETED 接收器不允许启动以下类型的前台服务：

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone（此限制自 Android 14 起已对 microphone 生效）

如果 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 权限时启动前台服务的限制

此前，如果应用持有 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) 的全局状态或政策（无论是通过修改用户设置还是关闭 DND 模式）。相反，应用必须贡献一个 AutomaticZenRule，系统会根据现有的“最严格政策胜出”方案将其与全局政策结合。调用以前影响全局状态的现有 API（setInterruptionFilter、setNotificationPolicy）将导致创建或更新隐式 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() 匹配。

在您更新应用的构建配置中的 compileSdk 以使用 Android 15（API 级别 35）后，新的 SequencedCollection API 可能会影响您应用的兼容性。

• 与 kotlin-stdlib 中 MutableList.removeFirst() 和 MutableList.removeLast() 扩展函数冲突

  Java 中的 List 类型映射到 Kotlin 中的 MutableList 类型。由于 Android 15（API 级别 35）中引入了 List.removeFirst() 和 List.removeLast() API，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 编译器会输出构建时错误。例如：

  示例错误 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();
  }
  

安全性

Android 15 包含促进系统安全性的变更，以帮助保护应用和用户免受恶意应用的侵害。

受限 TLS 版本

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

安全的后台活动启动

Android 15 通过添加变更来保护用户免受恶意应用的侵害，并赋予他们对其设备的更多控制权，这些变更可防止恶意后台应用将其他应用带到前台、提升其权限以及滥用用户交互。自 Android 10（API 级别 29）以来，后台活动启动已受到限制。

其他变更

除了 UID 匹配的限制外，还包括以下其他变更：

• 默认情况下，将 PendingIntent 创建者更改为阻止后台活动启动。这有助于防止应用意外创建可能被恶意行为者滥用的 PendingIntent。
• 除非 PendingIntent 发送者允许，否则不要将应用带到前台。此变更旨在防止恶意应用滥用在后台启动活动的能力。默认情况下，除非创建者允许后台活动启动权限或发送者具有后台活动启动权限，否则应用不允许将任务堆栈带到前台。
• 控制任务堆栈的顶部活动如何完成其任务。如果顶部活动完成任务，Android 将返回到上次活动的任务。此外，如果非顶部活动完成其任务，Android 将返回到主屏幕；它不会阻止此非顶部活动的完成。
• 防止从其他应用启动任意活动到您自己的任务中。此变更可防止恶意应用通过创建看起来来自其他应用的活动来诱骗用户。
• 阻止不可见的窗口被视为后台活动启动。这有助于防止恶意应用滥用后台活动启动来向用户显示不需要的或恶意内容。

更安全的 intent

Android 15 引入了新的可选安全措施，使 intent 更安全、更稳健。这些变更旨在防止可能被恶意应用利用的潜在漏洞和 intent 滥用。Android 15 中 intent 安全性有两项主要改进：

• 匹配目标 intent-filters：面向特定组件的 intent 必须准确匹配目标的 intent-filter 规范。如果您发送 intent 以启动另一个应用的 activity，则目标 intent 组件需要与接收 activity 声明的 intent-filters 对齐。
• Intent 必须具有 action：没有 action 的 Intent 将不再匹配任何 intent-filters。这意味着用于启动 activity 或 service 的 intent 必须具有明确定义的 action。

为了检查您的应用如何响应这些变更，请在您的应用中使用 StrictMode。要查看有关 Intent 使用违规的详细日志，请添加以下方法：

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

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

用户体验和系统界面

Android 15 包含一些变更，旨在创建更一致、更直观的用户体验。

窗口内边距变更

Android 15 中有两项与窗口内边距相关的变更：默认强制全屏，并且还有配置变更，例如系统栏的默认配置。

全屏强制执行

如果应用面向 Android 15（API 级别 35），则在运行 Android 15 的设备上，应用默认是全屏的。

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

• 手势导航栏
  • 默认透明。
  • 底部偏移已禁用，因此除非应用内边距，否则内容会绘制在系统导航栏后面。
  • setNavigationBarColor 和 R.attr#navigationBarColor 已弃用，且不影响手势导航。
  • setNavigationBarContrastEnforced 和 R.attr#navigationBarContrastEnforced 对手势导航继续无效。
• 三按钮导航
  • 默认不透明度设置为 80%，颜色可能与窗口背景匹配。
  • 底部偏移已禁用，因此除非应用内边距，否则内容会绘制在系统导航栏后面。
  • setNavigationBarColor 和 R.attr#navigationBarColor 默认设置为与窗口背景匹配。要使此默认设置生效，窗口背景必须是颜色 drawable。此 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）之前和之后以及在应用内边距之前和之后的情况。

如果您的应用已全屏，需要检查什么

如果您的应用已全屏并应用了内边距，则除了以下情况外，您基本不受影响。但是，即使您认为不受影响，我们仍建议您测试您的应用。

• 您有一个非浮动窗口，例如使用 SHORT_EDGES、NEVER 或 DEFAULT 而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS 的 Activity。如果您的应用在启动时崩溃，这可能是由于您的闪屏造成的。您可以将 core splashscreen 依赖项升级到 1.2.0-alpha01 或更高版本，或者设置 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always。
• 流量较低的屏幕可能会出现被遮挡的界面。验证这些访问量较少的屏幕没有被遮挡的界面。流量较低的屏幕包括：
  • 引导或登录屏幕
  • 设置页面

如果您的应用尚未全屏，需要检查什么

如果您的应用尚未全屏，您很可能会受到影响。除了已全屏的应用的情况外，您还应考虑以下事项：

• 如果您的应用在 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 中弃用。
• Display.getMetrics() 自 API 级别 33 起已如此运行。

elegantTextHeight 属性默认为 true

对于面向 Android 15（API 级别 35）的应用，elegantTextHeight TextView 属性默认变为 true，它将默认用于某些具有大垂直指标的脚本的紧凑字体替换为更具可读性的字体。引入紧凑字体是为了防止布局破坏；Android 13（API 级别 33）通过允许文本布局利用 fallbackLineSpacing 属性拉伸垂直高度来防止许多此类破坏。

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

复杂字母形状的 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 的区域设置感知默认行高

在早期 Android 版本中，文本布局会拉伸文本的高度以满足与当前区域设置匹配的字体的行高。例如，如果内容是日语，由于日语字体的行高略大于拉丁字体，因此文本的高度会略微增大。然而，尽管行高存在这些差异，但 EditText 元素的大小是统一的，无论使用何种区域设置，如下图所示：

对于面向 Android 15（API 级别 35）的应用，现在为 EditText 保留了最小行高，以匹配指定区域设置的参考字体，如下图所示：

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

相机和媒体

Android 15 对面向 Android 15 或更高版本的应用的相机和媒体行为进行了以下变更。

请求音频焦点的限制

面向 Android 15（API 级别 35）的应用必须是顶部应用或正在运行前台服务，才能请求音频焦点。如果应用在不满足这些要求之一的情况下尝试请求焦点，则调用会返回 AUDIOFOCUS_REQUEST_FAILED。

您可以在管理音频焦点中了解有关音频焦点的更多信息。

更新的非 SDK 限制

Android 15 包含更新的受限非 SDK 接口列表，这些列表基于与 Android 开发者合作和最新的内部测试。我们尽可能确保在限制非 SDK 接口之前提供公共替代方案。

如果您的应用未面向 Android 15，其中一些变更可能不会立即影响您。但是，虽然您的应用可能根据您应用的 target API 级别访问某些非 SDK 接口，但使用任何非 SDK 方法或字段始终会带来应用崩溃的高风险。

如果您不确定您的应用是否使用非 SDK 接口，您可以测试您的应用以找出答案。如果您的应用依赖于非 SDK 接口，您应该开始计划迁移到 SDK 替代方案。尽管如此，我们理解某些应用具有使用非 SDK 接口的有效用例。如果您无法找到在应用中为某个功能使用非 SDK 接口的替代方案，您应该请求新的公共 API。

要了解有关此 Android 版本变更的更多信息，请参阅Android 15 中非 SDK 接口限制的更新。要了解有关非 SDK 接口的一般信息，请参阅非 SDK 接口的限制。