これまでのリリースと同様、Android 15 には、アプリに影響する可能性がある動作変更が含まれています。下記の動作変更は、Android 15 以上をターゲットとするアプリにのみ適用されます。アプリが Android 15 以上をターゲットとする場合は、必要に応じてアプリを変更し、下記の動作に適切に対応できるようにしてください。
アプリの targetSdkVersion
に関係なく、Android 15 で実行されるすべてのアプリに影響する動作変更のリストも必ずご確認ください。
コア機能
Android 15 では、Android システムのさまざまなコア機能を変更または拡張しています。
フォアグラウンド サービスの変更
我们将对 Android 15 中的前台服务进行以下更改。
数据同步前台服务超时行为
对于以 Android 15(API 级别 35)或更高版本为目标平台的应用,Android 15 为 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 小时时间。 - 请使用替代 API,而不是使用
dataSync
前台服务。
如果您的应用的 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 では、新しいフォアグラウンド サービス タイプ 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
レシーバーは、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
权限时启动前台服务的限制
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)モードのグローバル状態やポリシーを変更できなくなりました(ユーザー設定の変更や 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 时,对参数索引、标志、宽度和精度的验证更为严格: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
)。对随机 int 序列的更改:在 https://bugs.openjdk.org/browse/JDK-8301574 中进行更改后,以下
Random.ints()
方法现在返回的数字序列与Random.nextInt()
方法返回的序列不同:通常,此更改不会导致应用出现破坏行为,但您的代码不应预期从
Random.ints()
方法生成的序列与Random.nextInt()
匹配。
在您更新应用 build 配置中的 compileSdk
以使用 Android 15(API 级别 35)后,新的 SequencedCollection
API 可能会影响应用的兼容性:
与
kotlin-stdlib
中的MutableList.removeFirst()
和MutableList.removeLast()
扩展函数发生冲突Java 中的
List
类型会映射到 Kotlin 中的MutableList
类型。由于List.removeFirst()
和List.removeLast()
API 已在 Android 15(API 级别 35)中引入,因此 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 では、TLS バージョン 1.0 および 1.1 の使用が制限されています。これまではこれらのバージョンは Android で非推奨でしたが、現在は 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 では、インテントをより安全かつ堅牢にするために、新しいオプションのセキュリティ対策が導入されています。この変更は、悪意のあるアプリによって悪用されるおそれのある潜在的な脆弱性やインテントの不正使用を防止することを目的としています。Android 15 では、インテントのセキュリティに関して、主に 2 つの改善点があります。
- ターゲットのインテント フィルタに一致させる: 特定のコンポーネントをターゲットとするインテントは、ターゲットのインテント フィルタの仕様に正確に一致する必要があります。別のアプリのアクティビティを起動するためのインテントを送信する場合、ターゲット インテント コンポーネントは、受信側のアクティビティで宣言されたインテント フィルタと一致している必要があります。
- インテントにはアクションが必要です。アクションのないインテントは、インテント フィルタと一致しなくなります。つまり、アクティビティやサービスを起動するために使用するインテントには、明確に定義されたアクションが必要です。
アプリがこれらの変更にどのように対応するかを確認するには、アプリで 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.
全面实施政策
如果应用以 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)为目标平台之前和之后,以及应用内边距之前和之后的效果。



如何检查应用是否已采用边到边设计
如果您的应用已经是边到边且应用了内边距,则除以下情况外,您大多不会受到影响。不过,即使您认为自己没有受到影响,我们也建议您测试应用。
- 您有一个非浮动窗口,例如使用
SHORT_EDGES
、NEVER
或DEFAULT
(而非LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
)的Activity
。如果您的应用在启动时崩溃,这可能是因为您的启动画面存在问题。您可以将核心启动画面依赖项升级到 1.2.0-alpha01 或更高版本,也可以设置window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
。 - 有些流量较低的屏幕可能存在遮挡界面的情况。验证这些访问次数较少的屏幕是否存在遮挡的界面。流量较低的屏幕包括:
- 初始配置或登录屏幕
- “设置”页面
如果您的应用尚未采用边到边设计,应检查哪些方面
如果您的应用尚未采用边到边设计,您很可能受到影响。除了已经采用边到边设计的应用的场景之外,您还应考虑以下情况:
- 如果您的应用在 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
参数。 - 如果应用使用了 View 和 Material 组件 (
com.google.android.material
),则大多数基于 View 的 Material 组件(例如BottomNavigationView
、BottomAppBar
、NavigationRailView
或NavigationView
)都会处理边衬区,因此不需要执行额外的操作。不过,如果使用的是AppBarLayout
,则需要添加android:fitsSystemWindows="true"
。 - 对于自定义可组合项,请手动将边衬区应用为内边距。如果您的内容位于
Scaffold
中,您可以使用Scaffold
内边距值使用内边距。否则,请使用WindowInsets
之一应用内边距。 - 如果应用使用的是 View 和
BottomSheet
、SideSheet
或自定义容器,请使用ViewCompat.setOnApplyWindowInsetsListener
应用内边距。对于RecyclerView
,请使用此监听器应用内边距,同时添加clipToPadding="false"
。
如果您的应用必须提供自定义后台保护,应检查哪些方面
如果您的应用必须为三按钮导航栏或状态栏提供自定义背景保护,则应使用 WindowInsets.Type#tappableElement()
在系统栏后面放置可组合项或视图,以获取三按钮导航栏高度或 WindowInsets.Type#statusBars
。
其他端到端资源
如需了解有关应用内边距的其他注意事项,请参阅边到边视图和边到边 Compose 指南。
已弃用的 API
以下 API 已废弃,但并未停用:
R.attr#enforceStatusBarContrast
R.attr#navigationBarColor
(适用于三按钮导航,透明度为 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
から返されるウィンドウサイズの重要な特徴の 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 です
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 のデフォルトの行の高さを言語 / 地域に応じて設定
在较低版本的 Android 中,文本布局会拉伸文本的高度,以满足与当前语言区域匹配的字体的行高。例如,如果内容是日语,由于日语字体的行高略高于拉丁字体,因此文本的高度会略高。不过,尽管行高存在这些差异,但无论使用的是哪种语言区域,EditText
元素的大小都是统一的,如下图所示:

EditText
元素。EditText
的高度相同,即使这些语言的行高各不相同。对于以 Android 15(API 级别 35)为目标平台的应用,现在为 EditText
预留了最小行高,以匹配指定语言区域的参考字体,如下图所示:

EditText
元素。EditText
的高度现在包含足够的空间来容纳这些语言字体的默认行高。如有需要,您的应用可以将 useLocalePreferredLineHeightForMinimum
属性指定为 false
,以恢复之前的行为;您的应用还可以在 Kotlin 和 Java 中使用 setMinimumFontMetrics
API 设置自定义最小垂直指标。
カメラとメディア
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 をリクエストしてください。
如需详细了解此 Android 版本中的变更,请参阅 Android 15 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息,请参阅对非 SDK 接口的限制。