動作の変更点: すべてのアプリ

Android 17 プラットフォームには、アプリに影響する可能性がある動作変更が含まれています。下記の動作変更は、targetSdkVersion に関係なく、Android 17 上で稼働するすべてのアプリに適用されます。該当する場合は、アプリをテストし、必要に応じて修正して、これらの変更に対応する必要があります。

Android 17 をターゲットとするアプリにのみ影響する動作変更のリストも必ずご確認ください。

コア機能

Android 17（API レベル 37）には、Android システムのさまざまなコア機能を変更または拡張する以下の変更が含まれています。

アプリのメモリ上限

Android 17 では、アプリと Android ユーザーにとってより安定した決定論的な環境を実現するため、デバイスの合計 RAM に基づくアプリのメモリ上限が導入されました。Android 17 では、システム全体の不安定さにつながる極端なメモリリークやその他の外れ値が原因で UI の動作がカクカクしたり、バッテリーの消耗が激しくなったり、アプリが強制終了したりする前に、システム ベースラインを確立するために上限が控えめに設定されています。ほとんどのアプリセッションへの影響は最小限に抑えられると予想されますが、メモリのベースラインの確立など、次のメモリに関するベスト プラクティスをおすすめします。

アプリ セッションが影響を受けたかどうかは、ApplicationExitInfo で getDescription を呼び出すことで確認できます。アプリが 影響を受けた場合、終了理由は REASON_OTHER になり、 説明には他の情報とともに文字列 "MemoryLimiter:AnonSwap" が含まれます。トリガーベースのプロファイリングを TRIGGER_TYPE_ANOMALYとともに使用すると、 メモリ上限に達したときに収集されるヒープダンプを取得することもできます。

アプリのメモリを管理するのドキュメントでは、アプリのメモリの問題を診断し、リソース消費を最適化するのに役立つ情報を提供しています。

メモリ制約下でのアプリの動作をテストする

Android Debug Bridge (adb)を使用すると、 メモリ上限を適用するデバイスでメモリ上限を調整または無効にできます。シェルコマンド am には、メモリ上限を調整するための 3 つのサブコマンドがあります。（これらのコマンドは、メモリ上限を適用しないデバイスでは効果がありません）。

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

一部またはすべてのプロセスを無視するようにメモリ リミッターに指示します。 UID（Android ユーザー ID）を渡すと、メモリリミッターは その UID に関連付けられているすべてのプロセスに対する適用を無視します。 all（すべてのアプリを無視）または none（アプリを無視しない）を渡すこともできます。none を渡すと、以前の am memory-limiter ignore の呼び出しがオーバーライドされます。

UID を無視するようにメモリ リミッターに指示した場合でも、am memory-limiter manual を呼び出すことで、アプリ内のプロセスに手動でメモリ上限を適用できます。

manual

指定された PID（プロセス ID）のプロセスにメモリ制約を適用するようにシステムに指示します。メモリ制約は MB 単位の整数で指定します。たとえば、30 を渡すと、プロセスは 30 MB のメモリに制限されます。max を渡すと、そのプロセスのすべてのメモリ上限が削除されます。none を渡すと、プロセスに設定されている手動の上限が削除され、システムのデフォルトの上限（存在する場合）が復元されます。

status

メモリ リミッターの現在のステータスを報告します。ステータスには、表示プロセスと非表示プロセスに適用されるメモリ上限が含まれます。

プライバシー

Android 17 では、ユーザーのプライバシーを強化するために、次のような変更が行われています。

SMS OTP 保護

从 Android 17 开始，Android 将扩大对包含一次性密码 (OTP) 的短信的保护范围。

在之前的 Android 版本中，此保护主要侧重于 SMS Retriever 格式。对于大多数应用，包含 SMS Retriever 哈希的消息的递送延迟了 3 小时。不过，某些应用（例如默认短信处理程序）不受此延迟的影响，拥有哈希的应用也不受此延迟的影响。

从 Android 17 开始，此保护也适用于 WebOTP 格式的消息。如果应用有权读取短信，但不是 WebOTP 消息的预期接收者（由网域验证确定），则该应用在收到消息后 3 小时内无法访问该消息。此变更旨在提高用户安全性，确保只有与消息中提及的网域关联的应用才能以编程方式读取验证码。

