The Android 15 Beta is now available. Try it out today and let us know what you think!

このページは Cloud Translation API によって翻訳されました。

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

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

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

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

カスタム通知

Android 12 では、フルカスタム通知の外観と動作が変更されました。以前のカスタム通知では、通知領域全体を使用して、独自のレイアウトとスタイルを指定することが可能でした。その結果、アンチパターンが発生して、ユーザーが混乱したり異なるデバイス間でレイアウト互換性の問題が生じたりすることがありました。

Android 12 をターゲットとするアプリでは、カスタムコンテンツビューを使用する通知は通知領域全体を使用せず、代わりにシステムが標準テンプレートを適用するようになります。このテンプレートにより、カスタム通知がすべての状態において他の通知と同じ装飾を持つことが保証されます。たとえば、通知のアイコンと展開のアフォーダンス（折りたたまれた状態の場合）や、通知のアイコン、アプリ名、および折りたたみのアフォーダンス（展開された状態の場合）などです。この動作は、Notification.DecoratedCustomViewStyle の動作とほぼ同じです。

これにより、Android 12 では、すべての通知の視覚的な一貫性が確保されます。また、ユーザーにとって見つけやすく親しみやすい外観で通知が展開されるため、スキャンが容易になります。

次の図は、標準テンプレートによるカスタム通知を示しています。

次の例は、折りたたまれた状態と展開された状態でカスタム通知がどのようにレンダリングされるかを示しています。

Android 12 における変更は、Notification.Style のカスタムサブクラスを定義しているアプリや、Notification.Builder のメソッド setCustomContentView(RemoteViews)、setCustomBigContentView(RemoteViews)、setCustomHeadsUpContentView(RemoteViews) を使用しているアプリに影響します。

フルカスタム通知を使用しているアプリがある場合は、できるだけ早く新しいテンプレートでテストすることをおすすめします。

カスタム通知の変更を有効にするには:
1. アプリの targetSdkVersion を S に変更して、新しい動作を有効にします。
2. 再コンパイルします。
3. Android 12 を実行しているデバイスまたはエミュレータにアプリをインストールします。
カスタムビューを使用する通知をすべてテストし、シェード内で想定どおりに表示されることを確認します。テストの際には、これらの点を考慮し、必要な調整を行います。
- カスタムビューの寸法が変更されました。一般的に、カスタム通知に提供される高さは以前より低くなります。折りたたまれた状態では、カスタムコンテンツの最大の高さは 106 dp から 48 dp に減少します。また、水平方向のスペースが縮小されます。
- Android 12 をターゲットとするアプリでは、すべての通知を展開できます。そのため、setCustomContentView を使用している場合、通常は setBigCustomContentView も使用して、折りたたまれた状態と展開された状態に一貫性を持たせる必要があります。
- 「ヘッドアップ」の状態が想定どおりに表示されるようにするには、通知チャンネルの重要度を必ず「高」（画面上のポップアップ表示）に上げてください。

Android アプリリンクの検証に関する変更

Android 12 以降をターゲットとするアプリでは、Android アプリリンクの検証方法に変更が加えられます。この変更により、アプリリンクエクスペリエンスの信頼性が向上し、アプリデベロッパーとエンドユーザーが、より細かく制御できるようになります。

Android アプリリンクの検証を使用してアプリ内でウェブリンクを開く場合は、Android アプリリンクの検証用に正しい形式のインテントフィルタを追加していることを確認してください。特に、これらのインテントフィルタに BROWSABLE カテゴリが含まれ、https スキームをサポートしていることを確認してください。

アプリのリンクを手動で検証し、宣言の信頼性をテストすることもできます。

ピクチャーインピクチャーの動作の改善

Android 12 では、ピクチャーインピクチャー（PIP）モードの動作が改善され、ジェスチャーナビゲーションと要素ベースのナビゲーションの両方で遷移アニメーションに推奨される外観の改善が導入されています。

詳しくは、ピクチャーインピクチャーの改善をご覧ください。

トーストのデザイン変更

Android 12 では、トーストの外見が変更されています。トーストは、2 行のテキストに制限され、テキストの横にアプリアイコンが表示されるようになりました。

トーストポップアップでアプリアイコンの横に [Sending message] が表示されている Android デバイスの画像

詳しくは、トーストの概要をご覧ください。

セキュリティとプライバシー

おおよその現在地

Android 12 以上を搭載しているデバイスでは、アプリに対してユーザーがおおよその位置情報という精度をリクエストすることができます。

