Android アプリリンクは、ウェブサイトの URL から Android アプリ内の対応するコンテンツをすぐに開けるようにする特別なタイプのディープリンクです。Android アプリリンクは Digital Asset Links API を使用して、アプリがそのドメインのリンクを自動的に開くようウェブサイトによって承認されているという信頼を確立します。URL を所有していることがシステムにより正常に確認されると、その URL インテントがアプリに自動的にルーティングされます。
アプリとウェブサイトの URL の両方を所有していることを確認する手順は次のとおりです。
autoVerify属性を含むインテント フィルタを追加します。この属性は、アプリがインテント フィルタで使用されている URL ドメインに属しているかどうかをシステムに通知します。デジタル アセット リンクの JSON ファイルを次の場所でホストして、ウェブサイトとインテント フィルタの関連付けを宣言します。
https://domain.name/.well-known/assetlinks.json
関連情報については、次のリソースをご覧ください。
アプリリンクの検証用のインテント フィルタを追加する
アプリのリンク処理検証を有効にするには、次の形式に一致するインテント フィルタを追加します。
<!-- Make sure you explicitly set android:autoVerify to "true". -->
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<!-- If a user clicks on a shared link that uses the "http" scheme, your
app should be able to delegate that traffic to "https". -->
<data android:scheme="http" />
<data android:scheme="https" />
<!-- Include one or more domains that should be verified. -->
<data android:host="..." />
</intent-filter>
autoVerify を各ホストの 1 つの <intent-filter> 宣言に含めるだけで十分ですが、そのホストが他のマークされていない宣言で使用されている場合でも、一貫性のために各 <intent-filter> 要素に autoVerify を追加することをおすすめします。これにより、マニフェスト ファイルの要素を削除またはリファクタリングした後も、定義するすべてのドメインとアプリとの関連付けが維持されます。
ドメイン検証プロセスにはインターネット接続が必要であり、完了までに時間がかかることがあります。プロセスの効率を向上させるため、Android 12 以降をターゲットとするアプリのドメインは、そのドメインが上記のコード スニペットで指定された形式を含む <intent-filter> 要素内にある場合にのみ検証されます。
複数のホスト用のアプリリンク機能をサポートする
システムは、アプリの URL インテント フィルタのデータ要素で指定されたホストを、そのインテント フィルタ内のそれぞれのウェブドメインでホストされているデジタル アセット リンク ファイルと照らし合わせて検証できる必要があります。検証が失敗した場合、システムはアプリ コンテンツへのディープリンクを作成するで説明されているように、デフォルトの動作に戻ってインテントを解決します。ただし、アプリの他のインテント フィルタで定義されている URL パターンのデフォルト ハンドラとしてアプリを検証することはできます。
注: Android 11（API レベル 30）以前では、マニフェストで定義したすべてのホストに一致するデジタル アセット リンク ファイルが見つかるまで、システムはアプリをデフォルト ハンドラとして検証しません。
たとえば、次のインテント フィルタを持つアプリは、assetlinks.json ファイルが https://www.example.com/.well-known/assetlinks.json で見つかったが https://www.example.net/.well-known/assetlinks.json ではなかった場合にのみ、https://www.example.com の検証に合格します。
<application>
<activity android:name=”MainActivity”>
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="http" />
<data android:scheme="https" />
<data android:host="www.example.com" />
</intent-filter>
</activity>
<activity android:name=”SecondActivity”>
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" />
<data android:host="www.example.net" />
</intent-filter>
</activity>
</application>
注: 同じインテント フィルタ内のすべての <data> 要素は、結合された属性のすべてのバリエーションを考慮するためにマージされます。たとえば、上記の最初のインテント フィルタには、HTTPS スキームのみを宣言する <data> 要素が含まれています。ただし、他の <data> 要素と組み合わせることで、インテント フィルタが http://www.example.com と https://www.example.com の両方をサポートするようになります。そのため、URI スキームとドメインの特定の組み合わせを定義する場合は、個別のインテント フィルタを作成する必要があります。
複数のサブドメイン用のアプリリンク機能をサポートする
デジタル アセット リンク プロトコルでは、インテント フィルタ内のサブドメインは、一意の個別のホストとして扱われます。そのため、インテント フィルタに、サブドメインが異なる複数のホストがリストされている場合は、各ドメインで有効な assetlinks.json を公開する必要があります。たとえば、次のインテント フィルタには、受け入れられるインテントの URL ホストとして www.example.com と mobile.example.com が含まれています。そのため、有効な assetlinks.json を https://www.example.com/.well-known/assetlinks.json と https://mobile.example.com/.well-known/assetlinks.json の両方で公開する必要があります。
<application>
<activity android:name=”MainActivity”>
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" />
<data android:scheme="https" />
<data android:host="www.example.com" />
<data android:host="mobile.example.com" />
</intent-filter>
</activity>
</application>
または、ワイルドカードを使用してホスト名（*.example.com など）を宣言する場合、ルートホスト名（example.com）で assetlinks.json ファイルを公開する必要があります。たとえば、次のインテント フィルタを使用するアプリは、assetlinks.json ファイルが https://example.com/.well-known/assetlinks.json で公開されている限り、example.com のサブ名（foo.example.com など）の検証に合格します。
<application>
<activity android:name=”MainActivity”>
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" />
<data android:host="*.example.com" />
</intent-filter>
</activity>
</application>
同じドメインに関連付けられている複数のアプリを確認する
同じドメインに関連付けられている複数のアプリを公開する場合、各アプリを正常に検証できます。ただし、軽量版とフル版のようにアプリがまったく同じドメインホストとパスを解決できる場合は、直近にインストールされたアプリのみがそのドメインのウェブ インテントを解決できます。
このような場合は、必要なパッケージの公開設定があれば、ユーザーのデバイス上で競合する可能性のあるアプリを確認します。次に、アプリで queryIntentActivities() を呼び出した結果を含むカスタム チューザ ダイアログを表示します。ユーザーは、ダイアログに表示された一致するアプリのリストから好みのアプリを選択できます。
ウェブサイトの関連付けを宣言する
ウェブサイトに関連付けられている Android アプリを示し、アプリの URL インテントを検証するには、デジタル アセット リンク JSON ファイルをウェブサイトで公開する必要があります。JSON ファイルでは、次のフィールドを使用して関連付けられたアプリを識別します。
package_name: アプリのbuild.gradleファイルで宣言されているアプリケーション ID。sha256_cert_fingerprints: アプリの署名証明書の SHA256 フィンガープリント。 Java keytool を使用してフィンガープリントを生成するには、次のコマンドを使用します。keytool -list -v -keystore my-release-key.keystore
このフィールドは複数のフィンガープリントをサポートし、デバッグビルドや製品版ビルドなど、さまざまなバージョンのアプリをサポートできます。アプリで Play アプリ署名を使用している場合、
keytoolをローカルで実行したときに生成される証明書フィンガープリントは通常、ユーザーのデバイス上の証明書フィンガープリントと一致しません。アプリで Play アプリ署名を使用しているかどうかは、Google Play Console デベロッパー アカウントのRelease > Setup > App signingで確認できます。使用している場合は、同じページにアプリの正しいデジタル アセット リンクの JSON スニペットも表示されます。
次の assetlinks.json ファイルの例では、リンクを開く権限を com.example Android アプリに付与しています。
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
1 つのウェブサイトを複数のアプリに関連付ける
ウェブサイトは、同じ assetlinks.json ファイル内で複数のアプリとの関連付けを宣言できます。次のファイルリストは、https://www.example.com/.well-known/assetlinks.json にある、2 つのアプリとの関連付けを個別に宣言するステートメント ファイルの例を示しています。
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example.puppies.app",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
},
{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example.monkeys.app",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
1 つのウェブホストにある複数のリソースに対してそれぞれ個別のリンクを用意し、各リンクを別のアプリで処理することができます。たとえば、app1 は https://example.com/articles のインテント フィルタを宣言し、app2 は https://example.com/videos のインテント フィルタを宣言します。
注: 1 つのドメインに関連付けられた複数のアプリは、同じ証明書で署名することも、異なる証明書で署名することもできます。
複数のウェブサイトを 1 つのアプリに関連付ける
複数のウェブサイトが、それぞれの assetlinks.json ファイルで同じアプリとの関連付けを宣言できます。次のファイルリストは、example.com と example.net と app1 の関連付けを宣言する方法の例を示しています。最初のリストは、example.com と app1 の関連付けを示しています。
https://www.example.com/.well-known/assetlinks.json
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.mycompany.app1",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
次のリストアイテムは、example.net と app1 の関連付けを示しています。これらのファイルがホストされている場所のみが異なります（.com と .net）。
https://www.example.net/.well-known/assetlinks.json
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.mycompany.app1",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
JSON 検証ファイルの公開
次の場所で JSON 検証ファイルを公開する必要があります。
https://domain.name/.well-known/assetlinks.json
注:
assetlinks.jsonファイルは、コンテンツ タイプapplication/jsonで提供されます。assetlinks.jsonファイルは、アプリのインテント フィルタで HTTPS がデータスキームとして宣言されているかどうかにかかわらず、HTTPS 接続でアクセスできる必要があります。assetlinks.jsonファイルは、リダイレクトなしでアクセス可能である必要があります（301 または 302 リダイレクトは不可）。- アプリリンクが複数のホストドメインをサポートしている場合は、各ドメインで
assetlinks.jsonファイルを公開する必要があります。複数ホストのアプリリンクのサポートをご覧ください。 - 一般公開されていない可能性のある開発用/テスト用 URL をマニフェスト ファイルに指定してアプリを公開しないでください（VPN でのみアクセスできるものなど）。このような場合の回避策は、ビルド バリアントを構成して、開発ビルド用に別のマニフェスト ファイルを生成することです。
Android アプリリンクの検証
アプリのインテント フィルタの少なくとも 1 つに android:autoVerify="true" が含まれている場合、Android 6.0（API レベル 23）以降を搭載しているデバイスにアプリをインストールすると、アプリのインテント フィルタ内の URL に関連付けられたホストが自動的に検証されます。Android 12 以降では、検証プロセスを手動で呼び出し、検証ロジックをテストすることもできます。
自動確認
システムの自動確認では、次のことを行います。
- 次のいずれかを含むすべてのインテント フィルタが検査されます。
- アクション:
android.intent.action.VIEW - カテゴリ:
android.intent.category.BROWSABLEとandroid.intent.category.DEFAULT - データスキーム:
httpまたはhttps
- アクション:
- 上記のインテント フィルタで見つかった一意のホスト名ごとに、Android は対応するウェブサイトで
https://hostname/.well-known/assetlinks.jsonにあるデジタル アセット リンク ファイルをクエリします。
アプリに関連付けるウェブサイトのリストを確認し、ホストされている JSON ファイルが有効であることを確認したら、デバイスにアプリをインストールします。非同期検証プロセスが完了するまで、少なくとも 20 秒待ちます。次のコマンドを使用して、システムによってアプリが検証されたかどうかを確認し、正しいリンク処理ポリシーを設定します。
adb shell am start -a android.intent.action.VIEW \
-c android.intent.category.BROWSABLE \
-d "http://domain.name:optional_port"
手動でのオーナー確認
Android 12 以降では、デバイスにインストールされているアプリのドメインの検証を手動で呼び出せます。このプロセスは、アプリが Android 12 をターゲットとしているかどうかに関係なく実施できます。
インターネット接続を確立する
ドメインの検証を行うには、テストデバイスをインターネットに接続する必要があります。
更新されたドメイン検証プロセスをサポートする
Android 12 以降をターゲットとするアプリの場合、更新されたドメインの所有権の証明プロセスが自動的に使用されます。
それ以外の場合は、更新された検証プロセスを手動で有効にできます。そのためには、ターミナル ウィンドウで次のコマンドを実行します。
adb shell am compat enable 175408749 PACKAGE_NAME
デバイスの Android アプリリンクの状態をリセットする
デバイスでドメインの検証を手動で呼び出す前に、テストデバイスの Android アプリリンクの状態をリセットする必要があります。そのためには、ターミナル ウィンドウで次のコマンドを実行します。
adb shell pm set-app-links --package PACKAGE_NAME 0 all
このコマンドは、デバイスを、ユーザーが任意のドメインのデフォルト アプリを選択する前と同じ状態にします。
ドメイン検証プロセスを呼び出す
デバイスの Android アプリリンクの状態をリセットした後、検証自体を実施できます。そのためには、ターミナル ウィンドウで次のコマンドを実行します。
adb shell pm verify-app-links --re-verify PACKAGE_NAME
検証結果を確認する
検証エージェントがリクエストを終えるまで少し待ってから、検証結果を確認します。これを行うには、次のコマンドを実行します。
adb shell pm get-app-links PACKAGE_NAME
このコマンドの出力は、次のようになります。
com.example.pkg:
ID: 01234567-89ab-cdef-0123-456789abcdef
Signatures: [***]
Domain verification state:
example.com: verified
sub.example.com: legacy_failure
example.net: verified
example.org: 1026
検証が完了したドメインは、ドメイン検証状態が verified になります。その他の状態は、ドメインの検証を実施できなかったことを示します。特に none の状態は、検証エージェントがまだ検証プロセスを完了していない可能性があることを示します。
特定のドメインについてドメインの検証で返される可能性がある戻り値を次に示します。
none- このドメインは何も記録されていません。検証エージェントがドメインの検証に関連するリクエストを終えるまでさらに数分待ってから、もう一度ドメイン検証プロセスを呼び出します。
verified- 宣言のアプリについて、ドメインの検証が完了しました。
approved- ドメインが（通常はシェルコマンドの実行によって）強制的に承認されました。
denied- ドメインが（通常はシェルコマンドの実行によって）強制的に拒否されました。
migrated- 以前のドメイン検証を使用した以前のプロセスの結果がシステムに保持されていました。
restored- ユーザーがデータの復元を行った後にドメインが承認されました。ドメインは以前に検証されているものと思われます。
legacy_failure- ドメインが以前の検証ツールによって拒否されました。具体的なエラーの理由は不明です。
system_configured- デバイス設定によりドメインが自動的に承認されました。
- エラーコード
1024以上 デバイスの検証ツールに固有のカスタム エラーコード。
ネットワーク接続が確立されていることを再確認し、もう一度ドメイン検証プロセスを呼び出します。
アプリをドメインに関連付けるようユーザーに依頼する
アプリをドメインについて承認するもう 1 つの方法は、アプリをそのドメインに関連付けるようユーザーに依頼することです。
アプリがすでにドメインに対して承認されているかどうかを確認する
ユーザーにプロンプトを表示する前に、アプリが、<intent-filter> 要素で定義したドメインのデフォルト ハンドラになっているかどうかを確認します。承認状態をクエリするには、次のいずれかの方法を使用します。
DomainVerificationManagerAPI（実行時）- コマンドライン プログラム（テスト中）
DomainVerificationManager
次のコード スニペットは、DomainVerificationManager API の使用方法を示しています。
Kotlin
val context: Context = TODO("Your activity or fragment's Context")
val manager = context.getSystemService(DomainVerificationManager::class.java)
val userState = manager.getDomainVerificationUserState(context.packageName)
// Domains that have passed Android App Links verification.
val verifiedDomains = userState?.hostToStateMap
?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_VERIFIED }
// Domains that haven't passed Android App Links verification but that the user
// has associated with an app.
val selectedDomains = userState?.hostToStateMap
?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_SELECTED }
// All other domains.
val unapprovedDomains = userState?.hostToStateMap
?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_NONE }
Java
Context context = TODO("Your activity or fragment's Context");
DomainVerificationManager manager =
context.getSystemService(DomainVerificationManager.class);
DomainVerificationUserState userState =
manager.getDomainVerificationUserState(context.getPackageName());
Map<String, Integer> hostToStateMap = userState.getHostToStateMap();
List<String> verifiedDomains = new ArrayList<>();
List<String> selectedDomains = new ArrayList<>();
List<String> unapprovedDomains = new ArrayList<>();
for (String key : hostToStateMap.keySet()) {
Integer stateValue = hostToStateMap.get(key);
if (stateValue == DomainVerificationUserState.DOMAIN_STATE_VERIFIED) {
// Domain has passed Android App Links verification.
verifiedDomains.add(key);
} else if (stateValue == DomainVerificationUserState.DOMAIN_STATE_SELECTED) {
// Domain hasn't passed Android App Links verification, but the user has
// associated it with an app.
selectedDomains.add(key);
} else {
// All other domains.
unapprovedDomains.add(key);
}
}
コマンドライン プログラム
開発中にアプリをテストする際、次のコマンドを実行すると、組織が所有するドメインの検証状態をクエリできます。
adb shell pm get-app-links --user cur PACKAGE_NAME
次の出力例では、「example.org」ドメインの検証が失敗したにもかかわらず、ユーザー 0 がシステム設定でアプリを手動で承認しており、そのドメインに対して他のパッケージは検証されていません。
com.example.pkg:
ID: ***
Signatures: [***]
Domain verification state:
example.com: verified
example.net: verified
example.org: 1026
User 0:
Verification link handling allowed: true
Selection state:
Enabled:
example.org
Disabled:
example.com
example.net
シェルコマンドを使用して、特定のドメインに関連付けられたアプリをユーザーが選択するプロセスをシミュレートすることもできます。これらのコマンドの詳細な説明は、adb shell pm の出力で確認できます。
リクエストの説明をする
ドメイン承認のリクエストを行う前に、ユーザーに状況を説明します。たとえばスプラッシュ画面、ダイアログ、または同様の UI 要素を表示して、アプリを特定のドメインのデフォルト ハンドラにする必要がある理由をユーザーに説明します。
リクエストを行う
アプリが何をするよう求めているのかをユーザーが理解したら、リクエストを行います。そのためには、次のコード スニペットに示すように、ACTION_APP_OPEN_BY_DEFAULT_SETTINGS インテントのアクションと、ターゲット アプリの package:com.example.pkg に一致するデータ文字列を含むインテントを呼び出します。
Kotlin
val context: Context = TODO("Your activity or fragment's Context")
val intent = Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
Uri.parse("package:${context.packageName}"))
context.startActivity(intent)
Java
Context context = TODO("Your activity or fragment's Context");
Intent intent = new Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
Uri.parse("package:" + context.getPackageName()));
context.startActivity(intent);
インテントが呼び出されると、ユーザーには [デフォルトで開く] という設定画面が表示されます。図 1 に示すように、この画面には [対応リンクを開く] というラジオボタンがあります。
ユーザーが [対応リンクを開く] をオンにすると、[このアプリで開くリンク] の下に一連のチェックボックスが表示されます。ユーザーはそこから、アプリに関連付けるドメインを選択できます。図 2 に示すように、[リンクを追加] を選択してドメインを追加することもできます。ユーザーが追加したドメイン内のリンクを選択すると、そのリンクがアプリで自動的に開きます。
![ラジオボタンをオンにすると下部のセクションにチェックボックスと [リンクを追加] ボタンが表示されます](https://developer.android.com/static/images/training/app-links/choose-domains.svg?authuser=19&hl=ja)
![各チェックボックスは追加できるドメインを表しています。ダイアログのボタンは [キャンセル] と [追加] です。](https://developer.android.com/static/images/training/app-links/add-domains.svg?authuser=19&hl=ja)
アプリが検証できないドメインをアプリで開く
サードパーティとしてリンクを開くことがアプリの主な機能であって、処理対象ドメインを検証する機能を備えていないこともあります。その場合は、ユーザーがウェブリンクを選択する際に、ファーストパーティ アプリとサードパーティ アプリのどちらかを選択できないことを説明します。ユーザーは、ドメインをサードパーティ アプリに手動で関連付ける必要があります。
さらに、ユーザーが希望する場合はファーストパーティ アプリでリンクを開くことができる、プロキシとして機能するダイアログまたはトランポリン アクティビティの導入を検討します。このようなダイアログまたはトランポリン アクティビティを設定する前に、アプリのウェブ インテント フィルタに一致するファーストパーティ アプリに対してパッケージの公開設定を持つようにアプリを設定します。
アプリリンクをテストする
アプリリンク機能を実装する際は、リンク機能をテストして、システムがアプリをウェブサイトに関連付け、想定どおりに URL リクエストを処理できることを確認する必要があります。
既存のステートメント ファイルをテストするには、 ステートメント リスト生成ツールとテスターツールを使用します。
検証するホストのリストを確定する
テストの際は、アプリに対してシステムが検証する必要がある関連ホストのリストを確認する必要があります。対応するインテント フィルタに次の属性と要素が含まれている URL をすべてリストアップします。
- 値が
httpまたはhttpsのandroid:scheme属性 - ドメイン URL パターンを持つ
android:host属性 android.intent.action.VIEWアクション要素android.intent.category.BROWSABLEカテゴリ要素
このリストを使用して、指定された各ホストとサブドメインでデジタル アセット リンクの JSON ファイルが提供されていることを確認します。
Digital Asset Links ファイルを確認する
ウェブサイトごとに、Digital Asset Links API を使用して、デジタル アセット リンク JSON ファイルが正しくホストされ、定義されていることを確認します。
https://digitalassetlinks.googleapis.com/v1/statements:list? source.web.site=https://domain.name:optional_port& relation=delegate_permission/common.handle_all_urls
リンクポリシーをチェックする
テストプロセスの一環として、リンク処理の現在のシステム設定を確認できます。次のコマンドを使用して、接続済みデバイス上のすべてのアプリに適用される既存のリンク処理ポリシーのリストを取得します。
adb shell dumpsys package domain-preferred-apps
あるいは、次のコマンドでも同じ処理を行うことができます。
adb shell dumpsys package d
注: アプリのインストール後、システムで検証プロセスが完了するまで 20 秒以上お待ちください。
このコマンドは、デバイスで定義されている各ユーザーまたはプロファイルのリストを、ヘッダーの前に次の形式で返します。
App linkages for user 0:
このヘッダーに続く出力では、そのユーザーのリンク処理設定が次の形式でリストされます。
Package: com.android.vending Domains: play.google.com market.android.com Status: always : 200000002
このリストは、対象ユーザーに関して、どのアプリがどのドメインに関連付けられているのかを示しています。
Package- マニフェストで宣言されているパッケージ名でアプリを識別します。Domains- このアプリがウェブリンクを処理するホストの完全なリストを表示します。区切り文字には空白スペースが使用されます。Status- このアプリの現在のリンク処理設定を表示します。検証に合格したアプリで、マニフェストにandroid:autoVerify="true"が含まれている場合、ステータスはalwaysになります。このステータスの後の 16 進数は、ユーザーのアプリリンク設定を記録した Android システムのレコードに関連しています。この値は検証が成功したかどうかを示すものではありません。
注: 検証が完了する前にユーザーがアプリのアプリリンク設定を変更すると、検証が失敗していても、検証成功に対する誤検出になることがあります。ただし、サポートされているリンクを開くようユーザーがアプリを明示的に有効にした場合、この検証失敗は問題ではありません。これは、ユーザー設定がプログラムによる検証よりも優先される（またはプログラムによる検証がない）ためです。その結果、ダイアログは表示されず、検証が成功したかのようにリンクがアプリに直接移動します。
テストの例
アプリリンクの検証が成功するには、特定のインテント フィルタで指定した各ウェブサイトで、アプリリンクの基準を満たすアプリが検証できる必要があります。次の例は、複数のアプリリンクが定義されたマニフェスト構成を示しています。
<application>
<activity android:name=”MainActivity”>
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" />
<data android:scheme="https" />
<data android:host="www.example.com" />
<data android:host="mobile.example.com" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" />
<data android:host="www.example2.com" />
</intent-filter>
</activity>
<activity android:name=”SecondActivity”>
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" />
<data android:host="account.example.com" />
</intent-filter>
</activity>
<activity android:name=”ThirdActivity”>
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="https" />
<data android:host="map.example.com" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="market" />
<data android:host="example.com" />
</intent-filter>
</activity>
</application>
上記のマニフェストで、プラットフォームが検証を試みるホストのリストは次のとおりです。
www.example.com mobile.example.com www.example2.com account.example.com
上記のマニフェストで、プラットフォームが検証を試みないホストのリストは次のとおりです。
map.example.com (it does not have android.intent.category.BROWSABLE) market://example.com (it does not have either an "http" or "https" scheme)
ステートメント リストについて詳しくは、 ステートメント リストの作成をご覧ください。
一般的な実装エラーを修正する
Android アプリリンクを検証できない場合は、次の一般的なエラーを確認してください。このセクションでは、プレースホルダ ドメイン名として example.com を使用します。これらのチェックを実行する場合は、example.com をサーバーの実際のドメイン名に置き換えてください。
- インテント フィルタの設定が正しくない
- アプリが所有していない URL が
<intent-filter>要素に含まれているかどうかを確認します。 - サーバーの設定が正しくない
サーバーの JSON 構成で、SHA 値が正しいことを確認します。
また、
example.com.（末尾にピリオド付き）がexample.comと同じコンテンツを提供することを確認します。- サーバーサイドのリダイレクト
次のようなリダイレクトを設定した場合、システムはアプリに対する Android アプリリンクを検証しません。
http://example.com～https://example.comexample.com～www.example.com
これにより、アプリのセキュリティが保護されます。
- サーバーの堅牢性
サーバーがクライアント アプリに接続できるかどうかを確認します。
- 確認できないリンク
テスト目的で、検証できないリンクを意図的に追加してもかまいません。Android 11 以前では、これらのリンクが原因でシステムがアプリのすべての Android アプリリンクを検証するわけではありません。
- assetlinks.json の署名が正しくない
署名が正しいこと、アプリの署名に使用された署名と一致していることを確認します。よくある間違いは次のとおりです。
- デバッグ証明書でアプリに署名し、
assetlinks.jsonにリリース署名のみを含める。 assetlinks.jsonに小文字の署名を含める。署名は大文字にする必要があります。- Play アプリ署名を使用している場合は、Google が各リリースの署名に使用している署名を使用していることを確認してください。完全な JSON スニペットなど、これらの詳細を確認するには、ウェブサイトの関連付けを宣言する手順をご覧ください。
- デバッグ証明書でアプリに署名し、