このページは Cloud Translation API によって翻訳されました。

動作の変更点: Android 15 以降をターゲットとするアプリ

以前のリリースと同様に、Android 15 では、説明します。以下の動作変更は、 Android 15 以降がターゲットになります。Android 15 以降をターゲットとするアプリの場合、これらの動作を適切にサポートするようにアプリを修正する必要があります。適用されます。

すべてのアプリに影響する動作変更のリストも必ずご確認ください。アプリの targetSdkVersion に関係なく、Android 15 で実行されるデバイスに限られます。

コア機能

Android 15 では、Android システムのさまざまなコア機能を変更または拡張しています。

フォアグラウンドサービスの変更

Android 15 では、フォアグラウンドサービスに次の変更が行われます。

データ同期フォアグラウンドサービスのタイムアウト動作
新しいメディア処理フォアグラウンドサービスタイプ
BOOT_COMPLETED ブロードキャストレシーバによるフォアグラウンドサービスの起動に関する制限
アプリが SYSTEM_ALERT_WINDOW 権限を保持している場合のフォアグラウンドサービスの起動に関する制限

データ同期フォアグラウンドサービスのタイムアウト動作

Android 15 では、アプリターゲティングでの dataSync に新しいタイムアウト動作が導入されています Android 15（API レベル 35）以降。この動作は、新しい mediaProcessing フォアグラウンドサービスタイプ。

システムはアプリの dataSync サービスを合計 6 時間実行できます。 24 時間以内に実行中のサービスのデータが呼び出されます。 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() 表示されます。（アプリをすぐに停止しないと、失敗します）。
アプリの dataSync サービスの実行時間が合計 24 時間あたり 6 時間（ユーザーがアプリを操作した場合を除く）タイマーのリセットなど）。
直接的なユーザーの結果としてのみ dataSync フォアグラウンドサービスを開始やり取りアプリがフォアグラウンドにあるため、アプリがバックグラウンドに移行してから 6 時間が経過するまで待ってから、
dataSync フォアグラウンドサービスの代わりに、代替 API。

アプリの dataSync フォアグラウンドサービスが過去 6 時間実行された場合 24 で、別の dataSync フォアグラウンドサービスを開始できるのは、ユーザーが アプリがフォアグラウンドになった（タイマーがリセットされます）。エラーを別の dataSync フォアグラウンドサービスを開始すると、システムがスローする ForegroundServiceStartNotAllowedException 「Time limit already reached for front service」などのエラーメッセージが表示される type 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 サービスの合計 6 回の実行を許可します。 24 時間（24 時間以内）であれば、実行中のサービスの 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]"

例外を回避するには、次のいずれかを行います。

サービスに新しい Service.onTimeout(int, int) メソッドを実装します。アプリがコールバックを受信したら、stopSelf() 表示されます。（アプリをすぐに停止しないと、失敗します）。
アプリの mediaProcessing サービスが合計 24 時間あたり 6 時間（ユーザーがアプリを操作した場合を除く）タイマーのリセットなど）。
直接的なユーザーの結果としてのみ mediaProcessing フォアグラウンドサービスを開始やり取りアプリがフォアグラウンドにあるため、アプリがバックグラウンドに移行してから 6 時間が経過するまで待ってから、
mediaProcessing フォアグラウンドサービスの代わりに、 API（WorkManager など）を呼び出すことができます。

この期間内に、アプリの mediaProcessing フォアグラウンドサービスが 6 時間実行された場合は、過去 24 日間、次の場合を除き、別の mediaProcessing フォアグラウンドサービスを開始することはできません。ユーザーがアプリをフォアグラウンドにしたとき（これによりタイマーがリセットされます）。もし別の mediaProcessing フォアグラウンドサービスを開始しようとすると、システムがスローする ForegroundServiceStartNotAllowedException 「Time limit already reached for front service」などのエラーメッセージが表示されるタイプ mediaProcessing」があります。

mediaProcessing サービスタイプの詳細については、サービスタイプの変更 Android 15 のフォアグラウンドサービスタイプ: メディア処理

テスト

アプリの動作をテストするには、メディア処理のタイムアウトをアプリが Android 15 をターゲットとしていない（アプリが Android 15 デバイス）。タイムアウトを有効にするには、次の adb コマンドを実行します。

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

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 为目标平台的应用无法再更改设备上的全局状态或勿扰 (DND) 政策（通过修改用户设置或关闭 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：
例如，当参数索引为 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() 方法生成的序列匹配Random.nextInt()。

