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

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

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

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

核心功能

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. 請改用其他 API，而非 dataSync 前景服務。

如果應用程式的 dataSync 前景服務在過去 24 小時內已執行 6 小時，則「除非」使用者將應用程式移至前景 (會重設計時器)，否則您無法啟動另一項 dataSync 前景服務。如果您嘗試啟動另一項 dataSync 前景服務，系統會擲回 ForegroundServiceStartNotAllowedException，並顯示錯誤訊息「Time limit is Of for 前景服務類型 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 introduces a new foreground service type, mediaProcessing. This service type is appropriate for operations like transcoding media files. For example, a media app might download an audio file and need to convert it to a different format before playing it. You can use a mediaProcessing foreground service to make sure the conversion continues even while the app is in the background.

The system permits an app's mediaProcessing services to run for a total of 6 hours in a 24-hour period, after which the system calls the running service's Service.onTimeout(int, int) method (introduced in Android 15). At this time, the service has a few seconds to call Service.stopSelf(). If the service does not call Service.stopSelf(), the system throws an internal exception. The exception is logged in Logcat with the following message:

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

To avoid having the exception, you can do one of the following:

1. Have your service implement the new Service.onTimeout(int, int) method. When your app receives the callback, make sure to call stopSelf() within a few seconds. (If you don't stop the app right away, the system generates a failure.)
2. Make sure your app's mediaProcessing services don't run for more than a total of 6 hours in any 24-hour period (unless the user interacts with the app, resetting the timer).
3. Only start mediaProcessing foreground services as a result of direct user interaction; since your app is in the foreground when the service starts, your service has the full six hours after the app goes to the background.
4. Instead of using a mediaProcessing foreground service, use an alternative API, like WorkManager.

If your app's mediaProcessing foreground services have run for 6 hours in the last 24, you cannot start another mediaProcessing foreground service unless the user has brought your app to the foreground (which resets the timer). If you try to start another mediaProcessing foreground service, the system throws ForegroundServiceStartNotAllowedException with an error message like "Time limit already exhausted for foreground service type mediaProcessing".

For more information about the mediaProcessing service type, see Changes to foreground service types for Android 15: Media processing.

Testing

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

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

You can also adjust the timeout period, to make it easier to test how your app behaves when the limit is reached. To set a new timeout period, run the following adb command:

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 類型。由於 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 包含提升系統安全性的變更，可協助保護應用程式和使用者免受惡意應用程式的侵害。

受限 TLS 版本

Android 15 會限制 TLS 1.0 和 1.1 版本的使用。這些版本先前已在 Android 中淘汰，但現在已禁止用於指定 Android 15 為目標版本的應用程式。

安全的背景活動啟動

Android 15 可保護使用者不受惡意應用程式侵擾，並讓使用者進一步控管 方法是加入可防止惡意背景應用程式的變更 將其他應用程式移至前景、提升其權限並濫用 互動。自以下日期起，系統已限制啟動背景活動： Android 10 (API 級別 29)。

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

惡意應用程式可能會在同一工作中啟動其他應用程式的活動，然後 疊加在上，營造出該應用程式的錯覺這項「工作」 駭客」攻擊會避開目前的背景啟動限制，因為這 發生在相同的可見工作中為降低這種風險，Android 15 新增了 旗標，防止應用程式啟動與堆疊上頂層 UID 不符的應用程式 活動。如要選擇加入應用程式的所有活動，請更新 allowCrossUidActivitySwitchFromBelow敬上 屬性加入應用程式的 AndroidManifest.xml 檔案中：

<application android:allowCrossUidActivitySwitchFromBelow="false" >

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

• 執行啟動作業的應用程式以 Android 15 為目標。
• 工作堆疊頂端的應用程式以 Android 15 為目標。
• 所有可見的活動已選擇採用新的保護措施

啟用安全措施後，應用程式可能會返回主畫面，而非 則最後顯示的應用程式。

其他變更

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

• 變更 PendingIntent 位創作者，禁止開啟背景活動，包括： default。這可避免應用程式意外 PendingIntent，可能遭不肖人士濫用。
• 除非 PendingIntent 傳送者，否則請勿將應用程式移至前景 這項異動旨在避免惡意應用程式濫用 可在背景啟動活動根據預設，應用程式 允許將工作堆疊移至前景，除非創作者允許 背景活動啟動權限或傳送者有背景活動 啟動權限。
• 控管工作堆疊的主要活動如何完成任務。如果 完成一項任務後，Android 就會回到 上次使用時間。此外，如果非頂層活動完成任務，Android 就會 返回主畫面。也不會阻斷 活動。
• 避免從其他應用程式啟動任意活動 工作。這項變更藉由建立 假冒其他應用程式的活動。
• 禁止將不可見的視窗視為背景活動 產品發布。避免惡意應用程式濫用背景 使用者啟動活動後，系統會顯示擾人或惡意的內容。

更安全的意圖

Android 15 推出了新的選用安全措施，讓意圖更安全可靠。這些異動旨在防止意圖遭到惡意應用程式濫用，並避免潛在的安全漏洞。Android 15 針對意圖的安全性進行了兩項主要改善：

• 比對目標意圖篩選器：如果意圖指定特定元件，就必須準確符合目標的意圖篩選器規格。如果您傳送意圖來啟動其他應用程式的活動，目標意圖元件必須與接收活動宣告的意圖篩選器相符。
• 意圖必須包含動作：沒有動作的意圖將不再與任何意圖篩選器相符。也就是說，用於啟動活動或服務的意圖必須有明確的動作定義。

如要檢查應用程式如何回應這些變更，請在應用程式中使用 StrictMode。如要查看 Intent 使用違規的詳細記錄，請新增下列方法：

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

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

使用者體驗和系統使用者介面

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

視窗插邊變更

Android 15 有兩項與視窗內嵌相關的變更：預設會強制執行邊到邊，且有設定變更，例如系統列的預設設定。

Edge-to-edge enforcement

Apps are edge-to-edge by default on devices running Android 15 if the app is targeting Android 15 (API level 35).

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.

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, your 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 deprecated but not disabled:

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor (for 3 button navigation, with 80% alpha)
• Window#isStatusBarContrastEnforced
• Window#setNavigationBarColor (for 3 button navigation, with 80% alpha)
• Window#setStatusBarContrastEnforced

The following APIs are deprecated and disabled:

• R.attr#navigationBarColor (for gesture navigation)
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#setDecorFitsSystemWindows
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#setNavigationBarColor (for gesture navigation)
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor

Stable configuration

如果應用程式指定 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 開發人員合作及最新的內部測試，Android 15 包含更新後的受限制非 SDK 介面清單。在限制非 SDK 介面之前，我們盡可能確保公開替代方案的可得性。

如果您的應用程式並未以 Android 15 為目標版本，則此處所述的某些變更可能不會立即對您造成影響。不過，雖然應用程式可以存取某些非 SDK 介面 (視應用程式的目標 API 級別而定)，但使用任何非 SDK 方法或欄位時，均可能面臨應用程式故障的高度風險。

如果不確定應用程式是否使用非 SDK 介面，您可以測試應用程式來確認。如果您的應用程式仰賴非 SDK 介面，則建議您開始規劃遷移至 SDK 替代方案。不過，我們瞭解有些應用程式可使用非 SDK 介面運作。如果您除了為應用程式中的某個功能使用非 SDK 介面外，已別無他法，則應要求新的公用 API。

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