これまでのリリースと同様、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]"
この動作の変更による問題を回避するには、次のいずれかを行います。
- サービスに新しい
Service.onTimeout(int, int)
メソッドを実装します。アプリがコールバックを受信したら、数秒以内にstopSelf()
を呼び出します。(アプリをすぐに停止しないと、システムは障害を生成します)。 - アプリの
dataSync
サービスが、24 時間で合計 6 時間を超えて実行されていないことを確認します(ユーザーがアプリを操作してタイマーをリセットする場合を除きます)。 dataSync
フォアグラウンド サービスは、直接のユーザー操作の結果としてのみ起動します。サービスの開始時にアプリはフォアグラウンドにあるため、サービスはバックグラウンドに移行してから 6 時間すべてかかります。dataSync
フォアグラウンド サービスを使用する代わりに、代替の API を使用してください。
アプリの dataSync
フォアグラウンド サービスが過去 24 時間以内に 6 時間実行されている場合、ユーザーがアプリをフォアグラウンドに表示した(これによりタイマーがリセットされる)場合を除き、別の dataSync
フォアグラウンド サービスを開始することはできません。別の dataSync
フォアグラウンド サービスを開始しようとすると、システムは ForegroundServiceStartNotAllowedException
をスローし、「フォアグラウンド サービス タイプ 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:
- Have your service implement the new
Service.onTimeout(int, int)
method. When your app receives the callback, make sure to callstopSelf()
within a few seconds. (If you don't stop the app right away, the system generates a failure.) - 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). - 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. - 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
レシーバーは、API 呼び出しを起動できない
フォアグラウンド サービスのタイプを使用できます。
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 では、最新の OpenJDK LTS リリースの機能に合わせて Android のコアライブラリを更新する取り組みが引き続き行われています。
これらの変更の一部は、Android 15(API レベル 35)をターゲットとするアプリの互換性に影響する可能性があります。
String Formatting API を変更: 次の
String.format()
API と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()
メソッドから生成されたシーケンスがRandom.nextInt()
と一致することを想定しないでください。
新しい SequencedCollection
API は、アプリのビルド構成で compileSdk
を更新して Android 15(API レベル 35)を使用すると、アプリの互換性に影響する可能性があります。
kotlin-stdlib
のMutableList.removeFirst()
拡張関数とMutableList.removeLast()
拡張関数との競合Java の
List
型は、Kotlin のMutableList
型にマッピングされます。List.removeFirst()
API とList.removeLast()
API は Android 15(API レベル 35)で導入されたため、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.getFirst(); }
セキュリティ
Android 15 には、悪意のあるアプリからアプリとユーザーを保護するために、システムのセキュリティを強化する変更が含まれています。
制限付き TLS バージョン
Android 15 では、TLS バージョン 1.0 および 1.1 の使用が制限されています。これまではこれらのバージョンは Android で非推奨でしたが、現在は Android 15 をターゲットとするアプリで許可されないようになりました。
バックグラウンド アクティビティの安全な起動
Android 15 では、悪意のあるアプリからユーザーを保護し、より細かく 悪意のあるバックグラウンド アプリが悪意のあるアクティビティを 他のアプリをフォアグラウンド表示させる、権限昇格させる、アプリを悪用する です。バックグラウンド アクティビティの起動は、それ以降、 Android 10(API レベル 29)。
その他の変更点
UID の一致に関する制限に加えて、次の変更も加えられています。
PendingIntent
クリエイターを変更し、デフォルトでバックグラウンド アクティビティの起動をブロックするようにしました。これにより、アプリが誤って IP アドレスをPendingIntent
: 悪意のある人物によって悪用されるおそれがあります。PendingIntent
送信者が許可しない限り、アプリをフォアグラウンドに表示しないでください。この変更は、悪意のあるアプリがバックグラウンドでアクティビティを開始する機能を悪用することを防ぐことを目的としています。デフォルトでは、作成者がバックグラウンド アクティビティの起動権限を許可している場合、または送信者にバックグラウンド アクティビティの起動権限がある場合を除き、アプリはタスクスタックをフォアグラウンドに表示できません。- タスクスタックの最上位アクティビティがタスクを終了する方法を制御する。最上位のアクティビティがタスクを完了すると、Android は最後にアクティブだったタスクに戻ります。また、トップ以外のアクティビティがタスクを終了すると、Android はホーム画面に戻ります。このトップ以外のアクティビティの終了はブロックされません。
- 他のアプリから任意のアクティビティを独自のタスクに起動できないようにする。この変更により、悪意のあるアプリがユーザーをフィッシング攻撃から 他のアプリからと思われるアクティビティ
- 非表示のウィンドウがバックグラウンド アクティビティの起動の対象と見なされないようにする。これにより、悪意のあるアプリがバックグラウンド アクティビティの起動を悪用して、望ましくないコンテンツや悪意のあるコンテンツをユーザーに表示するのを防ぐことができます。
より安全なインテント
Android 15 では、インテントをより安全で堅牢にするための新しいオプションのセキュリティ対策が導入されています。これらの変更は、悪意のあるアプリによって悪用される可能性のある脆弱性とインテントの不正使用を防ぐことを目的としています。2 つのモデル Android 15 では、インテントのセキュリティに関して次のように改善されています。
- ターゲット インテント フィルタと一致する: 特定のコンポーネントをターゲットとするインテントは、ターゲットのインテント フィルタ仕様に正確に一致する必要があります。。 別のアプリのアクティビティを起動するインテントがある場合は、ターゲット インテント コンポーネントが 受信側アクティビティの宣言されたインテント フィルタと一致している。
- インテントにアクションを含める: アクションのないインテントは一致しなくなります。 すべてのインテント フィルタが含まれます。つまり、アクティビティやイベントの開始に 明確に定義されたアクションが必要です
アプリがこれらの変更にどのように対応するかを確認するには、アプリで StrictMode
を使用します。Intent
の使用違反に関する詳細なログを表示するには、次のメソッドを追加します。
Kotlin
fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() .detectUnsafeIntentLaunch() .build() ) }
Java
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.
Edge-to-edge enforcement
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
andR.attr#navigationBarColor
are deprecated and don't affect gesture navigation.setNavigationBarContrastEnforced
andR.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
andR.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
andR.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
andR.attr#statusBarColor
are deprecated and have no effect on Android 15.setStatusBarContrastEnforced
andR.attr#statusBarContrastEnforced
are deprecated but still have an effect on Android 15.
- Display cutout
layoutInDisplayCutoutMode
of non-floating windows must beLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
.SHORT_EDGES
,NEVER
, andDEFAULT
are interpreted asALWAYS
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 usesSHORT_EDGES
,NEVER
orDEFAULT
instead ofLAYOUT_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 setwindow.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 asTopAppBar
,BottomAppBar
, andNavigationBar
, 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 thewindowInsets
parameter to apply the insets manually forBottomAppBar
,TopAppBar
,BottomNavigation
, andNavigationRail
. Likewise, use thecontentWindowInsets
parameter forScaffold
. - If your app uses views and Material Components
(
com.google.android.material
), most views-based Material Components such asBottomNavigationView
,BottomAppBar
,NavigationRailView
, orNavigationView
, handle insets and require no additional work. However, you need to addandroid:fitsSystemWindows="true"
if usingAppBarLayout
. - For custom composables, apply the insets manually as padding. If your
content is within a
Scaffold
, you can consume insets using theScaffold
padding values. Otherwise, apply padding using one of theWindowInsets
. - If your app is using views and
BottomSheet
,SideSheet
or custom containers, apply padding usingViewCompat.setOnApplyWindowInsetsListener
. ForRecyclerView
, apply padding using this listener and also addclipToPadding="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
Stable configuration
アプリが Android 15(API レベル 35)以上をターゲットにしている場合、Configuration
はシステムバーを除外しません。レイアウトの計算に Configuration
クラスの画面サイズを使用している場合は、必要に応じて適切な ViewGroup
、WindowInsets
、WindowMetricsCalculator
などのより良い代替手段に置き換える必要があります。
Configuration
は API 1 以降で利用可能です。通常は Activity.onConfigurationChanged
から取得します。ウィンドウの密度、向き、サイズなどの情報が提供されます。Configuration
から返されるウィンドウ サイズの重要な特徴の 1 つは、以前はシステムバーが除外されていたことです。
構成サイズは通常、/res/layout-h500dp
などのリソース選択に使用されますが、これは依然として有効なユースケースです。ただし、レイアウトの計算に使用することは常に推奨されていません。その場合は、今すぐ離れてください。ユースケースに応じて、Configuration
の使用をより適切なものに置き換える必要があります。
レイアウトの計算に使用する場合は、CoordinatorLayout
や ConstraintLayout
などの適切な ViewGroup
を使用します。システム ナビバーの高さを決定するために使用する場合は、WindowInsets
を使用します。アプリ ウィンドウの現在のサイズを知りたい場合は、computeCurrentWindowMetrics
を使用します。
この変更の影響を受けるフィールドは次のとおりです。
Configuration.screenWidthDp
サイズとscreenHeightDp
サイズでシステムバーが除外されなくなりました。Configuration.smallestScreenWidthDp
は、screenWidthDp
とscreenHeightDp
の変更の影響を間接的に受けます。Configuration.orientation
は、ほぼ正方形のデバイスでscreenWidthDp
とscreenHeightDp
の変更の影響を間接的に受けます。Display.getSize(Point)
は、Configuration
の変更の影響を間接的に受けます。これは API レベル 30 以降で非推奨になりました。Display.getMetrics()
は、API レベル 33 以降、すでにこの動作をしています。
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
.

