これまでのリリースと同様、Android 15 には、アプリに影響する可能性がある動作変更が含まれています。下記の動作変更は、Android 15 以上をターゲットとするアプリにのみ適用されます。アプリが Android 15 以上をターゲットとする場合は、必要に応じてアプリを変更し、下記の動作に適切に対応できるようにしてください。
アプリの targetSdkVersion に関係なく、Android 15 で実行されるすべてのアプリに影響する動作変更のリストも必ずご確認ください。
コア機能
Android 15 では、Android システムのさまざまなコア機能が変更または拡張されています。
フォアグラウンド サービスに関する変更
我们将对 Android 15 中的前台服务进行以下更改。
数据同步前台服务超时行为
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 引入了一种新的前台服务类型 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 小时时间。 - 请改用 替代 API(例如 WorkManager),而不是使用
mediaProcessing前台服务。
如果您的应用的 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 呼び出しを起動できない
フォアグラウンド サービスのタイプを使用できます。
dataSynccameramediaPlaybackphoneCallmediaProjectionmicrophone(この制限は、次の日付より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(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]);语言代码处理方式变更:使用
LocaleAPI 时,希伯来语、意第绪语和印度尼西亚语的语言代码不再转换为其过时形式(希伯来语: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())静态解析为新的ListAPI,而不是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 插件中的现有
NewApilint 选项可以捕获这些新的 API 用法。./gradlew lintMainActivity.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.javaMyList.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.javaMyList.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.javaMyList.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)以降、バックグラウンド アクティビティの起動が制限されています。
その他の変更点
PendingIntentクリエイターのデフォルトをバックグラウンド アクティビティの起動をブロックに変更。これにより、アプリが誤ってPendingIntentを作成し、悪意のある行為者によって不正使用されるのを防ぐことができます。PendingIntent送信者が許可しない限り、アプリをフォアグラウンドに移動しないでください。この変更は、悪意のあるアプリがバックグラウンドでアクティビティを開始する機能を悪用することを防ぐことを目的としています。デフォルトでは、作成者がバックグラウンド アクティビティの起動権限を許可するか、送信者がバックグラウンド アクティビティの起動権限を持っている場合を除き、アプリがタスクスタックをフォアグラウンドに移動することは許可されません。- タスクスタックの最上位のアクティビティがタスクを完了する方法を制御します。最上位のアクティビティがタスクを終了すると、Android は最後にアクティブだったタスクに戻ります。また、最上位でないアクティビティがタスクを終了した場合、Android はホーム画面に戻ります。この最上位でないアクティビティの終了はブロックされません。
- 他のアプリから任意の Activity が自分のタスクに起動されるのを防ぎます。この変更により、悪意のあるアプリが他のアプリからのものに見せかけたアクティビティを作成してユーザーをフィッシングするのを防ぐことができます。
- 非表示のウィンドウがバックグラウンド アクティビティの起動の対象にならないようにブロック。これにより、悪意のあるアプリがバックグラウンド アクティビティの起動を不正使用して、ユーザーに不要なコンテンツや悪意のあるコンテンツを表示するのを防ぐことができます。
より安全なインテント
Android 15 针对 intent 引入了 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 には、より一貫性のある直感的なユーザー エクスペリエンスを実現するための変更がいくつか含まれています。
ウィンドウ インセットの変更
Android 15 では、ウィンドウの切り欠きに関連する 2 つの変更があります。エッジツーエッジがデフォルトで適用され、システムバーのデフォルト構成などの構成も変更されています。
エッジ ツー エッジの適用
Android 15(API レベル 35)をターゲットとしているアプリについては、Android 15 を搭載しているデバイスではデフォルトでエッジツーエッジ表示となります。
これは、アプリの UI に悪影響を及ぼす可能性がある互換性を破る変更です。この変更は、次の UI 領域に影響します。
- ジェスチャー ハンドル ナビゲーション バー
- デフォルトで透明。
- 下部のオフセットが無効になっているため、インセットが適用されない限り、コンテンツはシステム ナビゲーション バーの背後に描画されます。
setNavigationBarColorとR.attr#navigationBarColorは非推奨であり、ジェスチャー ナビゲーションには影響しません。setNavigationBarContrastEnforcedとR.attr#navigationBarContrastEnforcedは、引き続きジェスチャー ナビゲーションに影響しません。
- 3 ボタン ナビゲーション
- 不透明度はデフォルトで 80% に設定され、色はウィンドウの背景と一致する可能性があります。
- 下部のオフセットが無効になっているため、インセットが適用されない限り、コンテンツはシステム ナビゲーション バーの背後に描画されます。
setNavigationBarColorとR.attr#navigationBarColorは、デフォルトでウィンドウの背景と一致するように設定されています。このデフォルトを適用するには、ウィンドウ背景が色ドローアブルである必要があります。この API は非推奨ですが、3 ボタン ナビゲーションには引き続き影響します。setNavigationBarContrastEnforcedとR.attr#navigationBarContrastEnforcedはデフォルトで true に設定されており、3 ボタン ナビゲーション全体に 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 では異なる場合があります。
アプリがすでにエッジ ツー エッジになっている場合に確認すること
アプリがすでにエッジ ツー エッジで、インセットを適用している場合、次のシナリオを除き、ほとんど影響はありません。ただし、影響を受けないと思われる場合でも、アプリをテストすることをおすすめします。
LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYSではなくSHORT_EDGES、NEVER、DEFAULTを使用するActivityなどの非フローティング ウィンドウがある。アプリが起動時にクラッシュする場合は、スプラッシュ画面が原因である可能性があります。core splashscreen の依存関係を 1.2.0-alpha01 以降にアップグレードするか、window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.alwaysを設定します。- トラフィックの少ない画面で UI が隠れている可能性があります。これらのあまりアクセスされない画面に、隠れている UI がないことを確認します。トラフィックの少ない画面には、次のようなものがあります。
- オンボーディング画面またはログイン画面
- 設定ページ
アプリがまだエッジ ツー エッジでない場合に確認すべきこと
アプリがまだエッジ ツー エッジに対応していない場合は、影響を受ける可能性が高くなります。すでにエッジ ツー エッジになっているアプリのシナリオに加えて、次の点を考慮する必要があります。
- アプリが Compose でマテリアル デザイン 3 のコンポーネント(
androidx.compose.material3)(TopAppBar、BottomAppBar、NavigationBarなど)を使用している場合、これらのコンポーネントはインセットを自動的に処理するため、影響を受けない可能性が高いです。 - アプリが Compose でマテリアル デザイン 2 のコンポーネント(
androidx.compose.material)を使用している場合、コンポーネントはインセットを自動的には処理しません。ただし、インセットにアクセスして手動で適用することはできます。androidx.compose.material 1.6.0 以降では、windowInsetsパラメータを使用して、BottomAppBar、TopAppBar、BottomNavigation、NavigationRailにインセットを手動で適用します。同様に、ScaffoldにはcontentWindowInsetsパラメータを使用します。 - アプリでビューとマテリアル コンポーネント(
com.google.android.material)を使用する場合、ビューベースのマテリアル コンポーネントの多く(BottomNavigationView、BottomAppBar、NavigationRailView、NavigationViewなど)はインセットを処理します。追加の作業は不要です。ただし、AppBarLayoutを使用する場合はandroid:fitsSystemWindows="true"を追加する必要があります。 - カスタム コンポーザブルの場合は、インセットをパディングとして手動で設定します。コンテンツが
Scaffold内にある場合は、Scaffoldパディング値を使用してインセットを消費できます。それ以外の場合は、WindowInsetsのいずれかを使用してパディングを適用します。 - アプリがビューと
BottomSheet、SideSheet、またはカスタム コンテナを使用する場合、ViewCompat.setOnApplyWindowInsetsListenerを使用してパディングを適用します。RecyclerViewについては、このリスナーを使用してパディングを適用して、さらにclipToPadding="false"を追加します。
アプリでカスタム バックグラウンド保護を提供する必要がある場合に確認すべきこと
アプリが 3 ボタン ナビゲーションまたはステータスバーにカスタムの背景保護を提供する必要がある場合は、WindowInsets.Type#tappableElement() を使用して 3 ボタン ナビゲーション バーの高さを取得するか、WindowInsets.Type#statusBars を使用して、システムバーの背後にコンポーザブルまたはビューを配置する必要があります。
エッジ ツー エッジに関するその他のリソース
インセットの適用に関するその他の考慮事項については、エッジ ツー エッジのビューとエッジ ツー エッジの Compose のガイドをご覧ください。
非推奨 API
次の API は非推奨ですが、無効にはなっていません。
R.attr#enforceStatusBarContrastR.attr#navigationBarColor(3 ボタン ナビゲーション用、アルファ値 80%)Window#isStatusBarContrastEnforcedWindow#setNavigationBarColor(3 ボタン ナビゲーション用、アルファ値 80%)Window#setStatusBarContrastEnforced
次の API は非推奨となり、無効になっています。
R.attr#navigationBarColor(ジェスチャー ナビゲーション用)R.attr#navigationBarDividerColorR.attr#statusBarColorWindow#setDecorFitsSystemWindowsWindow#getNavigationBarColorWindow#getNavigationBarDividerColorWindow#getStatusBarColorWindow#setNavigationBarColor(ジェスチャー ナビゲーション用)Window#setNavigationBarDividerColorWindow#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の変更によって間接的に影響を受けます。Configurationの変更はDisplay.getSize(Point)に間接的に影響します。このメソッドは 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 に設定してアプリをテストします。
Android 14(API レベル 34)以前をターゲットとするアプリの 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 要素を表す 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 では、Android デベロッパーの協力と直近の内部テストに基づいて、制限を受ける非 SDK インターフェースのリストが更新されています。Google は、非 SDK インターフェースを制限する前に、可能な限り、その代わりとなる公開インターフェースを利用可能にしています。
Android 15 をターゲットとしないアプリでは、この変更の一部はすぐには影響しない可能性があります。ただし、アプリの対象 API レベルに応じて、アプリが一部の非 SDK インターフェースにアクセスできる場合でも、非 SDK のメソッドまたはフィールドをそのまま使用し続けると、将来的にアプリが機能しなくなるリスクが高くなります。
アプリが非 SDK インターフェースを使用しているかどうか不明な場合は、アプリをテストして確認できます。アプリが非 SDK インターフェースに依存している場合は、SDK の代替手段への移行を計画してください。それでも、アプリによっては非 SDK インターフェースを使用する正当なユースケースがあることを承知しています。アプリの機能に使用している非 SDK インターフェースの代わりが見つからない場合は、新しい公開 API をリクエストしてください。
如需详细了解此 Android 版本中的变更,请参阅 Android 15 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息,请参阅对非 SDK 接口的限制。