WebView での最新の SameSite Cookie

Android の WebView コンポーネントは、Google の Chrome ブラウザを支えるオープンソースプロジェクトである Chromium をベースにしています。Chromium は、セキュリティとプライバシーを強化してより高い透明性と管理性をユーザーに提供するため、サードパーティ Cookie の処理に関する変更を導入しました。Android 12 以降、アプリが Android 12（API レベル 31）以降をターゲットとしている場合、これらの変更も WebView に含まれます。

Cookie の SameSite 属性は、Cookie を任意のリクエストで送信できるか、同一サイトリクエストのみで送信できるかを制御します。サードパーティ Cookie のデフォルト処理を改善し、意図しないクロスサイト共有を防止するため、次に示すプライバシー保護の変更が取り入れられています。

SameSite 属性が設定されていない Cookie は SameSite=Lax として扱われます。
SameSite=None の Cookie には、Secure 属性も指定する必要があります。つまり、そうした Cookie はセキュアコンテキストを必要とし、HTTPS で送信する必要があります。
サイトの HTTP バージョンと HTTPS バージョン間のリンクは、クロスサイトリクエストとして扱われるようになりました。したがって、SameSite=None; Secure として適切にマークされていない限り、Cookie は送信されません。

デベロッパー向けのガイダンスとして、重要なユーザーフローでクロスサイト Cookie の依存関係を明らかにし、必要に応じて SameSite 属性に適切な値が明示的に設定されていることを確認するようおすすめします。ウェブサイト間で、または HTTP から HTTPS に移動する同一サイトナビゲーションで動作することを許可する Cookie を明示的に指定する必要があります。

これらの変更に関するウェブデベロッパー向けの詳細なガイダンスについては、SameSite Cookie の説明およびスキームフル SameSite の記事をご覧ください。

アプリで SameSite 動作をテストする

アプリで WebView を使用している場合や、Cookie を使用するウェブサイトまたはサービスを管理している場合は、Android 12 の WebView でフローをテストすることをおすすめします。問題が見つかった場合は、新しい SameSite 動作に対応するために Cookie の更新が必要になる可能性があります。

ログインと埋め込みコンテンツで問題が発生しないか、また、ユーザーが安全でないページから出発して安全なページに移動するログインフロー、購入フロー、およびその他の認証フローで問題が発生しないかを確認してください。

WebView を使用するアプリをテストするには、次のいずれかの手順を実施して、テスト対象のアプリで新しい SameSite 動作を有効にする必要があります。

WebView DevTools で UI フラグ webview-enable-modern-cookie-same-site を切り替えることにより、テストデバイス上の SameSite 動作を手動で有効にします。

このアプローチでは、Android 5.0（API レベル 21）以上（Android 12 を含む）と WebView バージョン 89.0.4385.0 以上を実行しているデバイスで、テストを実施できます。
targetSdkVersion により、Android 12（API レベル 31）をターゲットとしてアプリをコンパイルします。

このアプローチでは、Android 12 を実行しているデバイスを使用する必要があります。

Android での WebView のリモートデバッグについては、Android デバイスでリモートデバッグを開始するをご覧ください。

その他のリソース

最新の SameSite 動作と Chrome および WebView へのロールアウトについて詳しくは、Chromium の SameSite アップデートのページをご覧ください。WebView または Chromium でバグが見つかった場合は、一般公開されている Chromium Issue Tracker での報告をお願いします。

モーションセンサーのレート制限

アプリが Android 12 以降をターゲットにしている場合、ユーザーの機密に該当する可能性がある情報を保護するため、特定のモーションセンサーや位置センサーからのデータのリフレッシュレートに制限が課されます。

詳しくは、センサーのレート制限をご覧ください。

アプリの休止状態

Android 12 では、Android 11（API レベル 30）で導入された許可のオートリセットの動作が拡張されています。アプリが Android 12 をターゲットとしていて、ユーザーが数か月にわたってアプリを操作しなかった場合、付与されたすべての権限が自動的にリセットされ、アプリが休止状態になります。

詳しくは、アプリの休止状態に関するガイドをご覧ください。

データアクセスの監査におけるアトリビューション宣言

Android 11（API レベル 30）で導入された Data Access Auditing API を使用すると、アプリのユースケースに基づいてアトリビューションタグを作成できます。これらのタグを使用することで、特定の種類のデータアクセスをアプリのどの部分で実行するかを簡単に指定できます。

