これまでのリリースと同様、Android 14 には、アプリに影響する可能性がある動作変更が含まれています。下記の動作変更は、Android 14（API レベル 34）以上をターゲットとするアプリにのみ適用されます。アプリが Android 14 以上をターゲットとする場合は、必要に応じてアプリを変更し、下記の動作に適切に対応できるようにしてください。
アプリの targetSdkVersion に関係なく、Android 14 で実行されるすべてのアプリに影響する動作変更のリストも必ずご確認ください。
コア機能
フォアグラウンド サービス タイプは必須
Android 14（API レベル 34）以降をターゲットとするアプリの場合、アプリ内のフォアグラウンド サービスごとに少なくとも 1 つのフォアグラウンド サービス タイプを指定する必要があります（アプリのユースケースを表すフォアグラウンド サービス タイプを選択します）。システムは、特定のタイプのフォアグラウンド サービスが、特定のユースケースを満たすことを想定しています。
アプリのユースケースがこれらのタイプのいずれにも関連していない場合は、WorkManager またはユーザーが開始するデータ転送ジョブを使用するようにロジックを移行することを強くおすすめします。
BluetoothAdapter での BLUETOOTH_CONNECT 権限の適用
对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，在调用 BluetoothAdapter getProfileConnectionState() 方法时，Android 14 会强制执行 BLUETOOTH_CONNECT 权限。
此方法已需要 BLUETOOTH_CONNECT 权限，但未强制执行。确保您的应用在应用的 AndroidManifest.xml 文件中声明 BLUETOOTH_CONNECT，如以下代码段所示，并在调用 getProfileConnectionState 之前检查用户是否已授予相应权限。
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
OpenJDK 17 の更新
Android 14 将继续更新 Android 的核心库，以与最新 OpenJDK LTS 版本中的功能保持一致，包括适合应用和平台开发者的库更新和 Java 17 语言支持。
以下变更可能会影响应用兼容性：
- 对正则表达式的更改：现在，为了更严格地遵循 OpenJDK 的语义，不允许无效的组引用。您可能会看到
java.util.regex.Matcher类抛出IllegalArgumentException的新情况，因此请务必测试应用中使用正则表达式的情形。如需在测试期间启用或停用此变更，请使用兼容性框架工具切换DISALLOW_INVALID_GROUP_REFERENCE标志。 - UUID 处理：现在，验证输入参数时，
java.util.UUID.fromString()方法会执行更严格的检查，因此您可能会在反序列化期间看到IllegalArgumentException。如需在测试期间启用或停用此变更，请使用兼容性框架工具切换ENABLE_STRICT_VALIDATION标志。 - ProGuard 问题：有时，在您尝试使用 ProGuard 缩减、混淆和优化应用时，添加
java.lang.ClassValue类会导致问题。问题源自 Kotlin 库，该库会根据Class.forName("java.lang.ClassValue")是否会返回类更改运行时行为。如果您的应用是根据没有java.lang.ClassValue类的旧版运行时开发的，则这些优化可能会将computeValue方法从派生自java.lang.ClassValue的类中移除。
JobScheduler がコールバックとネットワークの動作を強化
自从引入后，JobScheduler 期望您的应用从
onStartJob 或 onStopJob。在 Android 14 之前，如果作业运行时间过长，系统会停止作业并静默失败。如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台，
超过在主线程上授予的时间，应用会触发 ANR
显示“没有响应 onStartJob”错误消息或
“onStopJob没有回复”。
此 ANR 可能是由以下 2 种情况造成的：
1.有工作阻塞主线程，阻止回调 onStartJob
或者onStopJob在预期时间内执行并完成。
2. 开发者在 JobScheduler 中运行阻塞工作
回调 onStartJob 或 onStopJob，阻止从
在预期的时限内完成
要解决第 1 个问题，您需要进一步调试阻塞主线程的因素
您可以使用以下代码
ApplicationExitInfo#getTraceInputStream()，用于获取 Tombstone
ANR 发生时的跟踪信息如果您能够手动重现 ANR 问题
您可以录制系统轨迹，并使用
Android Studio 或 Perfetto，以便更好地了解应用上运行的
在发生 ANR 时调用主线程
请注意，直接使用 JobScheduler API 或使用 androidx 库 WorkManager 时可能会发生这种情况。
如需解决问题 2，请考虑迁移到 WorkManager，它支持将 onStartJob 或 onStopJob 中的任何处理封装在异步线程中。
JobScheduler 还引入了一项要求，即如果使用 setRequiredNetworkType 或 setRequiredNetwork 约束条件，则必须声明 ACCESS_NETWORK_STATE 权限。如果您的应用未声明
ACCESS_NETWORK_STATE 权限
Android 14 或更高版本，则会导致 SecurityException。
Tiles のリリース API
Android 14 以降をターゲットとするアプリの場合、TileService#startActivityAndCollapse(Intent) のサポートが終了し、呼び出されると例外がスローされるようになりました。アプリがタイルからアクティビティを起動する場合は、代わりに TileService#startActivityAndCollapse(PendingIntent) を使用してください。
プライバシー
写真と動画への部分的なアクセス権
Android 14 では、選択した写真へのアクセスが導入されています。これにより、ユーザーは特定の種類のすべてのメディアへのアクセス権をアプリに付与するのではなく、ライブラリ内の特定の画像や動画へのアクセス権をアプリに付与できるようになりました。
この変更は、アプリが Android 14（API レベル 34）以降をターゲットとしている場合にのみ有効になります。まだ写真選択ツールを使用していない場合は、アプリに実装することをおすすめします。これにより、画像と動画を選択する際の一貫したエクスペリエンスを提供できるほか、ストレージの権限をリクエストしなくてもユーザーのプライバシーを保護できます。
ストレージ権限を使用して独自のギャラリー選択ツールを維持し、実装を完全に制御する必要がある場合は、新しい READ_MEDIA_VISUAL_USER_SELECTED 権限を使用するように実装を調整してください。アプリが新しい権限を使用していない場合、システムはアプリを互換モードで実行します。
ユーザー エクスペリエンス
全画面インテント通知を保護
在 Android 11（API 级别 30）中，任何应用都可以在手机处于锁定状态时使用 Notification.Builder.setFullScreenIntent 发送全屏 intent。您可以通过在 AndroidManifest 中声明 USE_FULL_SCREEN_INTENT 权限，在应用安装时自动授予此权限。
全屏 intent 通知适用于需要用户立即注意的极高优先级通知，例如用户来电或用户配置的闹钟设置。对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，获准使用此权限的应用仅限于提供通话和闹钟的应用。对于不适合此情况的任何应用，Google Play 商店会撤消其默认的 USE_FULL_SCREEN_INTENT 权限。这些政策变更的截止日期为 2024 年 5 月 31 日。
在用户更新到 Android 14 之前，在手机上安装的应用仍拥有此权限。用户可以开启和关闭此权限。
您可以使用新 API NotificationManager.canUseFullScreenIntent 检查应用是否具有该权限；如果没有，应用可以使用新 intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT 启动设置页面，在该页面中，用户可以授予权限。
セキュリティ
暗黙的インテントとペンディング インテントの制限
Android 14（API レベル 34）以降をターゲットとするアプリの場合、Android は、アプリが内部アプリ コンポーネントに暗黙的インテントを送信することを次の方法で制限します。
- 暗黙的インテントは、エクスポートされたコンポーネントにのみ配信されます。アプリは、明示的インテントを使用してエクスポートされていないコンポーネントに配信するか、コンポーネントをエクスポート済みとしてマークする必要があります。
- アプリがコンポーネントまたはパッケージを指定しないインテントで可変ペンディング インテントを作成した場合、システムは例外をスローするようになりました。
この変更により、アプリの内部コンポーネントによる使用を目的とした暗黙的インテントを、悪意のあるアプリがインターセプトするのを防ぐことができます。
たとえば、アプリのマニフェスト ファイルで宣言できるインテント フィルタは次のようになります。
<activity
android:name=".AppActivity"
android:exported="false">
<intent-filter>
<action android:name="com.example.action.APP_ACTION" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
アプリが暗黙的インテントを使用してこのアクティビティを起動しようとすると、ActivityNotFoundException 例外がスローされます。
Kotlin
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(Intent("com.example.action.APP_ACTION"))
Java
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(new Intent("com.example.action.APP_ACTION"));
エクスポートされていないアクティビティをアプリが起動するには、代わりに明示的インテントを使用する必要があります。
Kotlin
// This makes the intent explicit. val explicitIntent = Intent("com.example.action.APP_ACTION") explicitIntent.apply { package = context.packageName } context.startActivity(explicitIntent)
Java
// This makes the intent explicit. Intent explicitIntent = new Intent("com.example.action.APP_ACTION") explicitIntent.setPackage(context.getPackageName()); context.startActivity(explicitIntent);
実行時に登録されるブロードキャスト レシーバでは、エクスポート動作を指定する必要がある
Android 14（API レベル 34）以降をターゲットとし、コンテキスト登録されたレシーバを使用するアプリとサービスでは、レシーバをデバイスの他のすべてのアプリにエクスポートするかどうかを示すフラグ（RECEIVER_EXPORTED または RECEIVER_NOT_EXPORTED）をそれぞれ指定する必要があります。この要件は、これらのレシーバ向けに Android 13 で導入された機能を利用して、アプリをセキュリティの脆弱性から保護するのに役立ちます。
システム ブロードキャストのみを受信するレシーバの例外
アプリで Context#registerReceiver メソッド（Context#registerReceiver() など）を通じてシステム ブロードキャストのレシーバのみを登録する場合は、レシーバの登録時にフラグを指定しないでください。
動的コードの読み込みの安全性を改善
アプリが Android 14（API レベル 34）以降をターゲットとし、動的コードの読み込み（DCL）を使用している場合、動的に読み込まれるファイルはすべて読み取り専用としてマークする必要があります。そうしないと、システムは例外をスローします。アプリが 動的に読み込まれるコード そのようにすると、アプリが不正使用される可能性があるリスクが 攻撃から保護できます。
コードを動的に読み込む必要がある場合は、次の方法を使用して、ファイルを開いた直後、コンテンツが書き込まれる前に、動的読み込みファイル（DEX、JAR、APK ファイルなど）を読み取り専用ファイルとして設定します。
Kotlin
val jar = File("DYNAMICALLY_LOADED_FILE.jar") val os = FileOutputStream(jar) os.use { // Set the file to read-only first to prevent race conditions jar.setReadOnly() // Then write the actual file content } val cl = PathClassLoader(jar, parentClassLoader)
Java
File jar = new File("DYNAMICALLY_LOADED_FILE.jar"); try (FileOutputStream os = new FileOutputStream(jar)) { // Set the file to read-only first to prevent race conditions jar.setReadOnly(); // Then write the actual file content } catch (IOException e) { ... } PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);
既存の動的読み込みファイルを処理する
既存の動的読み込みファイルに対して例外がスローされないようにするには、ファイルを削除して再作成してから、アプリでファイルを動的に読み込み直すことをおすすめします。ファイルを再作成するときは、上記のガイダンスに沿って書き込み時にファイルを読み取り専用としてマークしてください。既存のファイルに読み取り専用として再度ラベルを付けることもできますが、その場合は、信頼できる値に照らしてファイルの署名を確認するなど、最初にファイルの整合性を確認することを強くおすすめします。これにより、悪意のあるアクションからアプリを保護できます。
バックグラウンドからのアクティビティの起動に関する追加の制限
Android 14（API レベル 34）以上をターゲットとするアプリでは、アプリがバックグラウンドからアクティビティを開始できるタイミングがさらに制限されます。
- アプリが
PendingIntent#send()などのメソッドを使用してPendingIntentを送信する際、自身のバックグラウンド アクティビティを開始する権限を付与してペンディング インテントを開始する場合、オプトインが必須になりました。オプトインするには、アプリでsetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)を含むActivityOptionsバンドルを渡す必要があります。 - 表示されているアプリが
bindService()メソッドを使用してバックグラウンドにある別のアプリのサービスをバインドする場合、バインドされたサービスに自身のバックグラウンド アクティビティを開始する権限を付与するには、表示されているアプリがオプトインする必要があります。アプリがオプトインするには、bindService()メソッドを呼び出す際にBIND_ALLOW_ACTIVITY_STARTSフラグを含める必要があります。
この変更により、既存の制限セットが拡張されるため、悪意のあるアプリが API を悪用してバックグラウンドで破壊的なアクティビティを開始することを防止し、ユーザーを保護できます。
zip パス トラバーサル
Android 14（API レベル 34）以降をターゲットとするアプリの場合、Android は zip パス トラバーサルの脆弱性を回避するために、zip ファイルのエントリ名に「..」が含まれる場合、またはエントリ名が「/」で始まる場合、ZipFile(String) と ZipInputStream.getNextEntry() は ZipException をスローします。
アプリは dalvik.system.ZipPathValidator.clearCallback() を呼び出すことで、この検証をオプトアウトできます。
MediaProjection キャプチャ セッションごとにユーザーの同意が必要
Android 14（API レベル 34）以降をターゲットとするアプリでは、次のいずれかのシナリオで MediaProjection#createVirtualDisplay によって SecurityException がスローされます。
- アプリは、
MediaProjectionManager#createScreenCaptureIntentから返されたIntentをキャッシュに保存し、MediaProjectionManager#getMediaProjectionに複数回渡します。 - アプリが同じ
MediaProjectionインスタンスでMediaProjection#createVirtualDisplayを複数回呼び出している。
アプリは、各キャプチャ セッションの前にユーザーに同意を求める必要があります。1 回の回収セッションは MediaProjection#createVirtualDisplay の 1 回の呼び出しであり、各 MediaProjection インスタンスは 1 回だけ使用する必要があります。
構成の変更に対処する
アプリで MediaProjection#createVirtualDisplay を呼び出して、構成の変更（画面の向きや画面サイズの変更など）を処理する必要がある場合は、次の手順に沿って既存の MediaProjection インスタンスの VirtualDisplay を更新します。
- 新しい幅と高さで
VirtualDisplay#resizeを呼び出します。 - 新しい幅と高さを持つ新しい
SurfaceをVirtualDisplay#setSurfaceに指定します。
コールバックを登録する
アプリは、キャプチャ セッションを続行するための同意をユーザーが許可しなかった場合のケースを処理するコールバックを登録する必要があります。これを行うには、Callback#onStop を実装し、関連するリソース（VirtualDisplay や Surface など）をアプリで解放します。
アプリがこのコールバックを登録していない場合、アプリが呼び出すと MediaProjection#createVirtualDisplay は IllegalStateException をスローします。
非 SDK の制限の更新
Android 14 では、Android デベロッパーの協力と直近の内部テストに基づいて、制限を受ける非 SDK インターフェースのリストが更新されています。Google は、非 SDK インターフェースを制限する前に、可能な限り、その代わりとなる公開インターフェースを利用可能にしています。
Android 14 をターゲットとしないアプリでは、この変更の一部はすぐには影響しない可能性があります。ただし、現時点で（アプリのターゲット API レベルに応じて）一部の非 SDK インターフェースを利用できていても、非 SDK のメソッドまたはフィールドをそのまま使用し続けると、将来的にアプリが機能しなくなるリスクが高くなります。
アプリが非 SDK インターフェースを使用しているかどうか不明な場合は、アプリをテストして確認できます。アプリが非 SDK インターフェースに依存している場合は、SDK の代替インターフェースへの移行を計画してください。ただし Google も、一部のアプリには非 SDK インターフェースを使用する正当なユースケースがあると承知しています。アプリの機能に使用している非 SDK インターフェースの代わりが見つからない場合は、新しい公開 API をリクエストしてください。
Android の今回のリリースの変更について詳しくは、非 SDK インターフェースの制限に関する Android 14 での変更点をご覧ください。非 SDK インターフェース全般について詳しくは、非 SDK インターフェースの制限をご覧ください。