新的 SequencedCollection API 可能会影响应用的兼容性当您在应用的 build 配置中更新 compileSdk 以使用 Android 15（API 级别 35）：

与 MutableList.removeFirst() 和 kotlin-stdlib 中的 MutableList.removeLast() 扩展函数

Java 中的 List 类型会映射到 Kotlin 中的 MutableList 类型。由于使用 List.removeFirst() 和 List.removeLast() API 已在 Android 15（API 级别 35）中引入，Kotlin 编译器将函数调用（例如 list.removeFirst()）静态解析为新的 List API，而不是对 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 错误，removeFirst() 和 removeLast() 函数调用可替换为 removeAt(0)， removeAt(list.lastIndex)（在 Kotlin 中分别对应）。如果您使用的是 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.getLast();
}

セキュリティ

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 のクリエイターを変更してバックグラウンドアクティビティの起動をブロックするよう変更するデフォルトです。これにより、アプリが誤って IP アドレスを PendingIntent: 悪意のある人物によって悪用されるおそれがあります。
PendingIntent の送信者がない限りアプリをフォアグラウンドに戻さない許可します。この変更は、悪意のあるアプリによってバックグラウンドでアクティビティを開始する機能。デフォルトでは、アプリがクリエイターが許可しない限り、タスクスタックをフォアグラウンドに移すことができるバックグラウンドアクティビティの起動権限がある、または送信者にバックグラウンドアクティビティがあるできます。
タスクスタックのトップアクティビティがタスクを終了する方法を制御する。もし上位のアクティビティがタスクを終了すると、Android は最後のアクティブな状態。さらに、トップ以外のアクティビティがそのタスクを完了すると、Android はホーム画面に戻ります。このノントップスレッドのできます。
他のアプリから自分のアクティビティに任意のアクティビティを起動できないようにするタスクです。この変更により、悪意のあるアプリがユーザーをフィッシング攻撃から他のアプリからと思われるアクティビティ
非表示のウィンドウがバックグラウンドアクティビティの対象とみなされないようにブロックする。これにより、悪意のあるアプリによるバックグラウンドの不正使用を防ぐことができます望ましくないコンテンツや悪意のあるコンテンツをユーザーに表示する。

より安全なインテント

Android 15 では、インテントをより安全にする新たなセキュリティ対策が導入されている構築できます今回の変更は、潜在的な脆弱性を回避し、悪意のあるアプリに悪用される恐れのあるインテントの不正使用主に 2 つの Android 15 でインテントのセキュリティが改善されました。

一致ターゲットのインテントフィルタ: 特定のコンポーネントをターゲットとするインテントでは、ターゲットのインテントフィルタ仕様と正確に一致しているかどうかを確認します。。別のアプリのアクティビティを起動するインテントがある場合は、ターゲットインテントコンポーネントが受信側アクティビティの宣言されたインテントフィルタと一致している。
インテントにアクションを含める: アクションのないインテントは一致しなくなります。すべてのインテントフィルタが含まれます。つまり、アクティビティやイベントの開始に明確に定義されたアクションが必要です
ペンディングインテント: ペンディングインテントの作成者保留中のインテントの送信者ではなく、含まれるインテントの送信者として扱われる。インテント

で確認できます。

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 のウィンドウインセットに関連する変更点は 2 つあります。エッジツーエッジがデフォルトで適用されます。もう 1 つは、システムバーのデフォルト構成などの構成の変更です。

エッジツーエッジの適用

在搭载 Android 15 的设备上，应用会默认采用全屏以 Android 15（API 级别 35）为目标平台。

一款以 Android 14 为目标平台且在 Android 设备上未处于无边框的应用 Android 15 设备。

</ph>

一款以 Android 15（API 级别 35）为目标平台且采用无边框的应用在 Android 15 设备上。此应用主要使用 Material 3 Compose 组件自动应用边衬区此屏幕不会受到 Android 15 全屏强制执行。

这是一项可能会对应用的界面产生负面影响的破坏性更改。通过更改会影响以下界面区域：