Android 12 以降をターゲットとするアプリの場合は、アプリのマニフェストファイルでこれらのアトリビューションタグを宣言する必要があります。

ADB バックアップの制限

限定公開アプリのデータを保護するため、Android 12 では adb backup コマンドのデフォルト動作が変更されました。Android 12（API レベル 31）以降をターゲットとするアプリでは、ユーザーが adb backup コマンドを実行したとき、デバイスからエクスポートされる他のシステムデータからアプリデータが除外されます。

テストまたは開発ワークフローが adb backup を使用して取得するアプリデータに依存している場合は、アプリのマニフェストファイルで android:debuggable を true に設定することにより、アプリデータのエクスポートを有効にすることができるようになりました。

コンポーネントのエクスポートの安全性を改善

Android 12 以降をターゲットとするアプリに、インテントフィルタを使用するアクティビティ、サービス、またはブロードキャストレシーバが含まれている場合は、それらのアプリコンポーネントで android:exported 属性を明示的に宣言する必要があります。

アプリコンポーネントに LAUNCHER カテゴリが含まれている場合は、android:exported を true に設定します。他のほとんどの場合は、android:exported を false に設定します。

次のコードスニペットは、android:exported 属性が false に設定されているインテントフィルタを含むサービスの例を示しています。

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Android Studio のメッセージ

インテントフィルタを使用し、android:exported を宣言していないアクティビティ、サービス、ブロードキャストレシーバがアプリに含まれている場合は、使用する Android Studio のバージョンに応じて、次の警告メッセージが表示されます。

Android Studio 2020.3.1 Canary 版 11 以降

次のメッセージが表示されます。

マニフェストファイルに、次の lint 警告が表示されます。
```
When using intent filters, please specify android:exported as well
```

アプリをコンパイルしようとすると、次のビルドエラーメッセージが表示されます。

Manifest merger failed : Apps targeting Android 12 and higher are required \
to specify an explicit value for android:exported when the corresponding \
component has an intent filter defined.

古いバージョンの Android Studio

アプリをインストールしようとすると、logcat に次のエラーメッセージが表示されます。

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

ペンディングインテントの可変性

Android 12 をターゲットとするアプリでは、アプリが作成する個々の PendingIntent オブジェクトの可変性を指定する必要があります。この追加要件により、アプリのセキュリティが強化されます。

ペンディングインテントの可変性の変更をテストする

アプリに可変性の宣言が欠けているかどうかを確認するには、Android Studio で次の lint 警告を検索します。

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

インテントの安全でない起動

Android 12 以降では、プラットフォームのセキュリティを強化するため、インテントの安全でない起動を検出するデバッグ機能が導入されました。このような安全でない起動がシステムによって検出されると、StrictMode 違反が発生します。

パフォーマンス

フォアグラウンドサービスの起動に関する制限

Android 12 以降をターゲットとするアプリでは、少数の特殊なケースを除き、バックグラウンドでの実行中にはフォアグラウンドサービスを開始できません。アプリがバックグラウンドで動作しているときにフォアグラウンドサービスを起動しようとすると、（少数の特殊なケースを除いて）例外が発生します。

アプリがバックグラウンドで動作しているときに、WorkManager を使用してスケジュールを設定し、優先処理を開始することを検討してください。ユーザーが要求する、時間的制約のあるアクションを完了するには、正確なアラームの範囲内でフォアグラウンドサービスを開始します。

正確なアラームの権限

アプリによるシステムリソースの節約を促進するため、Android 12 以降をターゲットとし、正確なアラームを設定したアプリでは、システム設定の [特別なアプリアクセス] 画面に表示される「アラームとリマインダー」機能へのアクセス権が必要になります。

この特別なアプリアクセスを取得するには、マニフェストで SCHEDULE_EXACT_ALARM 権限をリクエストします。

正確なアラームは、ユーザー向けの機能にのみ使用する必要があります。正確なアラームの設定に利用可能なユースケースの詳細をご確認ください。

動作変更を無効にする

Android 12 をターゲットとしたアプリを準備する際には、デバッグ可能なビルドバリアントの動作変更をテスト目的で一時的に無効にできます。そのためには、次のいずれかを行います。

[開発者向けオプション] 設定画面で、[アプリの互換性の変更] を選択します。表示された画面でアプリの名前をタップし、[REQUIRE_EXACT_ALARM_PERMISSION] をオフにします。
開発マシンのターミナルウィンドウで次のコマンドを実行します。
```
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
```

