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

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

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

核心功能

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

前景服務變更

我们将对 Android 15 中的前台服务做出以下更改。

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

Android 15 針對指定應用程式，為 dataSync 推出了新的逾時行為 搭載 Android 15 以上版本。這個行為也適用於新的 mediaProcessing 前景服務類型。

系統允許應用程式的 dataSync 服務執行總計 6 小時 24 小時期間，系統會呼叫執行中服務的 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 前景服務在過去 6 小時內執行了 6 小時 24，「除非」使用者，否則您無法啟動另一項 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. 請使用替代 API，例如 WorkManager，不要使用 mediaProcessing 前景服務。

如果應用程式的 mediaProcessing 前景服務在過去 24 天內已執行 6 小時，則「除非」使用者將應用程式移至前景 (這會重設計時器)，否則您無法啟動另一項 mediaProcessing 前景服務。如果您嘗試啟動另一項 mediaProcessing 前景服務，系統會擲回 ForegroundServiceStartNotAllowedException，並顯示錯誤訊息「Time limit is Of for 前景服務類型 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 广播接收器的限制

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:

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

限制在应用拥有 SYSTEM_ALERT_WINDOW 权限的情况下启动前台服务

Previously, if an app held the SYSTEM_ALERT_WINDOW permission, it could launch a foreground service even if the app was currently in the background (as discussed in exemptions from background start restrictions).

If an app targets Android 15, this exemption is now narrower. The app now needs to have the SYSTEM_ALERT_WINDOW permission and also have a visible overlay window. That is, the app needs to first launch a TYPE_APPLICATION_OVERLAY window and the window needs to be visible before you start a foreground service.

If your app attempts to start a foreground service from the background without meeting these new requirements (and it does not have some other exemption), the system throws ForegroundServiceStartNotAllowedException.

If your app declares the SYSTEM_ALERT_WINDOW permission and launches foreground services from the background, it may be affected by this change. If your app gets a ForegroundServiceStartNotAllowedException, check your app's order of operations and make sure your app already has an active overlay window before it attempts to start a foreground service from the background. You can check if your overlay window is currently visible by calling View.getWindowVisibility(), or you can override View.onWindowVisibilityChanged() to get notified whenever the visibility changes.

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). To enable these new restrictions on starting foreground services from the background, run the following adb command:

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

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

以 Android 15 為目標的應用程式無法再透過修改使用者設定或關閉 DND 模式，變更裝置上「零打擾」(DND) 模式的全域狀態或政策。而是必須為應用程式提供 AutomaticZenRule，系統會將此系統結合至全域政策和目前最嚴格的政策，如果呼叫先前影響全域狀態 (setInterruptionFilter、setNotificationPolicy) 的現有 API，會導致隱式 AutomaticZenRule 建立或更新，系統會根據這些 API 呼叫的呼叫週期開啟或關閉這項功能。

請注意，當應用程式呼叫 setInterruptionFilter(INTERRUPTION_FILTER_ALL)，並預期呼叫來停用擁有者先前啟用的 AutomaticZenRule 時，這項變更只會影響可觀測的行為。

OpenJDK API 變更

Android 15 将继续更新 Android 的核心库， 最新 OpenJDK LTS 版本中的功能。

其中一些变更可能会影响应用定位的应用兼容性 Android 15（API 级别 35）：

  • 字符串格式设置 API 变更：验证参数索引、标志、 现在，使用 String.format() 和 Formatter.format() API：

    例如，当参数索引为 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() 方法生成的序列 匹配Random.nextInt()。

新的 SequencedCollection API 可能会影响应用的兼容性 当您在应用的 build 配置中更新 compileSdk 以使用 Android 15（API 级别 35）：

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

    Java 中的 List 类型会映射到 Kotlin 中的 MutableList 类型。 由于使用 List.removeFirst() 和 List.removeLast() API 已在 Android 15（API 级别 35）中引入，Kotlin 编译器 将函数调用（例如 list.removeFirst()）静态解析为 新的 List API，而不是对 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 错误，removeFirst() 和 removeLast() 函数调用可替换为 removeAt(0)， removeAt(list.lastIndex)（在 Kotlin 中分别对应）。如果您使用的是 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.getLast();
}

安全性

Android 15 包含提升系統安全性的異動，可協助保護應用程式和使用者不受惡意應用程式侵擾。

啟動安全的背景活動

Android 15 可以保護使用者不受惡意應用程式侵擾，並新增多項變更，防止惡意背景應用程式將其他應用程式導入前景、提升權限及濫用使用者互動行為，讓使用者進一步控管裝置。背景活動啟動功能自 Android 10 (API 級別 29) 開始受到限制。

封鎖與堆疊上頂端 UID 不符的應用程式，禁止啟動活動

惡意應用程式可能會在同一工作中啟動其他應用程式的活動，然後將其疊放在另一個頂端，造成代表該應用程式的錯覺。這種「工作盜用」攻擊會略過目前的背景啟動限制，因為這類攻擊全都發生在相同的可見工作中。為降低這種風險，Android 15 新增了旗標，用於封鎖與堆疊上頂端 UID 不符的應用程式，停止啟動活動。如要為應用程式的所有活動選擇加入，請在應用程式的 AndroidManifest.xml 檔案中更新 allowCrossUidActivitySwitchFromBelow 屬性：

<application android:allowCrossUidActivitySwitchFromBelow="false" >