手势手柄导航栏 <ph type="x-smartling-placeholder">
- 默认透明。
- 底部偏移量已停用，因此内容绘制在系统导航栏后面栏。
- setNavigationBarColor和R.attr#navigationBarColor 已弃用，不会影响手势导航。
- setNavigationBarContrastEnforced和 R.attr#navigationBarContrastEnforced不会对手势导航。
“三按钮”导航 <ph type="x-smartling-placeholder">
- 默认不透明度设为 80%，颜色可能与窗口一致背景。
- 底部偏移值已停用，因此内容绘制在系统导航栏后面除非应用了边衬区。
- setNavigationBarColor和R.attr#navigationBarColor 默认设置为与窗口背景匹配。窗口背景必须是颜色可绘制对象，才能应用此默认值。此 API 是但会继续影响“三按钮”导航。
- setNavigationBarContrastEnforced和 R.attr#navigationBarContrastEnforced 默认为 true，这会添加一个 “三按钮”导航模式显示 80% 不透明的背景。
状态栏 <ph type="x-smartling-placeholder">
- 默认透明。
- 顶部偏移量已停用，因此除非边衬区。
- setStatusBarColor和R.attr#statusBarColor 已废弃，对 Android 15 没有任何影响。
- setStatusBarContrastEnforced和 R.attr#statusBarContrastEnforced 已弃用，但仍具有对 Android 15 的影响。
刘海屏 <ph type="x-smartling-placeholder">
- layoutInDisplayCutoutMode 的非浮动窗口必须是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS。SHORT_EDGES、NEVER和系统会将 DEFAULT 解释为 ALWAYS，这样用户就不会看到黑色图标长条形尺寸，显示为无边框。

以下示例显示了定位前后的应用 Android 15（API 级别 35）以及应用边衬区之前和之后。

。 <ph type="x-smartling-placeholder">

一款以 Android 15（API 级别 35）为目标平台且为无边框应用在 Android 15 设备上。不过，许多元素栏、“三按钮”导航栏或刘海屏（由于 Android 15）全屏强制措施。隐藏界面包含 Material 2 顶部应用栏、悬浮操作按钮和列表项。

。 <ph type="x-smartling-placeholder">

如果应用以 Android 15（API 级别 35）为目标平台， Android 15 设备并应用边衬区，这样界面就不会已隐藏。

检查应用是否已采用全屏的检查步骤

如果您的应用已经采用无边框且应用了边衬区，基本未受影响，但下列情况除外。但即使您认为您不会受到影响，但我们建议您测试自己的应用。

您的非浮动窗口（例如 Activity）使用 SHORT_EDGES、NEVER 或 DEFAULT，而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS。如果您的应用在启动时崩溃可能是启动画面所致您可以升级核心初始屏幕依赖项更改为 1.2.0-alpha01 或更高版本，或者设置 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always。
可能会有流量较低的屏幕显示被遮挡的界面。验证这些访问较少的屏幕也不会显示被遮挡的界面。流量较低的屏幕包括： <ph type="x-smartling-placeholder">
- 初始配置或登录屏幕
- “设置”页面

如何检查应用尚未实现无边框

如果您的应用还没有全面屏，那么您很可能会受到影响。在除了针对已经采用无边框的应用的情况之外，请考虑以下事项：

