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

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

Android 13 で動作するすべてのアプリに影響する動作変更のリストも必ずご確認ください。

プライバシー

通知権限がフォアグラウンド サービスの表示に影響する

ユーザーが通知権限を拒否した場合、フォアグラウンド サービスに関連する通知は通知ドロワーに表示されません。ただし、フォアグラウンド サービスに関連する通知は、通知権限が付与されたかどうかにかかわらず、タスク マネージャーに引き続き表示されます。

付近の Wi-Fi デバイスに対する新しい実行時の権限

以前のバージョンの Android では、いくつかの一般的な Wi-Fi ユースケースに対応するために、ユーザーはアプリに ACCESS_FINE_LOCATION 権限を付与する必要があります。

ユーザーが位置情報の利用許可を Wi-Fi 機能に関連付けて理解するのは困難であることから、Android 13（API レベル 33）では、デバイスから付近のアクセス ポイントへの Wi-Fi 接続を管理するアプリ向けに、NEARBY_DEVICES 権限グループに実行時の権限を導入しています。この権限 NEARBY_WIFI_DEVICES で、次のような Wi-Fi ユースケースに対応できます。

• 付近のデバイス（プリンタやメディア キャスト デバイスなど）を検出または接続する。このワークフローでは、次のようなタスクをアプリで実行できます。
  • 帯域外で AP 情報を受信する（BLE 経由など）。
  • ローカル専用アクセス ポイントを使用して、Wi-Fi Aware と Connect でデバイスを検出して接続する。
  • Wi-Fi Direct でデバイスを検出して接続する。
• 既知の SSID への接続を開始する（車やスマートホーム デバイスなど）。
• ローカル専用のホットスポットを開始する。
• 付近の Wi-Fi Aware デバイスを探索する。

アプリが Wi-Fi API から物理的な位置情報を取得しないのであれば、Android 13 以上をターゲットに設定して Wi-Fi API を使用する場合は、ACCESS_FINE_LOCATION ではなく NEARBY_WIFI_DEVICES をリクエストしてください。NEARBY_WIFI_DEVICES 権限を宣言する場合、アプリが Wi-Fi API から物理的な位置情報を取得しないことを強く表明します。そのためには、android:usesPermissionFlags 属性を neverForLocation に設定します。このプロセスは、Bluetooth デバイス情報が位置情報に使用されないことを表明する場合に Android 12（API レベル 31）以上で実行するプロセスと似ています。

詳しくは、付近の Wi-Fi デバイスへアクセスする権限をリクエストする方法をご覧ください。

きめ細かいメディア権限

アプリが Android 13 以上をターゲットとし、他のアプリが作成したメディア ファイルにアクセスする必要がある場合は、READ_EXTERNAL_STORAGE 権限ではなく、以下のようなきめ細かいメディアの権限を 1 つ以上リクエストする必要があります。

別のアプリのメディア ファイルにアクセスする前に、ユーザーがアプリに適切な詳細なメディア権限を付与していることを確認します。

図 1 は、READ_MEDIA_AUDIO 権限をリクエストするアプリを示しています。

READ_MEDIA_IMAGES 権限と READ_MEDIA_VIDEO 権限の 2 つを同時にリクエストした場合、システム権限ダイアログは 1 つだけ表示されます。

以前にアプリに READ_EXTERNAL_STORAGE 権限が付与されていた場合は、アップグレード時にリクエストされた READ_MEDIA_* 権限が自動的に付与されます。アップグレードされた権限を確認するには、次の ADB コマンドを使用します。

adb shell cmd appops get --uid PACKAGE_NAME

バックグラウンドでボディセンサーを使用するには新しい権限が必要

Android 13 では、心拍数、体温、血中酸素率などを測定するボディセンサーへの「使用中」アクセスというコンセプトを導入しています。このアクセスモデルは、Android 10（API レベル 29）の位置情報でシステムに導入されたモデルとよく似ています。

Android 13 をターゲットとするアプリがバックグラウンドでの実行中にボディセンサー情報にアクセスする必要がある場合は、既存の BODY_SENSORS 権限に加えて、新しい BODY_SENSORS_BACKGROUND 権限を宣言する必要があります。

パフォーマンスとバッテリー

バッテリー リソース運用

ユーザーが Android 13 をターゲットとするアプリをバックグラウンドのバッテリー使用量について「制限付き」状態に設定している場合、他の理由でアプリが開始されるまで、BOOT_COMPLETED ブロードキャストや LOCKED_BOOT_COMPLETED ブロードキャストは行われません。

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

PlaybackState から派生するメディア コントロール

Android 13（API レベル 33）以上をターゲットとするアプリの場合は、PlaybackState アクションからメディア コントロールが派生します。そのため、スマートフォンとタブレット間で技術的に一貫した豊富なコントロールを表示できます。このコントロールは、Android Auto や Android TV など、各種の Android プラットフォームでのメディア コントロールのレンダリング方法に沿って表示されます。

