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

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

以前のリリースと同様に、Android 15 には、アプリに影響する可能性がある動作変更が含まれています。以下の動作変更は、Android 15 以上をターゲットとするアプリにのみ適用されます。Android 15 以降をターゲットとするアプリの場合は、必要に応じてアプリを修正し、下記の動作に正しく対応できるようにする必要があります。

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

コア機能

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

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

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

新しいメディア処理フォアグラウンドサービスタイプ
フォアグラウンドサービスを起動する BOOT_COMPLETED ブロードキャストレシーバに関する制限

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

Android 15 では、Android 15 以降をターゲットとするアプリ向けに、dataSync に新しいタイムアウト動作が導入されています。この動作は、新しい mediaProcessing フォアグラウンドサービスタイプにも適用されます。

システムは、アプリの dataSync サービスを 24 時間で合計 6 時間実行することを許可し、その後、実行中のサービスの Service.onTimeout(int, int) メソッド（Android 15 で導入）を呼び出します。この時点で、サービスが Service.stopSelf() を呼び出すために数秒かかります。Service.onTimeout() が呼び出されると、サービスはフォアグラウンドサービスと見なされなくなります。サービスが Service.stopSelf() を呼び出さないと、「<fgs_type> のフォアグラウンドサービスがタイムアウト内に停止しませんでした: <component_name>」というエラーメッセージが表示され、エラーが発生します。ベータ版 2 では、失敗メッセージは ANR として表示されますが、今後のベータ版リリースでは、カスタム例外がスローされます。

この動作変更による問題を回避するには、次のいずれかを行います。

サービスに新しい Service.onTimeout(int, int) メソッドを実装させます。アプリがコールバックを受信したら、必ず数秒以内に stopSelf() を呼び出します。（アプリをすぐに停止しないと、エラーが発生します）。
アプリの dataSync サービスが 24 時間で合計 6 時間以上実行されないようにします（ユーザーがアプリを操作してタイマーをリセットする場合を除く）。
dataSync フォアグラウンドサービスは、ユーザーの直接操作の結果としてのみ開始してください。サービスの開始時にアプリがフォアグラウンドにあるため、サービスはアプリがバックグラウンドに移動してから 6 時間かかります。
dataSync フォアグラウンドサービスを使用する代わりに、代替 API を使用します。

アプリの dataSync フォアグラウンドサービスが過去 24 日間に 6 時間実行されている場合、ユーザーがアプリをフォアグラウンドに移動した場合（タイマーがリセットされる）でない限り、別の dataSync フォアグラウンドサービスを開始することはできません。別の dataSync フォアグラウンドサービスを開始しようとすると、システムは ForegroundServiceStartNotAllowedException をスローし、「DataSync タイプのフォアグラウンドサービスの制限時間はすでに上限に達しています」などのエラーメッセージを返します。

新しいメディア処理フォアグラウンドサービスタイプ

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]"

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

サービスに新しい Service.onTimeout(int, int) メソッドを実装します。アプリがコールバックを受信したら、数秒以内に stopSelf() を呼び出します。（アプリをすぐに停止しないと、エラーが生成されます）。
アプリの mediaProcessing サービスが、24 時間で合計 6 時間を超えて実行されないようにする（ユーザーがアプリを操作してタイマーをリセットする場合を除きます）。
mediaProcessing フォアグラウンドサービスは、直接的なユーザー操作の結果としてのみ起動します。サービスの開始時にアプリはフォアグラウンドにあるため、サービスはバックグラウンドに移行してから 6 時間すべてかかります。
mediaProcessing フォアグラウンドサービスを使用する代わりに、WorkManager などの代替 API を使用してください。

アプリの 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（この制限は Android 14 以降 microphone に適用されています）

BOOT_COMPLETED レシーバーがこの種のフォアグラウンドサービスを起動しようとすると、システムは ForegroundServiceStartNotAllowedException をスローします。