在这 3 小时的延迟期间，系统会保留 SMS_RECEIVED_ACTION 广播，并过滤 短信提供商 数据库查询。延迟结束后，这些应用即可使用短信。此变更适用于 所有应用，无论其目标 API 级别如何。

某些应用（例如默认短信助理应用、关联设备配套应用等）不受此延迟的影响。所有依赖于读取短信 来提取 OTP 的应用都应过渡到使用 SMS Retriever 或 SMS User Consent API，以确保功能持续可用。

セキュリティ

Android 17 では、デバイスとアプリのセキュリティが以下のように改善されています。

usesClearTraffic の非推奨プラン

今後のリリースで、usesCleartextTraffic 要素は非推奨になる予定です。暗号化されていない（HTTP）接続を行う必要があるアプリは、ネットワーク セキュリティ構成ファイルを使用するように移行する必要があります。このファイルを使用すると、アプリがクリアテキスト接続を行う必要があるドメインを指定できます。

ネットワーク セキュリティ構成ファイルは API レベル 24 以上でのみサポートされます。アプリの最小 API レベルが 24 未満の場合は、次の両方を行う必要があります。

  • usesCleartextTraffic 属性を true に設定します。
  • ネットワーク構成ファイルを使用する

アプリの最小 API レベルが 24 以上の場合、ネットワーク構成ファイルを使用できるため、usesCleartextTraffic を設定する必要はありません。

暗黙的な URI 権限付与を制限する

現在、アプリがアクション ACTION_SEND、ACTION_SEND_MULTIPLE、または ACTION_IMAGE_CAPTUREを含む URI でインテントを起動すると、システムはターゲットアプリに読み取りと 書き込みの URI 権限を自動的に付与します。Android 18 以降では、システムは これらの権限を自動的に付与しなくなります。そのため、アプリはシステムに権限を付与させるのではなく、関連する URI 権限を明示的に付与することをおすすめします。

アプリでこれらのインテントが使用されていることを検出するには、StrictMode と detectImplicitUriPermissionGrant() を使用して違反をトリガーします。

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

または、システムが暗黙的に付与を設定したときに表示されるメッセージ Please set the grant explicitly in the app を含む、記録された例外をモニタリングすることもできます。これらのログは、次の adb コマンドを使用してモニタリングできます。

adb logcat | grep "Please set the grant explicitly in the app"

必要な権限を明示的に付与するには、 FLAG_GRANT_READ_URI_PERMISSION フラグを ACTION_SEND インテントと ACTION_SEND_MULTIPLE インテントに追加します。

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

ACTION_IMAGE_CAPTURE インテントには、FLAG_GRANT_READ_URI_PERMISSION フラグと FLAG_GRANT_WRITE_URI_PERMISSION フラグの両方を含めます。

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

アプリごとのキーストアの制限

应用应避免在 Android 密钥库中创建过多的密钥，因为它是设备上所有应用的共享资源。从 Android 17 开始，系统会强制限制应用可拥有的密钥数量。对于以 Android 17（API 级别 37）或更高版本为目标平台的非系统应用，密钥数量上限为 50,000 个；对于所有其他应用，密钥数量上限为 200,000 个。无论系统应用以哪个 API 级别为目标，其密钥数量上限均为 20 万。

如果应用尝试创建超出限制的密钥，则创建会失败并显示 KeyStoreException。异常的消息字符串包含有关密钥限制的信息。如果应用针对异常调用 getNumericErrorCode()，则返回值取决于应用的目标 API 级别：

  • 如果应用以 Android 17（API 级别 37）或更高版本为目标平台，getNumericErrorCode() 会返回新的 ERROR_TOO_MANY_KEYS 值。
  • 所有其他应用：getNumericErrorCode() 返回 ERROR_INCORRECT_USAGE。

クロス プロファイル ループバック トラフィックをブロック

Android 17 以降では、デフォルトでプロファイル間のループバック トラフィックが許可されなくなりました。同じプロファイル内のループバック トラフィックは影響を受けません。 この変更は、アプリがターゲットとする API レベルに関係なく、Android 17 以降で実行されるすべてのアプリに適用されます。

ユーザー エクスペリエンスとシステム UI

