認証情報マネージャーを使用すると、Android エコシステム全体で認証を簡素化できます。ユーザーには一貫したエクスペリエンスを提供し、デベロッパーには統合された API サーフェスを提供して、パスキー、パスワード、「Google でログイン」などのフェデレーション ログイン メカニズムを使用できるようにします。コア プログラミング インターフェースはフォーム ファクタ間で一貫していますが、各フォーム ファクタには独自の UI と UX の考慮事項があります。実装を成功させるには、アプリの認証フローを各デバイスの特定の入力方法、画面サイズ、ユーザー コンテキストに適応させる必要があります。
このガイドでは、さまざまな Android フォーム ファクタで認証情報マネージャーを実装する方法の概要を説明し、考慮すべきポイントをハイライトして、詳細なドキュメントへのリンクを示します。
モバイル デバイス
スマートフォン、タブレット、折りたたみ式デバイスなどのモバイル デバイスは、Android デベロッパーの最も一般的なターゲットです。標準の認証情報マネージャーの実装は、通常タッチスクリーンとデバイス上のキーボードを備えているこれらのデバイスに適しています。このフォーム ファクタのユーザー エクスペリエンスは、他のフォーム ファクタに適応させるためのベースラインとなります。認証フローはフォーム ファクタに適しており、デバイスの画面領域と入力方法の機能を最大限に活用する必要があります。
Wear OS
Wear OS デバイスは、画面が小さく、デバイス上の入力が限られていることが特徴です。認証情報マネージャーのパスキー実装により、ユーザーはペア設定されたスマートフォンを接続したり、パスワードを記憶したりすることなく、アプリに安全にログインできます。
Wear OS の API はモバイルと同じであるため、既存のモバイル統合を再利用できます。パスキー、「Google でログイン」、認証情報マネージャーのパスワードに加えて、Data Layer Token Sharing、OAuth、既存のソリューションなどの他の認証方法を使用できます。これらは、ユーザーを認証情報マネージャーに移行する際のバックアップとして使用できます。データレイヤートークン共有の場合は、長期的なソリューションとして使用できます。
Wear OS で認証情報マネージャーを使用するには、次の要件を満たす必要があります。
- 最小 API レベル:
minSdkVersion33 以上- パスワード、パスキー、「Google でログイン」のサポートが含まれます
- GMS バージョン: モバイルアプリに必要なバージョンと同じ
Wear OS デバイスのユーザー インターフェースは次のとおりです。
実装に関する詳しいガイダンスとコードサンプルについては、次のリソースをご覧ください。
制限事項
Wear OS で認証情報マネージャーを使用する場合、次の制限があります。
- パスキーの作成はサポートされていません。
- Restore Credentials についてはサポートされていません。
Android XR
Android XR（バーチャル リアリティと拡張現実を含む）では、アプリは 3D 空間でレンダリングされます。ユーザー入力は他のフォーム ファクタとは根本的に異なり、ハンド ジェスチャーなどの自然な入力に依存します。
XR 用に認証情報マネージャーを適応させるには、3D 空間での認証 UI（パスキー、パスワード、フェデレーション ログイン方法のいずれを使用する場合でも）を再考する必要があります。たとえば、認証プロンプトはフローティング パネルに表示され、ユーザーはハンド ジェスチャーを使用して選択します。ターゲット XR デバイスの特定のハードウェアまたはソフトウェアの前提条件も考慮する必要があります。
重要な設計上の課題は、VR 環境または AR 環境で直感的で安全な認証エクスペリエンスを作成することです。また、複数のユーザーが同じデバイスを使用する可能性があるマルチユーザー XR シナリオで ID を管理する方法も検討する必要があります。
Android XR で認証情報マネージャーを使用するには、次の要件を満たす必要があります。
- 最小 API レベル:
minSdkVersion34 以上 - GMS バージョン: モバイルアプリに必要なバージョンと同じ
- エミュレータ:
- エミュレータの最小システム イメージ:
- macOS: Google Play XR ARM 64 v8a システム イメージ リビジョン 7
- Windows: Google Play XR Intel x86_64 Atom システム イメージ リビジョン 7
- エミュレータ バージョン 35.6.11 Stable より新しいバージョン
- エミュレータの最小システム イメージ:
XR でのログイン エクスペリエンスは次のようになります。
XR でサポートされていないフロー
Android XR の認証情報マネージャーは、別のデバイスで QR コードをスキャンする必要がある認証フローをサポートしていません。これは、XR ヘッドセットでのログイン プロセス中や、エミュレータでのテスト中に確認できます。
XR の詳細については、Android XR をご覧ください。
Android TV
Android TV デバイスは通常、共有で使用され、離れた場所から視聴され、D-pad リモコンを使用して操作されます。この環境でユーザー名とパスワードを入力することは困難な場合があります。認証情報マネージャーは、「Google でログイン」、保存されたパスワード、クロスデバイス パスキーをサポートすることで、Android TV での認証を簡素化します。共有テレビには複数の Google プロファイルが存在することが多いため、認証情報マネージャーは、現在アクティブなアカウントのみに選択肢を制限するのではなく、デバイスで利用可能なすべての認証情報を取得して表示することで、この共有設定に適応します。
この共有の性質により、パスキーの処理方法も決まります。テレビには個人のロック画面ナレッジ ファクタ（LSKF）がないため、パスキーはテレビに直接保存または作成されません。代わりに、パスキー認証ではクロスデバイス ハイブリッド フローを利用します。このフローでは、テレビに QR コードが表示され、ユーザーはモバイル デバイスでスキャンして生体認証を完了します。
isAutoSelectAllowed = true を設定すると、Google TV でクリック不要のフローが可能になりますが、一致する認証情報が 1 つだけ利用可能な場合に限ります。ネイティブのテレビのボトムシートが引き続き表示され、ユーザーのアカウント確認が表示されます。ユーザーがキャンセルしない場合、リモコンをクリックしなくても認証情報が自動的に返されます。一致する認証情報が複数ある場合は、自動選択されず、ユーザーに選択を求めるプロンプトが表示されます。
モバイルアプリとテレビアプリがまったく同じ Android パッケージ名と署名鍵を共有している場合、Google パスワード マネージャーはそれらを同じアプリ ID として認識します。
このため、モバイル デバイスに保存されたパスワードは、デジタル アセット リンク（asset_statements）を構成しなくても、テレビで直接提供できます。デジタル アセット リンクは、アプリとウェブサイトの間や、パッケージ名が異なるアプリ間など、境界を越えて認証情報を共有する場合にのみ必要です。
Android TV で認証情報マネージャーを使用するには、次の要件を満たす必要があります。
- 最小 API レベル: Android 14（API レベル 34、
minSdkVersion34）以上 - GMS バージョン: 2026W30 以降
- パスキーのハードウェア: QR コードをスキャンして FIDO ハイブリッド フローを完了するには、カメラと Bluetooth を搭載したセカンダリ モバイル デバイスが必要です。
制限事項
Android TV は共有デバイスであるため、このプラットフォームで認証情報マネージャーを使用する場合、ユーザーのプライバシーとセキュリティを保護するために、次の制限が意図的に設けられています。
- ローカル パスキーの作成または保存はできません: パスキーはテレビに直接作成または保存できません。ローカル認証情報はサポートされていないため、リクエストで
preferImmediatelyAvailableCredentialsをtrueに設定しないでください。設定すると、クロスデバイス パスキーがフィルタされ、認証情報が返されません。 - サードパーティの認証情報プロバイダはありません: Android TV は自動入力をサポートしていないため、サードパーティのパスワード マネージャーはプラットフォームで使用できません。 ユーザーは Google パスワード マネージャーを使用する必要があります。
- Restore Credentials はありません: Android TV では、 Restore Credentials についてを使用して新しいデバイスに自動的にログインすることはできません。
テレビ開発の詳細については、Android TV の概要をご覧ください。
Android Automotive OS
Android Automotive OS（AAOS）デバイスは、自動車に統合された共有システムです。AAOS 用に認証情報マネージャーを適応させるには、安全な認証（通常は車両が駐車しているとき）をサポートし、共有デバイスで複数のユーザー プロファイルに対応する必要があります。
大画面またはタブレット向けに最適化されたアプリを自動車に導入し、アプリがモバイル デバイスまたはタブレットで認証情報マネージャーとパスキーをすでにサポートしている場合、認証フローを変更しなくても Android Automotive OS で動作します。
Android Automotive OS での認証では、次の方法がサポートされています。
- パスキー（クロスデバイス ハイブリッド フロー）: ユーザーは、クロスデバイス フローを使用して既存のパスキーで認証できます。車の画面に QR コードが表示され、ユーザーはモバイル デバイスでスキャンします。生体認証と画面ロックの確認はユーザーのスマートフォンで行われるため、車のディスプレイで画面ロックを設定する必要はありません。
- Google でログイン: ネイティブの Google でログイン画面が車のディスプレイに直接表示されます。
- 保存されたパスワード: ユーザーは Google パスワード マネージャーから保存されたパスワードを取得して、車両の画面に認証情報を手動で入力せずにログインできます。
Android Automotive OS は、プロファイルごとにセッションと認証情報を管理し、ユーザー固有のセッション データをプロファイル間で分離します（例: プロファイル A、プロファイル B、ゲスト プロファイル）。
Android Automotive OS で認証情報マネージャーを使用するには、次の要件を満たす必要があります。
- 最小 API レベル: Android 9（API レベル 28、
minSdkVersion28）以上。クロスデバイス パスキーを取得するには、Android 14（API レベル 34）以上が必要です。 - GMS バージョン: モバイルアプリに必要なバージョンと同じ。
テストの制限事項
パスキーをテストするには、Android Automotive OS ビルドをプライマリ サーフェスとして実行する物理デバイスが必要です。セットアップ手順については、Android Automotive OS を Google Pixel Tablet で使用してテストするをご覧ください。エミュレータは、FIDO ハイブリッド フローに必要な Bluetooth Low Energy（BLE）をサポートしていないため、パスキーのテストには使用できません。
制限事項とサポートされていないフロー
Android Automotive OS で認証情報マネージャーを使用する場合、次の制限があります。
- ローカル パスキーの保存または取得はできません: 車両は共有デバイスであるため、ローカル パスキーの直接取得はサポートされていません。パスキーを車両に直接同期するとセキュリティ リスクが生じるため、パスキーはクロスデバイス ハイブリッド フローを使用して使用する必要があります。
- すぐに利用可能な認証情報はサポートされていません: アプリがパスキーをリクエストし、
preferImmediatelyAvailableCredentialsをtrueに設定すると、自動車の UI が直ちに終了し、NoCredentialExceptionがスローされます。 このシナリオに適したフォールバック UX を用意してください。 - サードパーティの認証情報プロバイダはありません: Android Automotive OS では、サードパーティのパスワード マネージャーはサポートされていません。ユーザーは、Google パスワード マネージャーまたはクロスデバイス ハイブリッド フローを使用して認証する必要があります。
- 保存されたパスワードの作成はできません: API は、車のインターフェースから直接新しい保存済みパスワードを作成して保存することをサポートしていません。認証情報の作成は、FIDO ハイブリッド フローを使用した新しいパスキーに限定されます。
Automotive OS の開発について詳しくは、Android Automotive OS の概要をご覧ください。