アプリが `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 をターゲットとするアプリでは、ユーザー設定の変更や DND モードの無効化によって、デバイスのサイレントモード（DND）のグローバル状態またはポリシーを変更できなくなりました。代わりに、アプリは AutomaticZenRule をコントリビューションする必要があります。これにより、システムは既存の most-restrictive-policy-wins スキームとグローバルポリシーを結合します。以前にグローバル状態（setInterruptionFilter、setNotificationPolicy）に影響した既存の API を呼び出すと、暗黙的な AutomaticZenRule の作成または更新が発生します。暗黙的な AutomaticZenRule は、それらの API 呼び出しの呼び出しサイクルに応じてオンとオフが切り替わります。

この変更は、アプリが setInterruptionFilter(INTERRUPTION_FILTER_ALL) を呼び出し、その呼び出しによって以前に所有者によって有効化された AutomaticZenRule が無効化されることを想定している場合にのみ、オブザーバブルな動作に影響します。

OpenJDK API の変更

Android 15 では、最新の OpenJDK LTS リリースの機能に合わせて Android のコアライブラリを更新する取り組みが継続されています。

この変更のいずれかが、Android 15（API レベル 35）をターゲットとするアプリの互換性に影響する可能性があります。

文字列書式設定 API の変更: 次の String.format() API と 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-0、he1、インドネシア語: yi、インドネシア語 / イディッシュ語、{ヘブライ語: yi、イディッシュ語: yi（ヘブライ語: yi、イディッシュ語: yi）に変換してください。id
ランダムな int シーケンスの変更: https://bugs.openjdk.org/browse/JDK-8301574 で行われた変更により、以下の Random.ints() メソッドは、Random.nextInt() メソッドとは異なる数のシーケンスを返すようになりました。
一般的に、この変更によってアプリの互換性を損なう動作は発生しませんが、Random.ints() メソッドから生成されたシーケンスが Random.nextInt() と一致することをコードが想定すべきではありません。

Android 15（API レベル 35）を使用するようにアプリのビルド構成の compileSdk を更新すると、新しい SequencedCollection API はアプリの互換性に影響する可能性があります。

kotlin-stdlib の拡張関数 MutableList.removeFirst() および MutableList.removeLast() との競合

Java の List 型は、Kotlin の MutableList 型にマッピングされます。Android 15（API レベル 35）で List.removeFirst() API と List.removeLast() API が導入されているため、Kotlin コンパイラは、関数呼び出し（list.removeFirst() など）を kotlin-stdlib の拡張関数ではなく、新しい List API に静的に解決します。

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.getLast();
}

セキュリティ

Android 15 では、悪意のあるアプリからアプリやユーザーを保護できるように、システムセキュリティを促進する変更が行われています。

安全なバックグラウンドアクティビティの起動

Android 15 では、悪意のあるバックグラウンドアプリによる他のアプリのフォアグラウンドへの移動、権限の昇格、ユーザー操作の不正使用を防ぐ変更を追加することで、悪意のあるアプリからユーザーを保護し、デバイスをより細かく制御できるようにします。Android 10（API レベル 29）以降、バックグラウンドアクティビティの起動が制限されています。

スタック上の最上位の UID と一致しないアプリがアクティビティを起動できないようにする

悪意のあるアプリは、同じタスク内で別のアプリのアクティビティを起動し、その上に重ねて、そのアプリであるかのように見せかけることができます。この「タスクハイジャック」攻撃は、すべてが同じ表示タスク内で発生するため、現在のバックグラウンド起動制限をすり抜けます。このリスクを軽減するため、Android 15 では、スタックの最上位の UID と一致しないアプリがアクティビティを起動しないようブロックするフラグが追加されています。アプリのすべてのアクティビティをオプトインするには、アプリの AndroidManifest.xml ファイルの allowCrossUidActivitySwitchFromBelow 属性を更新します。

<application android:allowCrossUidActivitySwitchFromBelow="false" >

新しいセキュリティ対策は、次の条件がすべて当てはまる場合に有効になります。

リリースを実行するアプリは Android 15 をターゲットとしています。
タスクスタックの一番上にあるアプリは、Android 15 をターゲットとしています。
表示されるアクティビティはすべて新しい保護設定にオプトインしています

セキュリティ対策が有効になっている場合、アプリが自身のタスクを完了したときに、最後に表示されたアプリではなく、ホームに戻ることがあります。

その他の変更点

UID マッチングの制限に加えて、次のような変更も含まれています。

デフォルトでバックグラウンドアクティビティの起動をブロックするように、PendingIntent 作成者を変更します。これにより、悪意のある人物が悪用するおそれのある PendingIntent をアプリが誤って作成するのを防ぐことができます。
PendingIntent 送信者が許可しない限り、アプリをフォアグラウンドにしない。この変更は、悪意のあるアプリがバックグラウンドでアクティビティを開始する機能を悪用するのを防ぐことを目的としています。デフォルトでは、作成者がバックグラウンドアクティビティの起動権限を許可しているか、送信者がバックグラウンドアクティビティの起動権限を持っていない限り、アプリはタスクスタックをフォアグラウンドにできません。
タスクスタックのトップアクティビティがタスクを終了する方法を制御する。最上位のアクティビティがタスクを終了すると、Android は最後にアクティブだったタスクに戻ります。さらに、トップ以外のアクティビティがタスクを終了すると、Android はホーム画面に戻ります。このトップ以外のアクティビティの終了はブロックされません。
他のアプリから自分のタスクに任意のアクティビティが起動しないようにする。この変更により、他のアプリからのものと思われるアクティビティを作成することで、悪意のあるアプリがユーザーをフィッシングすることを防止できます。
非表示のウィンドウがバックグラウンドアクティビティの起動で考慮されないようにブロックする。これにより、悪意のあるアプリがバックグラウンドアクティビティの起動を悪用して、望ましくないコンテンツや悪意のあるコンテンツを表示することを防止できます。

より安全なインテント

Android 15 では、インテントの安全性と堅牢性を高めるための新しいセキュリティ対策が導入されています。この変更は、悪意のあるアプリによって悪用されるおそれのある潜在的な脆弱性とインテントの不正使用を防止することを目的としています。Android 15 では、インテントのセキュリティに関して、主に 2 つの改善が行われています。

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

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 デバイスの場合です。このアプリは主にマテリアル 3 Compose コンポーネントを使用していますインセットを自動的に適用しますこの画面は Android 15 のエッジツーエッジの適用。

これは互換性を破る変更であり、アプリの UI に悪影響を与える可能性があります。「次の UI 領域に影響します。

ジェスチャーハンドルのナビゲーションバー <ph type="x-smartling-placeholder">
- デフォルトで透過的。
- 下オフセットが無効になっているため、コンテンツがシステムナビゲーションの背後に描画されます使用できます。
- setNavigationBarColor と R.attr#navigationBarColor はサポートは終了しており、ジェスチャーナビゲーションには影響しません。
- setNavigationBarContrastEnforced、 R.attr#navigationBarContrastEnforced は引き続きジェスチャーナビゲーションを使用できます。
3 ボタンナビゲーション <ph type="x-smartling-placeholder">
- 不透明度はデフォルトで 80% に設定され、色はウィンドウと一致する可能性があります説明します。
- 下オフセットを無効にし、コンテンツがシステムナビゲーションバーの後ろに描画される使用できます。
- setNavigationBarColor と R.attr#navigationBarColor はウィンドウの背景と同じになるように設定されます。ウィンドウの背景このデフォルトを適用するには、カラードローアブルである必要があります。この API は、 3 ボタンナビゲーションには影響しますが、引き続き影響します。
- setNavigationBarContrastEnforced、 R.attr#navigationBarContrastEnforced はデフォルトで true であり、 3 ボタンナビゲーション全体の背景が 80% 不透明。
ステータスバー <ph type="x-smartling-placeholder">
- デフォルトで透過的。
- 上オフセットが無効になっているため、コンテンツはステータスバーの背後に描画されます。適用されます。
- setStatusBarColor と R.attr#statusBarColor は Android 15 には影響しません。
- setStatusBarContrastEnforced、 R.attr#statusBarContrastEnforced は非推奨ではあるものの、影響します
ディスプレイカットアウト <ph type="x-smartling-placeholder">
- 非フローティングウィンドウの layoutInDisplayCutoutMode は、 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS。SHORT_EDGES、NEVER、 DEFAULT は ALWAYS として解釈されるため、ユーザーには黒色は表示されません。バーが端から端まで表示されます。

次の例は、ターゲティング前後のアプリを示しています。 Android 15（API レベル 35）、およびインセットの適用前と適用後。

Android 15（API レベル 35）をターゲットとし、エッジツーエッジ対応のアプリ Android 15 デバイスの場合です。ただし、多くの要素がステータスによって非表示になりました。 Android 15 によるバー、3 ボタンナビゲーションバー、ディスプレイカットアウト厳格なコンプライアンス要件があります非表示 UI にマテリアル 2 が含まれるトップアプリバー、フローティングアクションボタン、リストアイテムなどの機能を備えています。

Android 15（API レベル 35）をターゲットとするアプリは、エッジツーエッジ対応インセットを適用して、UI が非表示です。

アプリがすでにエッジツーエッジ対応かどうかを確認する方法

アプリがすでにエッジツーエッジでインセットを適用している場合は、次のようになります。以下の場合を除き、ほとんど影響を受けない。とはいえ、影響を受けない場合は、アプリをテストすることをおすすめします。

非フローティングウィンドウ（Activity など）があり、代わりに SHORT_EDGES、NEVER、DEFAULT を選択 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS。アプリが起動時にクラッシュした場合、スプラッシュ画面が原因かもしれません一方、コアスプラッシュ画面の依存関係を 1.2.0-alpha01 にマッピング以降または window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always を設定します。
トラフィックの少ない画面で UI が遮られることがあります。これらを確認アクセス頻度の低い画面でも UI が遮られることはありません。トラフィックの少ない画面には、次のものがあります。 <ph type="x-smartling-placeholder">
- オンボーディング画面またはログイン画面
- 設定ページ

アプリがエッジツーエッジ対応でないかどうかを確認する方法

まだアプリをエッジツーエッジ対応にしていない場合は、この影響を受ける可能性が高いと考えられます。インすでにエッジツーエッジで処理されているアプリのシナリオに加えて、次の点を考慮してください。

アプリがマテリアル 3 コンポーネント（ androidx.compose.material3 など）を使用した場合（例: TopAppBar）、 BottomAppBar、NavigationBar の場合、これらのコンポーネントはおそらくインセットを自動的に処理できるため影響を受けます
アプリでマテリアル 2 コンポーネント（ androidx.compose.material など）と、インセットは自動的に処理されません。ただし、インセットにはアクセス可能です。手動で適用することもできます。androidx.compose.material 1.6.0 でインセットを手動で適用するには、windowInsets パラメータを使用します。 BottomAppBar、TopAppBar、 BottomNavigation、NavigationRail。同様に、contentWindowInsets パラメータを使用して、 Scaffold.
アプリでビューとマテリアルコンポーネントを使用する場合（com.google.android.material）、視聴回数ベースのほとんどのマテリアル BottomNavigationView、BottomAppBar、 NavigationRailView または NavigationView: インセットを処理し、なります。ただし、android:fitsSystemWindows="true" を追加する必要があります AppBarLayout を使用する場合。
カスタムコンポーザブルの場合は、インセットをパディングとして手動で適用します。お使いのコンテンツが Scaffold 内にある場合は、Scaffold を使用してインセットを使用できます。パディング値を指定します。それ以外の場合は、次のいずれかを使用してパディングを適用します。 WindowInsets.
アプリがビューと、BottomSheet、SideSheet、またはカスタムを使用している場合パディングを適用するには、 ViewCompat.setOnApplyWindowInsetsListener。対象 RecyclerView: このリスナーを使用してパディングを適用し、さらに clipToPadding="false"。

カスタムの背景保護を提供する必要があるかどうかの確認方法

アプリで 3 ボタンナビゲーションにカスタム背景保護を提供する必要がある場合、またはシステムバーの背後にコンポーザブルまたはビューを配置する必要があります。 WindowInsets.Type#tappableElement() を使用して 3 ボタンを取得するナビゲーションバーの高さまたは WindowInsets.Type#statusBars。

その他のエッジツーエッジのリソース

エッジからエッジへのビューとエッジからエッジへの Compose をご覧ください。ガイドを参照してください。

サポート終了 API

次の API は非推奨になりました。

安定した構成

Android 15（API レベル 35）以降をターゲットとするアプリの場合、Configurationいいえシステムバーが除外されますAndroid 10 の Configuration クラスをレイアウト計算に使用する場合は、適切な ViewGroup、WindowInsets、または必要に応じて WindowMetricsCalculator。

Configuration は API 1 以降で使用できます。通常は Activity.onConfigurationChanged。ウィンドウ密度、画面の向き、サイズです。ウィンドウサイズに関する重要な特性の 1 つは 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 以降ですでにこのように動作しています。

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 による幅の決定方法に影響するため、アプリが Android 15 以降をターゲットとする場合、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 要素のサイズは均一に設定されました。

`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 デベロッパーとのコラボレーションをベースとしており、内部テストです。Google は、非 SDK インターフェースを制限する前に、可能な限り、その代わりとなる公開インターフェースを利用可能にしています。

Android 15 をターゲットとしないアプリの場合、一部の変更すぐには影響しない可能性があります。ただし、アプリで一部の非 SDK インターフェースにアクセスするアプリの対象 API レベルに応じて異なるメソッドまたはフィールドを使用すると、アプリが機能しなくなるリスクが高くなります。

アプリが非 SDK インターフェースを使用しているかどうか不明な場合は、アプリをテストして確認します。アプリが非 SDK に依存している場合インターフェースがある場合は、他の SDK への移行計画を開始する必要があります。とはいえ、アプリによっては、非 SDK インターフェースで使用できます。非 SDK の代替手段が見つからない場合インターフェースを機能させるには、新しい公開 API をリクエストします。

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