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

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

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

核心功能

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

前景服務異動

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

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

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

Android 15 introduces a new timeout behavior to dataSync for apps targeting Android 15 (API level 35) or higher. This behavior also applies to the new mediaProcessing foreground service type.

The system permits an app's dataSync 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(). When Service.onTimeout() is called, the service is no longer considered a foreground service. 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 dataSync did not stop within its timeout: [component name]"

To avoid problems with this behavior change, you can do one or more 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 dataSync 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 dataSync 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 dataSync foreground service, use an alternative API.

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

Testing

To test your app's behavior, you can enable data sync 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 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. 請改用 WorkManager 等其他 API，而非 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

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

Apps that target Android 15 (API level 35) and higher can no longer change the global state or policy of Do Not Disturb (DND) on a device (either by modifying user settings, or turning off DND mode). Instead, apps must contribute an AutomaticZenRule, which the system combines into a global policy with the existing most-restrictive-policy-wins scheme. Calls to existing APIs that previously affected global state (setInterruptionFilter, setNotificationPolicy) result in the creation or update of an implicit AutomaticZenRule, which is toggled on and off depending on the call-cycle of those API calls.

Note that this change only affects observable behavior if the app is calling setInterruptionFilter(INTERRUPTION_FILTER_ALL) and expects that call to deactivate an AutomaticZenRule that was previously activated by their owners.

OpenJDK API 變更

Android 15 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases.

Some of these changes can affect app compatibility for apps targeting Android 15 (API level 35):

• Changes to string formatting APIs: Validation of argument index, flags, width, and precision are now more strict when using the following String.format() and Formatter.format() APIs:

  • String.format(String, Object[])
  • String.format(Locale, String, Object[])
  • Formatter.format(String, Object[])
  • Formatter.format(Locale, String, Object[])

  For example, the following exception is thrown when an argument index of 0 is used (%0 in the format string):

  IllegalFormatArgumentIndexException: Illegal format argument index = 0
  

  In this case, the issue can be fixed by using an argument index of 1 (%1 in the format string).

• Changes to component type of Arrays.asList(...).toArray(): When using Arrays.asList(...).toArray(), the component type of the resulting array is now an Object—not the type of the underlying array's elements. So the following code throws a ClassCastException:

  String[] elements = (String[]) Arrays.asList("one", "two").toArray();
  

  For this case, to preserve String as the component type in the resulting array, you could use Collection.toArray(Object[]) instead:

  String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
  

• Changes to language code handling: When using the Locale API, language codes for Hebrew, Yiddish, and Indonesian are no longer converted to their obsolete forms (Hebrew: iw, Yiddish: ji, and Indonesian: in). When specifying the language code for one of these locales, use the codes from ISO 639-1 instead (Hebrew: he, Yiddish: yi, and Indonesian: id).

• Changes to random int sequences: Following the changes made in https://bugs.openjdk.org/browse/JDK-8301574, the following Random.ints() methods now return a different sequence of numbers than the Random.nextInt() methods do:

  • Random.ints(long)
  • Random.ints(long, int, int)
  • Random.ints(int, int)
  • Random.ints()

  Generally, this change shouldn't result in app-breaking behavior, but your code shouldn't expect the sequence generated from Random.ints() methods to match Random.nextInt().

The new SequencedCollection API can affect your app's compatibility after you update compileSdk in your app's build configuration to use Android 15 (API level 35):

• Collision with MutableList.removeFirst() and MutableList.removeLast() extension functions in kotlin-stdlib

  The List type in Java is mapped to the MutableList type in Kotlin. Because the List.removeFirst() and List.removeLast() APIs have been introduced in Android 15 (API level 35), the Kotlin compiler resolves function calls, for example list.removeFirst(), statically to the new List APIs instead of to the extension functions in kotlin-stdlib.

  If an app is re-compiled with compileSdk set to 35 and minSdk set to 34 or lower, and then the app is run on Android 14 and lower, a runtime error is thrown:

  java.lang.NoSuchMethodError: No virtual method
  removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
  

  The existing NewApi lint option in Android Gradle Plugin can catch these new API usages.

  ./gradlew lint
  
  MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
        list.removeFirst()
  

  To fix the runtime exception and lint errors, the removeFirst() and removeLast() function calls can be replaced with removeAt(0) and removeAt(list.lastIndex) respectively in Kotlin. If you're using Android Studio Ladybug | 2024.1.3 or higher, it also provides a quick fix option for these errors.

  Consider removing @SuppressLint("NewApi") and lintOptions { disable 'NewApi' } if the lint option has been disabled.

• Collision with other methods in Java

  New methods have been added into the existing types, for example, List and Deque. These new methods might not be compatible with the methods with the same name and argument types in other interfaces and classes. In the case of a method signature collision with incompatibility, the javac compiler outputs a build-time error. For example:

  Example error 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
  

  Example error 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
  

  Example 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
  

  To fix these build errors, the class implementing these interfaces should override the method with a compatible return type. For example:

  @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) 起，系統會限制啟動背景活動。

其他變更

• 將 PendingIntent 建立者變更為預設封鎖背景活動啟動程序。這有助於防止應用程式意外建立 PendingIntent，避免惡意人士濫用。
• 除非PendingIntent傳送者允許，否則請勿將應用程式移至前景。這項異動旨在防止惡意應用程式濫用在背景啟動活動的功能。根據預設，應用程式不得將工作堆疊帶到前景，除非建立者允許啟動背景活動的權限，或傳送者具有啟動背景活動的權限。
• 控制工作堆疊頂端活動完成工作的方式。如果頂端活動完成工作，Android 會返回上次啟用的工作。此外，如果非頂端活動完成任務，Android 會返回主畫面，不會封鎖這個非頂端活動的完成作業。
• 防止其他應用程式在您的工作階段中啟動任意活動。這項異動可防止惡意應用程式建立看似來自其他應用程式的活動，藉此網路釣魚。
• 禁止將非可見視窗納入背景活動啟動程序。這樣一來，惡意應用程式就無法濫用背景活動啟動功能，向使用者顯示不當或惡意內容。

更安全的意圖

Android 15 introduces StrictMode for intents.

In order to see detailed logs about Intent usage violations, use following method:

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

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

使用者體驗和系統 UI

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

視窗插邊變更

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

Edge-to-edge enforcement

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

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

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

• 您有非浮動視窗，例如使用 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

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 開始，這項屬性已遭淘汰。
• 自 API 級別 33 起，Display.getMetrics() 就已採用這種運作方式。

elegantTextHeight 屬性預設為 true

For apps targeting Android 15 (API level 35), 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.

複雜字母形狀的 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 以上版本的應用程式，進行了下列攝影機和媒體行為變更。

要求音訊焦點的限制

Apps that target Android 15 (API level 35) must be the top app or running a foreground service in order to request audio focus. If an app attempts to request focus when it does not meet one of these requirements, the call returns AUDIOFOCUS_REQUEST_FAILED.

You can learn more about audio focus at Manage audio focus.

更新非 SDK 限制

基於與 Android 開發人員合作及最新的內部測試，Android 15 包含更新後的受限制非 SDK 介面清單。在限制非 SDK 介面之前，我們盡可能確保公開替代方案的可得性。

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

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

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