図 2 に、スマートフォンとタブレットでの表示例をそれぞれ示します。

Android 13 より前のシステムでは、MediaStyle 通知から最大 5 つのアクションが、追加された順序で表示されていました。折りたたまれたクイック設定パネルなどのコンパクト モードでは、setShowActionsInCompactView() によって指定された最大 3 つのアクションが表示されていました。

Android 13 以上では、次の表に示すように、PlaybackState に基づいて最大 5 つのアクション ボタンが表示されます。コンパクト モードでは、最初の 3 つのアクション スロットのみが表示されます。Android 13 をターゲットとしないアプリ、または PlaybackState を含まないアプリの場合は、前の段落で示したように、MediaStyle 通知に追加された Action リストに基づいてコントロールが表示されます。

カスタム アクションは、PlaybackState に追加された順序で配置されます。

WebView のコンテンツに自動的に適用されるアプリのカラーテーマ

Android 13（API レベル 33）以上をターゲットとするアプリでは、setForceDark() メソッドのサポートが終了したため、このメソッドを呼び出すしても no-op になります。

代わりに、WebView はアプリのテーマ属性 isLightTheme に従って、常にメディアクエリ prefers-color-scheme を設定するようになりました。つまり、isLightTheme が true であるか、指定されていない場合、prefers-color-scheme は light になります。それ以外の場合は dark になります。この動作により、コンテンツが対応している場合には、ウェブ コンテンツのライトスタイルまたはダークスタイルがアプリのテーマに合わせて自動的に適用されます。

ほとんどのアプリでは、新しい動作により適切なアプリスタイルが自動的に適用されますが、アプリをテストして、ダークモード設定を手動で制御している可能性があるかどうかを確認する必要があります。

アプリのカラーテーマの動作をカスタマイズする必要がある場合は、代わりに setAlgorithmicDarkeningAllowed() メソッドを使用します。以前の Android バージョンとの下位互換性を維持するため、AndroidX で同等の setAlgorithmicDarkeningAllowed() メソッドを使用することをおすすめします。

アプリの targetSdkVersion とテーマ設定に応じてアプリがどのように動作するかについて詳しくは、このメソッドのドキュメントをご覧ください。

接続

BluetoothAdapter#enable() と BluetoothAdapter#disable() の非推奨

Android 13（API レベル 33）以上をターゲットとするアプリでは、BluetoothAdapter#enable() メソッドと BluetoothAdapter#disable() メソッドのサポートが終了し、常に false を返します。

次の種類のアプリは、これらの変更の対象外です。

• デバイス所有者アプリ
• プロファイル所有者アプリ
• システムアプリ

Google Play 開発者サービス

広告 ID に必要な権限

Google Play 開発者サービスの広告 ID を使用し、Android 13（API レベル 33）以上をターゲットとしているアプリでは、以下のようにマニフェスト ファイル内で、そのアプリの AD_ID 標準の権限を宣言する必要があります。

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

アプリが Android 13 以上をターゲットとしていて、この権限を宣言していない場合、広告 ID は自動的に削除され、0 を羅列した文字列に置換されます。

ライブラリのマニフェストで AD_ID 権限を宣言する SDK を使用しているアプリでは、権限がデフォルトでアプリのマニフェスト ファイルに統合されます。この場合、権限をアプリのマニフェスト ファイル内で宣言する必要はありません。

詳しくは、Google Play Console ヘルプの広告 ID をご覧ください。

非 SDK の制限の更新

Android 13 では、Android デベロッパーの協力と直近の内部テストに基づいて、制限を受ける非 SDK インターフェースのリストが更新されています。Google は、非 SDK インターフェースを制限する前に、可能な限り、その代わりとなる公開インターフェースを利用可能にしています。

Android 13 をターゲットとしないアプリでは、この変更の一部はすぐには影響しない可能性があります。ただし、現時点で（アプリのターゲット API レベルに応じて）一部の非 SDK インターフェースを利用できていても、非 SDK のメソッドまたはフィールドをそのまま使用し続けると、将来的にアプリが機能しなくなるリスクが高くなります。

アプリが非 SDK インターフェースを使用しているかどうか不明な場合は、アプリをテストして確認できます。アプリが非 SDK インターフェースに依存している場合は、SDK の代替インターフェースへの移行を計画してください。ただし Google も、一部のアプリには非 SDK インターフェースを使用する正当なユースケースがあると承知しています。アプリの機能で使用している非 SDK インターフェースの代替インターフェースが見つからない場合は、新しい公開 API をリクエストしてください。

Android の今回のリリースの変更について詳しくは、非 SDK インターフェースの制限に関する Android 13 での変更点をご覧ください。非 SDK インターフェース全般について詳しくは、非 SDK インターフェースの制限をご覧ください。