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

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

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

核心功能

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

前景服務異動

我們將對 Android 15 的前景服務進行下列異動。

• 資料同步前景服務逾時行為
• 新版媒體處理前景服務類型
• BOOT_COMPLETED廣播接收器啟動前景服務的限制
• 應用程式擁有 SYSTEM_ALERT_WINDOW 權限時，啟動前景服務的限制

資料同步處理前景服務逾時行為

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

新的媒體處理前景服務類型

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

BOOT_COMPLETED 廣播接收器啟動前景服務的限制

BOOT_COMPLETED 廣播接收器啟動有一些新限制 前景服務BOOT_COMPLETED 接收器無法啟動 下列類型的前景服務：

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (我們已對 microphone 設下這項限制，自 Android 14)

如果 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) 功能的全局状态或政策（无论是通过修改用户设置还是关闭勿扰模式）。相反，应用必须提供 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() 相符。

在應用程式的建構設定中更新 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）起，后台 activity 启动受到限制。

其他更改

• 将 PendingIntent 创建者更改为默认阻止后台活动启动。这有助于防止应用意外创建可能被恶意行为者滥用的 PendingIntent。
• 除非 PendingIntent 发送方允许，否则请勿将应用转至前台。此变更旨在防止恶意应用滥用在后台启动 activity 的功能。默认情况下，除非创建者允许后台 activity 启动权限或发送者具有后台 activity 启动权限，否则不允许应用将任务堆栈带到前台。
• 控制任务堆栈的顶层 activity 如何完成其任务。如果顶部 activity 完成了一项任务，Android 将返回到上次处于活跃状态的任务。此外，如果非顶部 activity 完成其任务，Android 会返回到主屏幕；它不会阻止此非顶部 activity 完成。
• 防止从其他应用启动任意 activity 进入您自己的任务。此变更可防止恶意应用通过创建看似来自其他应用的 activity 来对用户进行钓鱼式攻击。
• 阻止将非可见窗口纳入后台 activity 启动的考虑范围。这有助于防止恶意应用滥用后台活动启动来向用户显示不必要或恶意的内容。

更安全的意圖

Android 15 针对 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 包含一些變更，旨在打造更一致、直覺的使用者體驗。

視窗插邊變更

Android 15 中与窗口内边距相关的两项变更：默认强制执行边到边，此外还有配置变更，例如系统栏的默认配置。

邊緣到邊緣強制執行

如果應用程式以 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 無邊框強制措施的負面影響。

這項重大變更可能會對應用程式的 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) 前後，以及套用插邊前後的樣貌。這個範例並不完整，Android Auto 上的顯示方式可能有所不同。

以 Android 14 為目標版本，但未在 Android 15 裝置上啟用無邊框模式的應用程式。

應用程式指定 Android 15 (API 級別 35) 為目標，且在 Android 15 裝置上採用無邊框設計。不過，由於 Android 15 強制採用無邊框設計，許多元素現在會遭到狀態列、3 鍵導覽列或螢幕凹口遮蔽。隱藏的 UI 包括 Material 2 頂端應用程式列、懸浮動作按鈕和清單項目。

如果應用程式以 Android 15 (API 級別 35) 為目標，且在 Android 15 裝置上採用無邊框設計，並套用插邊，UI 就不會遭到遮蔽。

如果應用程式已採用無邊框設計，請檢查以下項目

如果您的應用程式已無邊框並套用插邊，則大多不會受到影響，但下列情況除外。不過，即使您認為自己不受影響，我們仍建議測試應用程式。

• 您有非浮動視窗，例如使用 SHORT_EDGES、NEVER 或 DEFAULT 而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS 的 Activity。如果應用程式在啟動時當機，可能是因為啟動畫面。您可以將核心啟動畫面依附元件升級至 1.2.0-alpha01 以上版本，或設定 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always。
• 可能會有流量較低的畫面，且使用者介面遭到遮蔽。確認這些較少造訪的畫面沒有遭到遮蔽的 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 參數。
• 如果應用程式使用 Views 和 Material 元件 (com.google.android.material)，您可能不需採取額外行動，因為大多數以 Views 為基礎的 Material 元件 (例如 BottomNavigationView、BottomAppBar、NavigationRailView 或 NavigationView) 都會處理插邊。不過，如果您使用 AppBarLayout，就需要新增 android:fitsSystemWindows="true"。
• 如果是自訂可組合函式，請手動將插邊套用為邊框間距。如果內容位於 Scaffold 內，您可以使用Scaffold 邊框間距值取用插邊。否則，請使用 WindowInsets 套用邊框間距。
• 如果應用程式使用 Views 和 BottomSheet、SideSheet 或自訂容器，請使用 ViewCompat.setOnApplyWindowInsetsListener 套用邊框間距。對於 RecyclerView，也請使用這個事件監聽器套用邊框間距，同時新增 clipToPadding="false"。

如果應用程式必須提供自訂背景保護功能，請檢查下列事項

如果應用程式必須為三按鈕操作模式或狀態列提供自訂背景保護措施，應用程式應使用 WindowInsets.Type#tappableElement() 將可組合函式或檢視區塊放在系統列後方，以取得三按鈕操作模式導覽列高度或 WindowInsets.Type#statusBars。

其他無邊框資源

如要進一步瞭解如何套用插邊，請參閱「無邊框檢視區塊」和「無邊框 Compose」指南。

已淘汰的 API

下列 API 已淘汰，但仍可使用：

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor (適用於三按鈕操作模式，且 alpha 值為 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

針對指定 Android 15 (API 級別 35) 的應用程式，elegantTextHeight TextView 屬性預設會變成 true，將預設使用的緊湊字型取代為具有大型垂直指標的某些指令碼，以便更容易閱讀。我們推出了精簡字型，以免版面配置中斷；Android 13 (API 級別 33) 允許文字版面配置利用 fallbackLineSpacing 屬性拉長垂直高度，藉此避免許多這類中斷情形。

在 Android 15 中，系統仍會保留精簡字型，因此應用程式可以將 elegantTextHeight 設為 false，以便取得與先前相同的行為，但未來版本不太可能支援這項功能。因此，如果您的應用程式支援下列文字：阿拉伯文、老撾文、緬甸文、泰米爾文、古吉拉特文、卡納達文、馬拉雅拉姆文、奧里雅文、泰盧固文或泰文，請將 elegantTextHeight 設為 true 來測試應用程式。

elegantTextHeight 指定 Android 14 (API 級別 34) 以下版本為目標版本的應用程式行為。

elegantTextHeight 指定 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 的預設行高會因語言代碼而異

在 Android 先前版本中，文字版面配置會拉伸文字高度，以符合與目前語言代碼相符的字型行高。舉例來說，如果內容是日文，由於日文字型的行高略大於拉丁字型，因此文字高度會稍微變高。不過，儘管行高有這些差異，EditText 元素的大小仍保持一致，不受使用語言代碼影響，如下圖所示：

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

針對指定 Android 15 (API 級別 35) 的應用程式，現在會為 EditText 保留最小行高，以便與指定語言代碼的參考字型相符，如以下圖片所示：

三個方塊代表 EditText 元素，可包含英文 (en)、日文 (ja) 和緬甸文 (my) 的文字。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 为目标平台，其中一些变更可能不会立即对您产生影响。不过，虽然您的应用可以访问某些非 SDK 接口（具体取决于应用的目标 API 级别），但只要您使用任何非 SDK 方法或字段，就始终会有很高风险导致应用功能异常。

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

如需详细了解此 Android 版本中的变更，请参阅 Android 15 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息，请参阅对非 SDK 接口的限制。