これまでのリリースと同様、Android 15 には、アプリに影響する可能性がある動作変更が含まれています。下記の動作変更は、Android 15 以上をターゲットとするアプリにのみ適用されます。アプリが Android 15 以上をターゲットとする場合は、必要に応じてアプリを変更し、下記の動作に適切に対応できるようにしてください。
アプリの targetSdkVersion
に関係なく、Android 15 で実行されるすべてのアプリに影響する動作変更のリストも必ずご確認ください。
コア機能
Android 15 では、Android システムのさまざまなコア機能が変更または拡張されています。
フォアグラウンド サービスの変更
We are making the following changes to foreground services with Android 15.
- Data sync foreground service timeout behavior
- New media processing foreground service type
- Restrictions on
BOOT_COMPLETED
broadcast receivers launching foreground services - Restrictions on starting foreground services while an app holds the
SYSTEM_ALERT_WINDOW
permission
Data sync foreground service timeout behavior
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
New media processing foreground service type
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
Restrictions on BOOT_COMPLETED
broadcast receivers launching foreground services
There are new restrictions on BOOT_COMPLETED
broadcast receivers launching
foreground services. BOOT_COMPLETED
receivers are not allowed to launch the
following types of foreground services:
dataSync
camera
mediaPlayback
phoneCall
mediaProjection
microphone
(this restriction has been in place formicrophone
since Android 14)
If a BOOT_COMPLETED
receiver tries to launch any of those types of foreground
services, the system throws ForegroundServiceStartNotAllowedException
.
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). Run the following adb
command:
adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name
To send a BOOT_COMPLETED
broadcast without restarting the device,
run the following adb
command:
adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name
Restrictions on starting foreground services while an app holds the SYSTEM_ALERT_WINDOW
permission
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
アプリがサイレント モードのグローバル状態を変更できるタイミングの変更
以 Android 15(API 级别 35)及更高版本为目标平台的应用无法再更改设备上的勿扰 (DND) 功能的全局状态或政策(无论是通过修改用户设置还是关闭勿扰模式)。相反,应用必须提供 AutomaticZenRule
,系统会将其与现有的“最严格的政策优先”方案合并为一个全局政策。对之前会影响全局状态的现有 API 的调用(setInterruptionFilter
、setNotificationPolicy
)会导致创建或更新隐式 AutomaticZenRule
,该 AutomaticZenRule
会根据这些 API 调用的调用周期开启和关闭。
请注意,只有当应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL)
并希望该调用停用之前由其所有者激活的 AutomaticZenRule
时,此更改才会影响可观察到的行为。
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
创建者更改为屏蔽后台活动启动。这有助于防止应用意外创建可能会被恶意操作者滥用的PendingIntent
。 - 除非
PendingIntent
发件人允许,否则请勿将应用调至前台。此变更旨在防止恶意应用滥用 在后台启动 activity 的功能。默认情况下,应用 允许将任务堆栈转到前台,除非创建者允许 后台活动启动权限或发送者有后台活动 启动权限 - 控制任务堆栈顶部 activity 如何完成其任务。如果顶部 activity 完成任务,Android 将返回上次处于活动状态的任务。此外,如果非顶层 activity 完成其任务,Android 将 返回主屏幕;它不会挡住这个非顶层的 活动。
- 防止将其他应用中的任意 activity 启动到您自己的 activity 任务。这项变更可防止恶意应用通过创建看似来自其他应用的 activity 来钓鱼式攻击用户。
- 阻止系统考虑非可见窗口来启动后台 activity。这有助于防止恶意应用滥用后台 activity 启动来向用户显示不需要或恶意的内容。
より安全なインテント
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
如果应用以 Android 15(API 级别 35)为目标平台,则在搭载 Android 15 的设备上默认以无边框显示。