只要符合下列所有條件，系統就會啟用新的安全措施：

  • 搭載 Android 15 的應用程式發布。
  • 工作堆疊頂端的應用程式以 Android 15 為目標。
  • 任何可見活動都啟用新的保護措施

如果啟用安全措施，應用程式完成自己的工作後可能會返回主畫面，而非上次顯示的應用程式。

其他異動

除了 UID 比對的限制外，下列其他變更也包括：

  • 將 PendingIntent 建立者變更為預設封鎖背景活動啟動。這有助於防止應用程式意外建立可能會遭惡意人士濫用的 PendingIntent。
  • 請勿讓應用程式在前景執行，除非 PendingIntent 傳送者允許應用程式。這項變更旨在避免惡意應用程式濫用在背景啟動活動的功能。根據預設，除非創作者允許背景活動啟動權限，或傳送者擁有背景活動啟動權限，否則應用程式不得將工作堆疊移至前景。
  • 控管工作堆疊的頂端活動如何完成工作。如果頂層活動完成一項任務，Android 就會返回上次啟用的工作。此外，如果非頂端活動完成任務，Android 會返回主畫面，並不會阻止完成這項非頂層活動。
  • 防止透過其他應用程式啟動任意活動到自己的工作中。這項變更會建立看似來自其他應用程式的活動，預防惡意應用程式使用者遭受網路釣魚攻擊。
  • 封鎖背景活動啟動不可見的視窗。這有助於防止惡意應用程式濫用背景活動啟動程序，向使用者顯示不需要或惡意的內容。

更安全的意圖

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

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

Kotlin


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

Java


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

使用者體驗和系統 UI

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

視窗插邊變更

Android 15 的視窗插邊有兩項變更：根據預設，系統會強制執行無邊框設計，以及設定變更 (例如系統列的預設設定)。

無邊框強制執行

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, you 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 now deprecated:

穩定版設定

如果應用程式指定 Android 15 (API 級別 35) 以上版本，Configuration則否 更長的時間排除系統資訊列。如果 用於計算版面配置的 Configuration 類別，請將其替換為更好的類別 替代函式，例如適當的 ViewGroup、WindowInsets 或 WindowMetricsCalculator (視您的需求而定)。

Configuration 自 API 1 版本開始提供。這通常是從 Activity.onConfigurationChanged。這項服務提供視窗密度 廣告方向和大小視窗大小的一個重要特性 Configuration 傳回的原因是先前已排除系統資訊列。

設定大小通常用於選取資源，例如 /res/layout-h500dp，這仍然是有效的用途。不過，如果是 並向來不建議版面配置否則請將 立即解決問題您應該將 Configuration 的使用替換為 根據用途選擇更合適的選項

如果要用於計算版面配置，請使用適當的 ViewGroup，例如 CoordinatorLayout 或 ConstraintLayout。當您用它來確定高度 請使用 WindowInsets。詢問目前大小 請使用 computeCurrentWindowMetrics

以下清單說明受到這項異動影響的欄位：

routeTextHeight 屬性預設為 true

For apps targeting Android 15, 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 以上版本，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 元素的大小仍一致，如下圖所示：

三個方塊代表 EditText 元素，可包含英文 (en)、日文 (ja) 和緬甸文 (my)。EditText 的高度相同，即使這些語言的行高也不同。

對於指定 Android 15 為目標版本的應用程式，系統現在會為 EditText 保留最小行高，以便符合指定語言代碼的參考字型，如下圖所示：

三個方塊代表 EditText 元素，可包含英文 (en)、日文 (ja) 和緬甸文 (my)。EditText 的高度現在包含空間，以配合這些語言字型的預設行高。

如有需要，應用程式可將 useLocalePreferredLineHeightForMinimum 屬性指定為 false，藉此還原先前的行為，應用程式則可在 Kotlin 和 Java 中使用 setMinimumFontMetrics API，設定自訂的最小垂直指標。

相機與媒體

Android 15 針對指定 Android 15 以上版本為目標的應用程式，對相機和媒體行為做出下列變更。

要求音訊焦點的限制

以 Android 15 為目標的應用程式必須是頂層應用程式或執行前景服務，才能要求音訊焦點。如果應用程式嘗試要求焦點，但不符合上述其中一項要求，呼叫會傳回 AUDIOFOCUS_REQUEST_FAILED。

如要進一步瞭解音訊焦點，請參閱管理音訊焦點一文。

更新非 SDK 限制

Android 15 內含最新的受限制非 SDK 清單 介面是以與 Android 開發人員合作為基礎，並採用 內部測試。我們會盡可能確保公開的替代方案 ，然後再限制非 SDK 介面使用

如果您的應用程式並不是以 Android 15 為目標版本，則其中某些變更 可能無法立即對您造成影響不過，雖然您的應用程式可以 存取某些非 SDK 介面 視應用程式的目標 API 級別而定 (使用任何非 SDK) 方法或欄位，都有很高風險的應用程式毀損。

如果不確定應用程式是否使用非 SDK 介面，您可以 測試應用程式。如果應用程式仰賴非 SDK 介面，因此您應該開始規劃遷移至 SDK 替代方案。 我們瞭解有些應用程式具備使用情境 非 SDK 介面若您找不到使用非 SDK 的替代方案 應用程式中某個功能的介面 要求新的公用 API。

如要進一步瞭解此 Android 版本中的變更，請參閱 Android 15 的非 SDK 介面限制更新內容。如要進一步瞭解非 SDK 介面的一般資訊，請參閱非 SDK 介面的限制。