如果您的应用使用 Material 3 组件 ( androidx.compose.material3)，例如 TopAppBar， BottomAppBar 和 NavigationBar，那么这些组件可能不会受到影响，因为它们会自动处理边衬区。
如果您的应用使用 Material 2 组件 ( androidx.compose.material），那么这些组件不会自动处理边衬区。不过，您可以使用边衬区并手动应用这些设置在 androidx.compose.material 1.6.0 中然后使用 windowInsets 参数手动应用边衬区 BottomAppBar、TopAppBar、 BottomNavigation 和 NavigationRail。同样，对以下内容使用 contentWindowInsets 形参： Scaffold。
如果您的应用使用视图和 Material 组件 (com.google.android.material)，大多数基于 View 的 Material 如 BottomNavigationView、BottomAppBar、 NavigationRailView 或 NavigationView，处理边衬区，不需要额外工作。但是，您需要将 android:fitsSystemWindows="true" 如果使用 AppBarLayout，则会发生此错误。
对于自定义可组合项，请手动将边衬区作为内边距应用。如果您的内容位于 Scaffold 内，因此您可以使用 Scaffold 来使用边衬区内边距值。否则，使用 WindowInsets。
如果您的应用使用的是视图和 BottomSheet、SideSheet 或自定义使用 ViewCompat.setOnApplyWindowInsetsListener。对于 RecyclerView，使用此监听器应用内边距，同时添加 clipToPadding="false"。

检查应用是否必须提供自定义后台保护的注意事项

如果您的应用必须为“三按钮”导航或状态栏，则应用应将可组合项或视图放在系统栏后面使用 WindowInsets.Type#tappableElement() 获取三按钮导航栏高度或 WindowInsets.Type#statusBars。

其他无边框资源

请参阅无边框视图和无边框 Compose 了解应用边衬区的其他注意事项。

已弃用的 API

以下 API 现已弃用：

安定した構成

如果您的应用以 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 已废弃。
从 API 级别 33 开始，Display.getMetrics() 已采用这种方式。

sensitiveTextHeight 属性のデフォルトを true に設定

对于以 Android 15 为目标平台的应用，elegantTextHeight TextView 属性默认变为 true，将默认使用的紧凑字体替换为一些具有较大垂直指标的脚本，并且这种字体更易于阅读。紧凑字体的引入是为了防止破坏布局；Android 13（API 级别 33）允许文本布局利用 fallbackLineSpacing 属性拉伸垂直高度，以防止许多此类破坏。

在 Android 15 中，紧凑字体仍保留在系统中，因此您的应用可以将 elegantTextHeight 设置为 false，以获得与之前相同的行为，但即将在未来版本中提供支持。因此，如果您的应用支持以下文字：阿拉伯语、老挝语、缅甸、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语，请将 elegantTextHeight 设置为 true，以测试应用。

以 Android 14（API 级别 34）及更低版本为目标平台的应用的 `elegantTextHeight` 行为。

以 Android 15 为目标平台的应用的 `elegantTextHeight` 行为。

複雑な文字形状における TextView の幅の変化

以前のバージョンの Android では、手書きメモのフォントや言語には複雑なシェーピングでは、前または次の文字の領域に文字が描画されることがあります。場合によっては、このような文字が先頭や末尾で切り取られていました。 Android 15 以降では、TextView が十分なスペースを描画するために幅を割り当てます。追加のパディングをアプリでリクエストして、クリッピングを防止できます

この変更は TextView が幅を決定する方法に影響するため、TextView アプリが Android 15（API レベル 35）または高くなります。この動作は、 setUseBoundsForWidth API（TextView）。

左パディングを追加すると既存のレイアウトがずれる可能性があるため、 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` 要素を表す 3 つのボックス。英語（en）、日本語（ja）、ビルマ語（my）のテキストを含めることができます。これらの言語の行の高さは異なりますが、`EditText` の高さは同じです。

Android 15 をターゲットとするアプリでは、次の図に示すように、指定された言語 / 地域の参照フォントと一致するように、EditText の最小行の高さが予約されています。

`EditText` 要素を表す 3 つのボックス。英語（en）、日本語（ja）、ビルマ語（my）のテキストを含めることができます。`EditText` の高さには、これらの言語のフォントのデフォルトの行の高さに対応するスペースが含まれています。

必要に応じて、useLocalePreferredLineHeightForMinimum 属性を false に指定することで以前の動作を復元できます。また、Kotlin と Java で setMinimumFontMetrics API を使用してカスタムの最小業種指標を設定できます。

カメラとメディア

Android 15 では、アプリのカメラとメディアの動作が次のように変更されます Android 15 以降をターゲットとするアプリである必要があります。

音声フォーカスのリクエストに関する制限

音声フォーカスをリクエストするには、Android 15 をターゲットとするアプリが最上位のアプリであるか、フォアグラウンドサービスを実行している必要があります。アプリがこれらの要件のいずれかを満たしていないときにフォーカスをリクエストしようとすると、呼び出しは AUDIOFOCUS_REQUEST_FAILED を返します。

音声フォーカスの詳細については、音声フォーカスの管理をご覧ください。

非 SDK の制限の更新

Android 15 包含更新后的受限非 SDK 列表基于与 Android 开发者之间的协作以及最新的内部测试在限制使用非 SDK 接口之前，我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 15 为目标平台，其中一些变更可能不会立即对您产生影响。不过，虽然您的应用可以访问某些非 SDK 接口具体取决于应用的目标 API 级别，使用任何非 SDK 均可方法或字段总是很有破坏应用的风险。

如果您不确定自己的应用是否使用了非 SDK 接口，可以测试您的应用，找出答案。如果您的应用依赖于非 SDK 接口，则应开始计划迁移到 SDK 替代方案。尽管如此，我们了解到，某些应用具有非 SDK 接口。如果您无法找到使用非 SDK 的替代方案应用某项功能的界面，您应该请求新的公共 API。

Android の今回のリリースの変更について詳しくは、非 SDK インターフェースの制限に関する Android 15 での変更点をご覧ください。非 SDK インターフェース全般について詳しくは、非 SDK インターフェースの制限をご覧ください。