これまでのリリースと同様、Android 14 には、アプリに影響する可能性がある動作変更が含まれています。下記の動作変更は、Android 14（API レベル 34）以上をターゲットとするアプリにのみ適用されます。アプリが Android 14 以上をターゲットとする場合は、必要に応じてアプリを変更し、下記の動作に適切に対応できるようにしてください。
アプリの targetSdkVersion に関係なく、Android 14 で実行されるすべてのアプリに影響する動作変更のリストも必ずご確認ください。
コア機能
フォアグラウンド サービス タイプは必須
Android 14（API レベル 34）以降をターゲットとするアプリの場合、アプリ内のフォアグラウンド サービスごとに少なくとも 1 つのフォアグラウンド サービス タイプを指定する必要があります（アプリのユースケースを表すフォアグラウンド サービス タイプを選択します）。システムは、特定のタイプのフォアグラウンド サービスが、特定のユースケースを満たすことを想定しています。
アプリのユースケースがこれらのタイプのいずれにも関連していない場合は、WorkManager またはユーザーが開始するデータ転送ジョブを使用するようにロジックを移行することを強くおすすめします。
BluetoothAdapter での BLUETOOTH_CONNECT 権限の適用
对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，Android 14 会在调用 BluetoothAdapter getProfileConnectionState() 方法时强制执行 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）以降をターゲットとし、メインスレッドで許可された時間が超過すると、アプリは「onStartJob への応答なし」または「onStopJob への応答なし」というエラー メッセージとともに ANR をトリガーします。
この ANR は、次の 2 つのシナリオの結果である可能性があります。
1. メインスレッドをブロックする処理があり、コールバック onStartJob または onStopJob が想定された時間制限内に実行されず、完了しません。2. デベロッパーが JobScheduler コールバック onStartJob または onStopJob 内でブロッキング処理を実行しているため、コールバックが想定された制限時間内に完了していません。
1 の問題に対処するには、メインスレッドをブロックしているものをさらにデバッグする必要があります。
アラートのタイムスタンプを
ApplicationExitInfo#getTraceInputStream(): tombstone を取得します
トレースをトリガーできますANR を手動で再現できる場合は
システム トレースを記録し、次のいずれかの方法でトレースを検査できます。
Android Studio または Perfetto を使用して、何が
メインスレッドで待機します。
これは、JobScheduler API を直接使用する場合や、androidx ライブラリの WorkManager を使用する場合に発生する可能性があります。
2 に対処するには、WorkManager への移行を検討してください。
onStartJob または onStopJob での処理をラップするためのサポート
呼び出されることがあります
JobScheduler には、サービス アカウント キーの
ACCESS_NETWORK_STATE 権限（setRequiredNetworkType または
setRequiredNetwork 制約。アプリがジョブのスケジュール設定時に ACCESS_NETWORK_STATE 権限を宣言しておらず、Android 14 以降をターゲットとしている場合、SecurityException が発生します。
Tiles launch 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 会通过以下方式限制应用向内部应用组件发送隐式 intent：
- 隐式 intent 只能传送到导出的组件。应用必须使用显式 intent 传送到未导出的组件，或将该组件标记为已导出。
- 如果应用通过未指定组件或软件包的 intent 创建可变待处理 intent，系统会抛出异常。
这些变更可防止恶意应用拦截意在供应用内部组件使用的隐式 intent。
例如，下面是可以在应用的清单文件中声明的 intent 过滤器：
<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>
如果应用尝试使用隐式 intent 启动此 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"));
如需启动非导出的 activity，应用应改用显式 intent：
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()）针对系统广播注册接收器，那么它在注册接收器时不应指定标志。
動的コードの読み込みの安全性を改善
If your app targets Android 14 (API level 34) or higher and uses Dynamic Code Loading (DCL), all dynamically-loaded files must be marked as read-only. Otherwise, the system throws an exception. We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.
If you must dynamically load code, use the following approach to set the dynamically-loaded file (such as a DEX, JAR, or APK file) as read-only as soon as the file is opened and before any content is written:
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);
Handle dynamically-loaded files that already exist
To prevent exceptions from being thrown for existing dynamically-loaded files, we recommend deleting and recreating the files before you try to dynamically load them again in your app. As you recreate the files, follow the preceding guidance for marking the files read-only at write time. Alternatively, you can re-label the existing files as read-only, but in this case, we strongly recommend that you verify the integrity of the files first (for example, by checking the file's signature against a trusted value), to help protect your app from malicious actions.
バックグラウンドからのアクティビティの起動に関する追加の制限
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：
- 使用新的宽度和高度调用
VirtualDisplay#resize。 - 向
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 の今回のリリースの変更について詳しくは、非 SDK インターフェースの制限に関する Android 14 での変更点をご覧ください。非 SDK インターフェース全般について詳しくは、非 SDK インターフェースの制限をご覧ください。