行為變更：指定 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

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

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 持續更新 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 restricts the usage of TLS versions 1.0 and 1.1. These versions had previously been deprecated in Android, but are now disallowed for apps targeting Android 15.

安全啟動背景活動

Android 15 protects users from malicious apps and gives them more control over their devices by adding changes that prevent malicious background apps from bringing other apps to the foreground, elevating their privileges, and abusing user interaction. Background activity launches have been restricted since Android 10 (API level 29).

Other changes

In addition to the restriction for UID matching, these other changes are also included:

• Change PendingIntent creators to block background activity launches by default. This helps prevent apps from accidentally creating a PendingIntent that could be abused by malicious actors.
• Don't bring an app to the foreground unless the PendingIntent sender allows it. This change aims to prevent malicious apps from abusing the ability to start activities in the background. By default, apps are not allowed to bring the task stack to the foreground unless the creator allows background activity launch privileges or the sender has background activity launch privileges.
• Control how the top activity of a task stack can finish its task. If the top activity finishes a task, Android will go back to whichever task was last active. Moreover, if a non-top activity finishes its task, Android will go back to the home screen; it won't block the finish of this non-top activity.
• Prevent launching arbitrary activities from other apps into your own task. This change prevents malicious apps from phishing users by creating activities that appear to be from other apps.
• Block non-visible windows from being considered for background activity launches. This helps prevent malicious apps from abusing background activity launches to display unwanted or malicious content to users.

更安全的意圖

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

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

如要檢查應用程式如何回應這些變更，請在應用程式中使用 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 有兩項與視窗內嵌相關的變更：預設會強制執行邊到邊，且有設定變更，例如系統列的預設設定。

邊緣到邊緣強制執行

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. This example is not comprehensive, this might appear differently on Android Auto.

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

穩定設定

如果應用程式指定 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 以上版本的應用程式，進行了下列攝影機和媒體行為變更。

要求音訊焦點的限制

指定 Android 15 (API 級別 35) 為目標版本的應用程式必須是頂層應用程式，或執行前景服務，才能要求音訊焦點。如果應用程式在未符合上述任一規定的情況下嘗試要求焦點，則呼叫會傳回 AUDIOFOCUS_REQUEST_FAILED。

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

更新非 SDK 限制

Android 15 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 15, some of these changes might not immediately affect you. However, while it's possible for your app to access some non-SDK interfaces depending on your app's target API level, using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you can't find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.

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