行为变更：面向 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，并显示类似“Time limit already exhausted for foreground service type 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，并显示类似“Time limit already exhausted for foreground service type 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()匹配。

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

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

  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 编译器会输出构建时错误。例如

  错误示例 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 包含旨在增强系统安全性以帮助保护应用和用户免受恶意应用侵害的更改。

安全的后台活动启动

Android 15 通过添加更改来防止恶意后台应用将其他应用带到前台、提升其权限和滥用用户交互，从而保护用户免受恶意应用的侵害。自 Android 10（API 级别 29）起，后台活动启动已被限制。

其他更改

除了 UID 匹配的限制外，还包含以下其他更改

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

更安全的 Intent

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

• 匹配目标 Intent 过滤器：针对特定组件的 Intent 必须准确匹配目标的 Intent 过滤器规范。如果您发送 Intent 以启动另一个应用的活动，则目标 Intent 组件需要与接收活动的已声明 Intent 过滤器保持一致。
• Intent 必须具有操作：没有操作的 Intent 将不再匹配任何 Intent 过滤器。这意味着用于启动活动或服务的 Intent 必须具有明确定义的操作。

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

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

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

用户体验和系统 UI

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

窗口内嵌更改

Android 15 中有两个与窗口内嵌相关的更改：默认情况下强制执行边缘到边缘，并且还有一些配置更改，例如系统栏的默认配置。

边缘到边缘强制

如果应用的目标是 Android 15（API 级别 35），则在运行 Android 15 的设备上，应用默认情况下为边缘到边缘。

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

• 手势处理导航栏
  • 默认情况下为透明。
  • 底部偏移已禁用，因此内容在系统导航栏后面绘制，除非应用了内嵌。
  • 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）之前和之后，以及在应用内嵌之前和之后的情况。

如果您的应用已为边缘到边缘，则需要检查什么

如果您的应用已边缘到边缘并应用内嵌，则您基本不受影响，除了以下情况。但是，即使您认为自己没有受到影响，我们也建议您测试您的应用。

• 您有一个非浮动窗口，例如使用 SHORT_EDGES、NEVER 或 DEFAULT 而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS 的 Activity。如果您的应用在启动时崩溃，这可能是由于您的启动画面造成的。您可以将 核心启动画面依赖项升级到1.2.0-alpha01或更高版本，或者设置 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always。

• 一些流量较低的屏幕可能存在 UI 被遮挡的情况。请验证这些访问量较少的屏幕上没有 UI 被遮挡。流量较低的屏幕包括
  • 引导或登录屏幕
  • 设置页面

如果您的应用尚未启用边缘到边缘，需要检查哪些内容

如果您的应用尚未启用边缘到边缘，则很可能受到影响。除了已启用边缘到边缘的应用的场景外，您还应考虑以下内容

• 如果您的应用在 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 Components（com.google.android.material），大多数基于视图的 Material Components（如 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 包含基于与 Android 开发人员合作以及最新的内部测试而更新的受限非 SDK 接口列表。在限制非 SDK 接口之前，我们会尽可能确保提供公共替代方案。

如果您的应用没有以 Android 15 为目标，则其中一些更改可能不会立即影响您。但是，虽然您的应用可能可以访问某些非 SDK 接口 具体取决于您的应用的目标 API 级别，但使用任何非 SDK 方法或字段始终存在使您的应用崩溃的高风险。

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

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