elegantTextHeight
behavior for apps targeting Android 14 (API level 34) and lower.
elegantTextHeight
behavior for apps targeting Android 15.複雑な文字の形状に合わせて TextView の幅が変更される
Android の以前のバージョンでは、複雑なシェーピングを持つ一部の筆記体フォントや言語では、文字が前の文字または次の文字の領域に描画されることがあります。場合によっては、このような文字の開始位置や終了位置が切り詰められていました。Android 15 以降では、TextView
はこのような文字に十分なスペースを描画するための幅を割り当て、アプリがクリッピングを防ぐために左側に追加の余白をリクエストできるようにします。
この変更は TextView
が幅を決定する方法に影響するため、アプリが Android 15(API レベル 35)以降をターゲットとしている場合、TextView
はデフォルトでより多くの幅を割り当てます。この動作を有効または無効にするには、TextView
で setUseBoundsForWidth
API を呼び出します。
左側の余白を追加すると、既存のレイアウトの位置がずれる可能性があるため、Android 15 以降をターゲットとするアプリでも、デフォルトでは余白は追加されません。ただし、setShiftDrawingOffsetForStartOverhang
を呼び出すことで、クリッピングを防ぐためにパディングを追加できます。
次の例は、これらの変更によって、一部のフォントと言語のテキスト レイアウトがどのように改善されるかを示しています。

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

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

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

<TextView android:text="คอมพิวเตอร์" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
EditText のロケール対応のデフォルトの行の高さ
以前のバージョンの Android では、テキスト レイアウトは、現在の言語 / 地域に一致するフォントの行の高さに合うようにテキストの高さを伸ばしていました。たとえば、コンテンツが日本語の場合、日本語フォントの行間がラテン文字フォントよりも少し大きいため、テキストの高さが少し大きくなっていました。ただし、次の画像に示すように、このような行の高さの違いにもかかわらず、EditText
要素は、使用されている言語 / 地域に関係なく、均一にサイズ設定されていました。

EditText
要素を表す 3 つのボックス。これらの言語の行の高さは異なりますが、EditText
の高さは同じです。Android 15(API レベル 35)をターゲットとするアプリの場合、指定されたロケールの参照フォントに合わせて、EditText
の最小行の高さが予約されるようになりました。これは次の図に示すとおりです。

EditText
要素を表す 3 つのボックス。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 の今回のリリースの変更について詳しくは、非 SDK インターフェースの制限に関する Android 15 での変更点をご覧ください。非 SDK インターフェース全般について詳しくは、非 SDK インターフェースの制限をご覧ください。