行為變更：指定 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 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 權限時，啟動前景服務的限制

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

變更應用程式修改零打擾模式全域狀態的時間

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

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

視窗插邊變更

There are two changes related to window insets in Android 15: edge-to-edge is enforced by default, and there are also configuration changes, such as the default configuration of system bars.

邊緣到邊緣強制執行

如果應用程式以 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 遮蔽問題。確認這些較少造訪的畫面沒有遭到遮蔽的 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 來測試應用程式。

複雜字母形狀的 TextView 寬度變化

In previous versions of Android, some cursive fonts or languages that have complex shaping might draw the letters in the previous or next character's area. In some cases, such letters were clipped at the beginning or ending position. Starting in Android 15, a TextView allocates width for drawing enough space for such letters and allows apps to request extra paddings to the left to prevent clipping.

Because this change affects how a TextView decides the width, TextView allocates more width by default if the app targets Android 15 (API level 35) or higher. You can enable or disable this behavior by calling the setUseBoundsForWidth API on TextView.

Because adding left padding might cause a misalignment for existing layouts, the padding is not added by default even for apps that target Android 15 or higher. However, you can add extra padding to preventing clipping by calling setShiftDrawingOffsetForStartOverhang.

The following examples show how these changes can improve text layout for some fonts and languages.

Standard layout for English text in a cursive font. Some of the letters are clipped. Here is the corresponding XML:

<TextView
    android:fontFamily="cursive"
    android:text="java" />

Layout for the same English text with additional width and padding. Here is the corresponding XML:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Standard layout for Thai text. Some of the letters are clipped. Here is the corresponding XML:

<TextView
    android:text="คอมพิวเตอร์" />

Layout for the same Thai text with additional width and padding. Here is the corresponding 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 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 介面的限制」。