通知トランポリンの制限

ユーザーが通知を操作したとき、一部のアプリは通知のタップに反応してアプリコンポーネントを起動し、このアプリコンポーネントにより、ユーザーが最終的に確認して操作するアクティビティが開始されます。このようなアプリコンポーネントを「通知トランポリン」と呼びます。

アプリのパフォーマンスと UX を改善するため、Android 12 以降をターゲットとするアプリでは、通知トランポリンとして使用しているサービスまたはブロードキャストレシーバからアクティビティを開始できないようになっています。つまり、ユーザーが通知または通知内のアクションボタンをタップした後、アプリはサービスまたはブロードキャストレシーバ内で startActivity() を呼び出すことができません。

通知トランポリンとして機能するサービスまたはブロードキャストレシーバからアプリがアクティビティを開始しようとすると、システムによってアクティビティの開始が阻止され、logcat に以下のメッセージが表示されます。

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

通知トランポリンとして機能するアプリコンポーネントを特定する

アプリをテストするとき、通知をタップすると、アプリ内の通知トランポリンとして機能したサービスまたはブロードキャストレシーバを特定できます。そのためには、次のターミナルコマンドの出力を確認します。

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

出力のセクションには、「NotifInteractionLog」というテキストが含まれます。このセクションには、通知をタップすると開始されるコンポーネントを特定するために必要な情報が含まれています。

アプリの更新

通知トランポリンとして機能するサービスまたはブロードキャストレシーバからアクティビティを開始するアプリがある場合は、次の移行手順を実施します。

ユーザーが通知をタップしたときに表示されるアクティビティに関連付けられた PendingIntent オブジェクトを作成します。
通知を作成する際に、前の手順で作成した PendingIntent オブジェクトを使用します。

たとえば、ロギングを行う目的でアクティビティの発生元を特定するには、通知の送信時にエクストラを使用します。ロギングを一元的に行う場合は、ActivityLifecycleCallbacks または Jetpack ライフサイクルオブザーバーを使用します。

動作の切り替え

アプリのデバッグ可能なバージョンをテストする場合には、NOTIFICATION_TRAMPOLINE_BLOCK アプリ互換性フラグを使用して、この制限を有効または無効にできます。

バックアップと復元

Android 12（API レベル 31）をターゲットとして動作するアプリでは、バックアップと復元の仕組みが変更されています。Android のバックアップと復元には 2 つの形式があります。

クラウドバックアップ: ユーザーデータはユーザーの Google ドライブに保存され、後で対象のデバイスや新しいデバイスで復元できます。
デバイス間（D2D）転送: ケーブルを使用するなどして、ユーザーデータが以前のデバイスからユーザーの新しいデバイスに直接送信されます。

データのバックアップと復元について詳しくは、自動バックアップでユーザーデータをバックアップすると Android Backup Service を使用して Key-Value ペアをバックアップするをご覧ください。

D2D 転送機能の変更

Android 12 以降をターゲットとして動作するアプリの場合:

XML 構成メカニズムで包含ルールと除外ルールを指定しても、D2D 転送には影響しませんが、クラウドベースのバックアップと復元（Google ドライブのバックアップなど）には影響します。D2D 転送のルールを指定するには、次のセクションで説明する新しい構成を使用する必要があります。
一部のデバイスメーカーのデバイスでは、android:allowBackup="false" を指定すると Google ドライブへのバックアップが無効になりますが、アプリの D2D 転送は無効になりません。

追加と除外の新しい形式

Android 12 以降をターゲットとして動作するアプリは、使用する XML 構成の形式が異なります。この形式では、Google ドライブのバックアップと D2D 転送の違いを明確にするため、クラウドバックアップと D2D 転送に追加ルールと除外ルールを別々に指定する必要があります。

必要に応じて、バックアップのルールを指定することもできます。この場合、Android 12 以降を搭載したデバイスでは、以前に使用した構成が無視されます。Android 11 以前を搭載しているデバイスでは、引き続き古い構成が必要です。

XML 形式の変更

Android 11 以前のバックアップと復元の構成に使用する形式は次のとおりです。

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

形式の変更点を太字で示します。

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

詳しくは、自動バックアップによるユーザーデータのバックアップに関するガイドの対応するセクションをご覧ください。

アプリのマニフェストフラグ

マニフェストファイルで android:dataExtractionRules 属性を使用して、アプリが新しい XML 構成を指すようにします。新しい XML 構成を指すと、Android 12 以降を搭載したデバイスでは、古い構成を指す android:fullBackupContent 属性は無視されます。次のコードサンプルは、新しいマニフェストファイルのエントリを示しています。

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

