動作の変更点: Android 14 以上をターゲットとするアプリ

これまでのリリースと同様、Android 14 には、アプリに影響する可能性がある動作変更が含まれています。下記の動作変更は、Android 14（API レベル 34）以上をターゲットとするアプリにのみ適用されます。アプリが Android 14 以上をターゲットとする場合は、必要に応じてアプリを変更し、下記の動作に適切に対応できるようにしてください。

アプリの targetSdkVersion に関係なく、Android 14 で実行されるすべてのアプリに影響する動作変更のリストも必ずご確認ください。

コア機能

フォアグラウンド サービス タイプは必須

Android 14（API レベル 34）以降をターゲットとするアプリの場合、アプリ内のフォアグラウンド サービスごとに少なくとも 1 つのフォアグラウンド サービス タイプを指定する必要があります（アプリのユースケースを表すフォアグラウンド サービス タイプを選択します）。システムは、特定のタイプのフォアグラウンド サービスが、特定のユースケースを満たすことを想定しています。

注: Android 14 では、健全性とリモート メッセージのユースケース用のフォアグラウンド サービス タイプが導入されています。また、新しいタイプの短いサービス、特別なユースケース、システム除外も予約されています。

アプリのユースケースがこれらのタイプのいずれにも関連していない場合は、WorkManager またはユーザーが開始するデータ転送ジョブを使用するようにロジックを移行することを強くおすすめします。

BluetoothAdapter での BLUETOOTH_CONNECT 権限の適用

Android 14 では、Android 14（API レベル 34）以降をターゲットとするアプリで BluetoothAdapter getProfileConnectionState() メソッドを呼び出すときに、BLUETOOTH_CONNECT 権限が適用されます。

このメソッドにはすでに BLUETOOTH_CONNECT 権限が必要でしたが、適用されていませんでした。次のスニペットに示すように、アプリの AndroidManifest.xml ファイルで BLUETOOTH_CONNECT を宣言し、getProfileConnectionState を呼び出す前にユーザーが権限を付与していることを確認します。

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

OpenJDK 17 の更新

Android 14 では、最新の OpenJDK LTS リリースの機能に合わせて Android のコアライブラリを更新する取り組みが引き続き行われています。これには、アプリ デベロッパーとプラットフォーム デベロッパー向けのライブラリの更新と Java 17 言語のサポートが含まれます。

これらの変更のいくつかは、アプリの互換性に影響する可能性があります。

• 正規表現の変更: 無効なグループ参照は、OpenJDK のセマンティクスに厳密に従うことができなくなりました。java.util.regex.Matcher クラスが IllegalArgumentException をスローする新しいケースが発生する可能性があるため、正規表現を使用する領域について必ずアプリのテストを行ってください。テスト中にこの変更を有効または無効にするには、互換性フレームワーク ツールを使用して DISALLOW_INVALID_GROUP_REFERENCE フラグを切り替えます。
• UUID 処理: java.util.UUID.fromString() メソッドで入力引数を検証する際に、より厳格なチェックが行われるようになりました。これにより、シリアル化解除中に IllegalArgumentException が表示される場合があります。テスト中にこの変更を有効または無効にするには、互換性フレームワーク ツールを使用して ENABLE_STRICT_VALIDATION フラグを切り替えます。
• ProGuard の問題: java.lang.ClassValue クラスの追加により、ProGuard を使用するアプリの圧縮、難読化、最適化をしようとすると問題が発生することがあります。この問題は、Class.forName("java.lang.ClassValue") がクラスを返すかどうかに基づいてランタイムの動作を変更する Kotlin ライブラリに起因します。java.lang.ClassValue クラスを利用できない古いバージョンのランタイムを対象にアプリが開発されている場合、これらの最適化により、java.lang.ClassValue から派生したクラスから computeValue メソッドが削除されることがあります。

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。

タイル起動 API

对于以 Android 14 及更高版本为目标平台的应用， TileService#startActivityAndCollapse(Intent) 已弃用，现在会抛出 调用时抛出异常。如果您的应用从功能块启动 activity，请使用 TileService#startActivityAndCollapse(PendingIntent)。

プライバシー

写真と動画への部分的なアクセス権

Android 14 引入了“已选照片访问权限”，让用户可以向应用授予对其媒体库中特定图片和视频的访问权限，而不是授予对给定类型的所有媒体的访问权限。

只有当您的应用以 Android 14（API 级别 34）或更高版本为目标平台时，此更改才会启用。如果您尚未使用照片选择器，我们建议您在应用中实现照片选择器，以提供一致的图片和视频选择体验，同时增强用户隐私保护，而无需请求任何存储权限。

如果您使用存储权限维护自己的图库选择器，并且需要对实现保持完全控制，请调整实现以使用新的 READ_MEDIA_VISUAL_USER_SELECTED 权限。如果您的应用不使用新权限，系统会以兼容模式运行您的应用。

ユーザー エクスペリエンス

全画面インテント通知を保護

Android 11（API レベル 30）では、どのアプリも、スマートフォンがロックされているときに Notification.Builder.setFullScreenIntent を使用して全画面インテントを送信することが可能でした。AndroidManifest で USE_FULL_SCREEN_INTENT 権限を宣言することで、アプリのインストール時にこの権限を自動的に付与することができました。

全画面表示のインテント通知は、着信やユーザー設定によるアラームなど、ユーザーがすぐに確認する必要がある非常に優先度の高い通知向けに設計されています。Android 14（API レベル 34）以降をターゲットとするアプリの場合、この権限の使用が許可されているアプリは、通話とアラームのみを提供するアプリに限定されます。Google Play ストアでは、このプロファイルに一致しないアプリのデフォルトの USE_FULL_SCREEN_INTENT 権限が取り消されます。これらのポリシーの変更期限は 2024 年 5 月 31 日です。

ユーザーが Android 14 にアップデートする前にスマートフォンにインストールしていたアプリについては、この権限は有効なままになります。ユーザーはこの権限のオンとオフを切り替えることができます。

新しい API NotificationManager.canUseFullScreenIntent を使用すると、アプリに権限があるかどうかを確認できます。権限がない場合、アプリは新しいインテント 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。

您的应用必须在每次捕获会话之前征求用户同意。单次捕获会话是对 MediaProjection#createVirtualDisplay 的单次调用，并且每个 MediaProjection 实例只能使用一次。

处理配置变更

如果您的应用需要调用 MediaProjection#createVirtualDisplay 来处理配置更改（例如屏幕方向或屏幕大小更改），您可以按照以下步骤更新现有 MediaProjection 实例的 VirtualDisplay：

1. 使用新的宽度和高度调用 VirtualDisplay#resize。
2. 向 VirtualDisplay#setSurface 提供新的 Surface，并为其指定新的宽度和高度。

注册回调

您的应用应注册回调，以处理用户不同意继续拍摄会话的情况。为此，请实现 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 版本中的变更，请参阅 Android 14 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息，请参阅对非 SDK 接口的限制。