这是一项重大变更,可能会对应用的界面产生负面影响。这些更改会影响以下界面区域:
- 手势柄导航栏
- 默认透明。
- 底部偏移量处于停用状态,因此内容会绘制在系统导航栏后面,除非应用了边衬区。
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
。 - 可能存在流量较低且界面被遮挡的屏幕。验证这些访问频率较低的界面是否没有被遮挡的界面。低流量界面包括:
- 初始配置或登录界面
- “设置”页面
如果您的应用尚未实现全屏显示,需要检查哪些方面
如果您的应用尚未实现全屏显示,则很可能会受到影响。除了已经实现全屏显示的 app 的场景之外,您还应考虑以下事项:
- 如果您的应用在 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
参数。 - 如果您的应用使用视图和 Material 组件 (
com.google.android.material
),则大多数基于视图的 Material 组件(例如BottomNavigationView
、BottomAppBar
、NavigationRailView
或NavigationView
)都会处理边衬区,因此不需要执行额外的操作。不过,如果使用的是AppBarLayout
,则需要添加android:fitsSystemWindows="true"
。 - 对于自定义可组合项,请手动应用边衬区作为内边距。如果您的内容位于
Scaffold
内,则可以使用Scaffold
内边距值来使用插边。否则,请使用WindowInsets
之一应用内边距。 - 如果应用使用的是视图和
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
Stable configuration
如果您的应用以 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
に設定してアプリをテストします。

elegantTextHeight
の動作
elegantTextHeight
の動作。複雑な文字の形状に合わせて 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 のロケール対応のデフォルトの行の高さ
In previous versions of Android, the text layout stretched the height of the
text to meet the line height of the font that matched the current locale. For
example, if the content was in Japanese, because the line height of the Japanese
font is slightly larger than the one of a Latin font, the height of the text
became slightly larger. However, despite these differences in line heights, the
EditText
element was sized uniformly, regardless
of the locale being used, as illustrated in the following image:

EditText
elements that
can contain text from English (en), Japanese (ja), and Burmese (my). The
height of the EditText
is the same, even though these languages
have different line heights from each other.For apps targeting Android 15 (API level 35), a minimum line height is now
reserved for EditText
to match the reference font for the specified Locale, as
shown in the following image:

EditText
elements that
can contain text from English (en), Japanese (ja), and Burmese (my). The
height of the EditText
now includes space to accommodate the
default line height for these languages' fonts.If needed, your app can restore the previous behavior by specifying the
useLocalePreferredLineHeightForMinimum
attribute
to false
, and your app can set custom minimum vertical metrics using the
setMinimumFontMetrics
API in Kotlin and Java.
カメラとメディア
Android 15 では、Android 15 以上をターゲットとするアプリのカメラとメディアの動作が次のように変更されています。
音声フォーカス リクエストの制限
Android 15(API レベル 35)をターゲットとするアプリが音声フォーカスをリクエストするには、最上位のアプリであるか、フォアグラウンド サービスを実行している必要があります。アプリがこれらの要件のいずれかを満たしていないときにフォーカスをリクエストしようとすると、呼び出しは AUDIOFOCUS_REQUEST_FAILED
を返します。
音声フォーカスの詳細については、音声フォーカスを管理するをご覧ください。
非 SDK の制限の更新
Android 15 では、Android デベロッパーの協力と直近の内部テストに基づいて、制限を受ける非 SDK インターフェースのリストが更新されています。Google は、非 SDK インターフェースを制限する前に、可能な限り、その代わりとなる公開インターフェースを利用可能にしています。
Android 15 をターゲットとしないアプリでは、この変更の一部はすぐには影響しない可能性があります。ただし、アプリのターゲット API レベルに応じて、アプリが一部の非 SDK インターフェースにアクセスできる場合もありますが、非 SDK のメソッドまたはフィールドを使用すると、アプリが機能しなくなるリスクが高くなります。
アプリが非 SDK インターフェースを使用しているかどうか不明な場合は、アプリをテストして確認できます。アプリが非 SDK インターフェースに依存している場合は、SDK の代替インターフェースへの移行を計画してください。ただし Google も、一部のアプリには非 SDK インターフェースを使用する正当なユースケースがあると承知しています。アプリの機能に使用している非 SDK インターフェースの代わりが見つからない場合は、新しい公開 API をリクエストしてください。
To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 15. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.