接続

Bluetooth の権限

Android 12 では、BLUETOOTH_SCAN、BLUETOOTH_ADVERTISE、BLUETOOTH_CONNECT 権限が導入されました。この権限により、Android 12 をターゲットとするアプリ、特にデバイスの位置情報へのアクセスを必要としないアプリで、Bluetooth デバイスの操作が容易になります。

Android 12 以上をターゲットとするようにデバイスを準備するには、アプリのロジックを更新します。従来の Bluetooth 権限のセットを宣言するのではなく、最新の Bluetooth 権限セットを宣言します。

ピアツーピア接続とインターネット接続の同時実行

Android 12（API レベル 31）以降をターゲットとするアプリの場合、ピアツーピア接続とインターネット接続の同時接続をサポートするデバイスは、ピアデバイスとプライマリインターネットネットワークの両方への Wi-Fi 接続を同時に維持できます。これにより、ユーザーエクスペリエンスがよりシームレスになります。Android 11（API レベル 30）以下をターゲットとするアプリでは、ピアデバイスに接続する前にプライマリ Wi-Fi 接続が切断されるという従来の動作が引き続き発生します。

互換性

WifiManager.getConnectionInfo() は、1 つのネットワークの WifiInfo のみを返すことができます。そのため、Android 12 以降では API の動作が次のように変更されました。

利用可能な Wi-Fi ネットワークが 1 つのみの場合は、WifiInfo が返されます。
複数の Wi-Fi ネットワークが利用可能で、呼び出し元のアプリがピアツーピア接続をトリガーした場合、ピアデバイスに対応する WifiInfo が返されます。
複数の Wi-Fi ネットワークが利用可能で、呼び出し元のアプリがピアツーピア接続をトリガーしていない場合、プライマリインターネット接続の WifiInfo が返されます。

同時に 2 つの Wi-Fi ネットワークをサポートするデバイスでのユーザーエクスペリエンスを向上させるため、すべてのアプリ（特にピアツーピア接続をトリガーするアプリ）で、WifiManager.getConnectionInfo() を呼び出すのではなく、NetworkCallback.onCapabilitiesChanged() を使用するように移行することをおすすめします。これにより、NetworkCallback の登録に使用された NetworkRequest に一致するすべての WifiInfo オブジェクトを取得できるようになります。Android 12 では getConnectionInfo() のサポートが終了しています。

次のコードサンプルは、NetworkCallback で WifiInfo を取得する方法を示しています。

Kotlin

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

Java

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

mDNSResponder ネイティブ API

Android 12 では、mDNSResponder ネイティブ API を使用して、アプリが mDNSResponder デーモンを操作できるタイミングが変更されています。以前は、アプリがネットワーク上でサービスを登録して getSystemService() メソッドを呼び出すと、アプリがまだ NsdManager メソッドを呼び出していない場合でも、システムの NSD サービスが mDNSResponder デーモンを起動していました。デーモンはその後、すべてのノードのマルチキャストグループにデバイスを登録するため、システムが頻繁に復帰することで消費電力が増えていました。バッテリー使用量を最小限に抑えるために、Android 12 以降では、NSD イベントで必要な場合にのみ mDNSResponder デーモンを起動し、その後停止するようになりました。

この変更は mDNSResponder デーモンを使用できるタイミングに影響するため、getSystemService() メソッドを呼び出した後に mDNSResponder デーモンが開始されることを想定したアプリは、mDNSResponder デーモンを使用できないことを示すメッセージをシステムから受け取る可能性があります。NsdManager を使用し、mDNSResponder ネイティブ API を使用しないアプリは、この変更の影響を受けません。

ベンダーライブラリ

ベンダー提供のネイティブ共有ライブラリ

シリコンベンダーまたはデバイスメーカーが提供する非 NDK のネイティブ共有ライブラリは、アプリが Android 12（API レベル 31）以降をターゲットとしている場合、デフォルトではアクセスできません。ライブラリにアクセスするには、<uses-native-library> タグを使用して明示的にリクエストする必要があります。

Android 11（API レベル 30）以下をターゲットとするアプリの場合、<uses-native-library> タグは不要です。この場合、ネイティブ共有ライブラリは、NDK ライブラリかどうかにかかわらずアクセスできます。

非 SDK の制限の更新

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

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

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

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