Android アプリリンクは、ウェブサイトの URL を表示できる特別なタイプのディープリンクです。 Android アプリで対応するコンテンツをすぐに開くことができます。 ユーザーにアプリの選択を求めます。Android アプリリンクは、デジタル アセット Links API を使用して信頼関係を確立する アプリがウェブサイトによって承認され、アプリのリンクが 表示されます。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>
ただし、1 つの <intent-filter>
に autoVerify
を含めるだけで十分です。
宣言されている場合があります。これは、そのホストが、マークされていない他のホストでも
各宣言に autoVerify
を
一貫性を保つために <intent-filter>
要素を使用します。これにより
削除またはリファクタリングしても、アプリは
すべてのドメインを登録する必要があります。
ドメイン検証プロセスにはインターネット接続が必要であり、完了までに時間がかかることがあります。このプロセスの効率を高めるために、
Android 12 以降をターゲットとするアプリのドメインを確認する
<intent-filter>
要素内にそのドメインが含まれている場合に限り、
上記のコード スニペットと同じ形式で指定します。
複数のホスト用のアプリリンク機能をサポートする
システムは、アプリの URL インテント フィルタのデータで指定されたホストを検証できる必要があります。 それぞれのウェブドメインでホストされているデジタル アセット リンク ファイルと照合する必要があります。 使用します。検証が失敗した場合は、システムはデフォルトの標準動作になります。 インテントを解決できます。詳しくは、 アプリ コンテンツへのディープリンクを作成する。 ただし、アプリは、アプリの他のインテント フィルタで定義されている URL パターンのデフォルト ハンドラとして検証できます。
注: Android 11(API レベル 30)以前では、 一致するものが見つからない限り、アプリがデフォルト ハンドラとして確認されることはありません。 定義したすべてのホストのデジタル アセット リンク ファイル。 使用します。
たとえば、次のようなインテントのアプリがあるとします。
https://www.example.com
のフィルタのみが検証に合格します
assetlinks.json
ファイルが
https://www.example.com/.well-known/assetlinks.json
、ただし、
https://www.example.net/.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="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>
要素
結合された属性のすべてのバリエーションを考慮して、結合が行われます。たとえば、
上記の 1 つ目のインテント フィルタには、<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
など)を宣言する場合は、
assetlinks.json
ファイルをルートホスト名で公開する必要があります。
(example.com
).たとえば、次のようなインテント フィルタを持つアプリは、
example.com
のサブ名(foo.example.com
など)に対する確認
assetlinks.json
ファイルが
https://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:host="*.example.com" /> </intent-filter> </activity> </application>
同じドメインに関連付けられている複数のアプリを確認する
同じドメインに関連付けられている複数のアプリを公開する場合、各アプリを正常に検証できます。ただし、軽量版とフル版のようにアプリがまったく同じドメインホストとパスを解決できる場合は、直近にインストールされたアプリのみがそのドメインのウェブ インテントを解決できます。
このような場合は、必要なパッケージの公開設定があれば、ユーザーのデバイス上で競合する可能性のあるアプリを確認します。次に、アプリで queryIntentActivities()
を呼び出した結果を含むカスタム チューザ ダイアログを表示します。ユーザーは、ダイアログに表示された一致するアプリのリストから好みのアプリを選択できます。
ウェブサイトの関連付けを宣言する
デジタル アセット リンクの JSON ファイルをウェブサイトで公開して、Android アプリを示す必要があります URL インテントを検証し、アプリの URL インテントを検証します。 JSON ファイルでは、次のフィールドを使用して関連付けられたアプリを識別します。
package_name
: アプリケーション ID アプリのbuild.gradle
ファイルで宣言されている。sha256_cert_fingerprints
: アプリの署名証明書の SHA256 フィンガープリント。 フィンガープリントは Java Keytool で次のコマンドを使用して生成できます。 このフィールドは複数のフィンガープリントに対応しており、 デバッグビルドや製品版ビルドなど、さまざまなバージョンのアプリをテストできます。keytool -list -v -keystore my-release-key.keystore
アプリで Play アプリ署名を使用している場合は、証明書
keytool
をローカルで実行して生成されたフィンガープリントは、 一致するものとはできます。使用しているサービスは、 Google Play Console のデベロッパー アカウントにあるアプリの Play アプリ署名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 つのウェブサイトを複数のアプリに関連付ける
1 つのウェブサイトで、同じ assetlinks.json
内で複数のアプリとの関連付けを宣言できる
表示されます。次のファイルリストは、関連付けを宣言するステートメント ファイルの例を示しています。
2 つのアプリケーションがあり、それぞれ別の
https://www.example.com/.well-known/assetlinks.json
:
[{ "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 の場合:
[{ "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
)。
[{ "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
ファイルは、content-typeapplication/json
で配信されます。assetlinks.json
ファイルは HTTPS 接続でアクセスできる必要があります。 アプリのインテント フィルタで HTTPS がデータスキームとして宣言されているかどうかにかかわらず、assetlinks.json
ファイルは、リダイレクトなしでアクセス可能でなければなりません( 301 または 302 リダイレクト)。- アプリリンクが複数のホストドメインをサポートしている場合は、
各ドメインの
assetlinks.json
ファイル。詳しくは、 アプリリンクをサポート: 構成します。 - マニフェスト ファイルに、 一般のユーザーがアクセスできるもの(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>
要素で定義したドメインのデフォルト ハンドラになっているかどうかを確認します。承認状態をクエリするには、次のいずれかの方法を使用します。
DomainVerificationManager
API(実行時)- コマンドライン プログラム(テスト中)
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);
インテントが呼び出されると、ユーザーには [デフォルトで開く] という設定画面が表示されます。この画面には [対応リンクを開く] というラジオボタンがあります。 必要があります。
ユーザーが [対応リンクを開く] をオンにすると、一連のチェックボックスが表示される [このアプリで開くリンク] で確認できます。ここでユーザーは アプリに関連付けるドメインを選択します。また、 [リンクを追加] を選択してドメインを追加します(図 2 を参照)。ユーザーが追加したドメイン内のリンクを選択すると、そのリンクがアプリで自動的に開きます。
アプリが検証できないドメインをアプリで開く
サードパーティとしてリンクを開くことがアプリの主な機能であって、処理対象ドメインを検証する機能を備えていないこともあります。その場合は、ユーザーがウェブリンクを選択する際に、ファーストパーティ アプリとサードパーティ アプリのどちらかを選択できないことを説明します。ユーザーは、ドメインをサードパーティ アプリに手動で関連付ける必要があります。
さらに、ユーザーが希望する場合はファーストパーティ アプリでリンクを開くことができる、プロキシとして機能するダイアログまたはトランポリン アクティビティの導入を検討します。このようなダイアログまたはトランポリン アクティビティを設定する前に、アプリのウェブ インテント フィルタに一致するファーストパーティ アプリに対してパッケージの公開設定を持つようにアプリを設定します。
アプリリンクをテストする
アプリリンク機能を実装する際は、リンク機能をテストして、 システムがアプリとウェブサイトを関連付け、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.com
example.com
~www.example.com
これにより、アプリのセキュリティが保護されます。
- サーバーの堅牢性
サーバーがクライアント アプリに接続できるかどうかを確認します。
- 確認できないリンク
テスト目的で、検証できないリンクを意図的に追加してもかまいません。維持 Android 11 以前では、これらのリンクが原因で アプリのすべての Android アプリリンクを検証しないように設定します。
- assetlinks.json の署名が正しくない
署名が正しいこと、署名に使用した署名と一致することを確認する 説明します。よくある間違い:
- デバッグ用証明書でアプリに署名し、リリースのみを使用する
assetlinks.json
内の署名。 assetlinks.json
に小文字の署名を含める。署名は 使用します。- Play アプリ署名を使用している場合は、その署名を使用していることを確認してください。 Google が各リリースの署名に使用する名前です。これらの詳細情報は 完全な JSON スニペットを含めます。手順については、 ウェブサイトの関連付けの宣言をご覧ください。
- デバッグ用証明書でアプリに署名し、リリースのみを使用する