Android 17 には、より一貫性のある直感的なユーザー エクスペリエンスを実現するための以下の変更が含まれています。

回転後の IME の可視性に関するデフォルトを復元

Android 17 以降では、デバイスの構成が変更されたとき（回転など）に、アプリ自体で処理されない場合、以前の IME の可視性は復元されません。

アプリが処理しない構成変更が行われ、変更後にキーボードを表示する必要がある場合は、明示的にリクエストする必要があります。このリクエストは、次のいずれかの方法で行うことができます。

  • android:windowSoftInputMode 属性を stateAlwaysVisible に設定します。
  • アクティビティの onCreate() メソッドでソフト キーボードをプログラムでリクエストするか、onConfigurationChanged() メソッドを追加します。

手入力

Android 17 には、キーボードやタッチパッドなどのヒューマン入力デバイスとアプリがやり取りする方法に影響する次の変更が含まれています。

ポインタ キャプチャ中、タッチパッドはデフォルトで相対イベントを配信する

从 Android 17 开始，如果应用使用 View.requestPointerCapture() 请求捕获指针，并且用户使用触控板，系统会识别用户触摸操作产生的指针移动和滚动手势，并以与捕获的鼠标产生的指针和滚轮移动相同的方式将这些信息报告给应用。在大多数情况下，这使得支持捕获鼠标的应用无需为触控板添加特殊的处理逻辑。如需了解详情，请参阅 View.POINTER_CAPTURE_MODE_RELATIVE 的文档。

之前，系统不会尝试识别触控板的手势，而是以类似于触摸屏触摸的格式将原始的绝对手指位置传递给应用。如果应用仍需要此绝对数据，则应改为使用 View.POINTER_CAPTURE_MODE_ABSOLUTE 调用新的 View.requestPointerCapture(int) 方法。

メディア

Android 17 では、メディアの動作が次のように変更されています。

バックグラウンド音声の強化

Android 17 以降では、オーディオ フレームワークは、オーディオ再生、音声フォーカス リクエスト、音量変更 API などのバックグラウンド オーディオ インタラクションに対する制限を適用し、これらの変更がユーザーによって意図的に開始されるようにします。

アプリが有効なライフサイクルにないときにアプリが音声 API を呼び出そうとすると、例外をスローしたり、エラー メッセージを提供したりすることなく、音声再生 API と音量変更 API はサイレントに失敗します。音声フォーカス API が結果コード AUDIOFOCUS_REQUEST_FAILED で失敗します。

軽減策など、詳しくは、バックグラウンド音声の強化をご覧ください。

接続

Android 17 では、デバイスの接続性を強化するために次の変更が加えられています。

Bluetooth ボンドの損失に対する自律的な再ペア設定

Android 17 引入了自主重新配对功能，这是一项系统级增强功能，旨在自动解决蓝牙配对信息丢失问题。

以前，如果配对信息丢失，用户必须手动前往“设置”取消配对，然后重新配对外围设备。此功能以 Android 16 的安全改进为基础，允许系统在后台重新建立配对信息，而无需用户手动前往“设置”取消配对并重新配对外围设备。

虽然大多数应用不需要更改代码，但开发者应注意蓝牙堆栈中的以下行为变更：

  • 新的配对上下文： ACTION_PAIRING_REQUEST 现在包含 EXTRA_PAIRING_CONTEXT extra，允许应用区分 标准配对请求和自主系统发起的重新配对尝试。
  • 有条件的密钥更新：只有在重新配对成功且新连接达到或超过之前配对信息的安全级别时，才会替换现有安全密钥。
  • 修改后的 intent 时间：现在，只有在自主重新配对尝试失败时，才会广播 ACTION_KEY_MISSING intent。如果系统在后台成功恢复配对信息，则可以减少应用中不必要的错误处理。
  • 用户通知：系统通过新的界面通知和对话框管理重新配对。系统会提示用户确认重新配对尝试，以确保用户了解重新连接。

外围设备制造商和配套应用开发者应验证硬件和应用是否能妥善处理配对信息转换。如需测试此行为，请使用以下任一方法模拟远程配对信息丢失：

  • 从外围设备中手动移除配对信息
  • 在“设置”>“已连接的设备”中手动取消配对设备