App links intent filters in assetlinks.json not working on Android

问题

My app defines the intent filters to handle URL's from my site defined by

<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:host="www.host.com" android:scheme="http"/>
</intent-filter>
<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:host="www.host.com" android:scheme="https"/>
</intent-filter>

The app correctly detects URL's of the correct host but queries the user whether to open them in the app or browser. I tried using the App links verification as specified here: https://developer.android.com/training/app-links/index.html

As seen in my server logs, when installing the app, the device queries /well-known/assetlinks.json and it responds with a 200 status. Testing the digital assets file using the

https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://<domain1>:<port>&relation=delegate_permission/common.handle_all_urls

API and it found no errors.

The SHA256 in the assetlinks.json file was obtained using

keytool -list -v -keystore my-release-key.keystore 

the same .keystore of which the app was signed.

Running adb shell dumpsys package d returns that the link verification status is "ask" meaning that verification failed. Why might verification be failing?

回答1:

For us it was Windows line endings!

Testing with "https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://domain1:port&relation=delegate_permission/common.handle_all_urls" proved invaluable as it gave us an "Could not parse statement list (not valid JSON)" error which led us to the problem.

TIP: It was good to use the 'Save File' button in the Android Studio App Links Assistant instead of copying and pasting as we did - that way it generates the file itself and is guaranteed not to have this issue.

回答2:

For me, it came down to checking all the basics:

1. Verify my assetLinks file is good with this tool: (replace domain1:port with your domain) https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://domain1:port&relation=delegate_permission/common.handle_all_urls
2. Always test with a signed APK
3. Make sure the test device is running Android 6.0 or later (this is the one that bit me because I forgot it - on older versions of android, you always get the user prompt)

回答3:

There are some common pitfalls which you should check twice (I don't say that you did it wrong. It is just a check list):

1. Verify that the assetlinks.json is valid and stored accessible from https://example.com/.well-known/assetlinks.json to do that you need to visit https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site= https://example.com&relation=delegate_permission/common.handle_all_urls, there must be no errors.
2. If you link multiple domains at once, check that all domains are setup correctly as in step 1.
3. Make sure that those <intent-filters> which contain your <data> tags have the attribute android:autoVerify="true".

4. Verify that you have the required <meta-data> tag in your <application> tag:

   <meta-data
       android:name="asset_statements"
       android:resource="@string/asset_statements"/>
   

   The content of the asset_statements string must be:

   <string name="asset_statements" translatable="false">[{\"include\": \"https://example.com/.well-known/assetlinks.json\"}]
   

5. Use for debug also the release signing certificate (don't be scared you cannot upload it accidentally) use this in your build.gradle:

   buildTypes {
       release {
           minifyEnabled true
           proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
           signingConfig signingConfigs.release
       }
       debug {
           debuggable true
           signingConfig signingConfigs.release
       }
   }
   

回答4:

Update

So I resolved my issue. Not sure which one did it (might have been a combination), but this is what I did:

• Uninstalled "Google Play Services for Instant Apps": I had previously tinkered around with Instant Apps, so I thought maybe some old configurations might be sticking around like the debug package name, however this is unlikely.
• Stopped using proxies: Proxies are helpful for debugging network calls, but HTTP/2 might not be fully supported on the tools I'm using.
• Delete intent filter for legacy subdomains: This is the big one. One of my subdomains has been deprecated and is no longer available. In the AndroidManifest, if you have multiple hostnames declared for an activity that contains at least one autoVerify intent filter, each host is checked for the Digital Asset Link JSON file. If autoVerify fails for even one of the hosts, then none of the hosts are auto verified.

Original

When I first faced this issue, it was because my network was blocking calls to Google's servers for verifying the app links.

As OP and other answers have touched on, in general the API call to endpoint:

digitalassetlinks.googleapis.com

must be successful to bypass the chooser dialog. This is the web call the Android system makes, to verify the Digital Asset Link JSON file, and seems to be made upon app install/update. A helpful place to look is the Logcat, searching for items with the text "I/SingleHostAsyncVerifier:". If you see "--> true" at the end of the log, your app

Lately though, these calls have been failing for me due to what appears to be some bug which may have been introduced recently. The device is receiving this response from the API call above:

Error: unavailable: Wrong content type in HTTP response headers while fetching statements from {host}/.well-known/assetlinks.json (which is equivalent to '{host}/.well-known/assetlinks.json'): expected 'Content-Type: application/json' but found text/html [11] while fetching Web statements from {host}./.well-known/assetlinks.json

It's been awhile since I last looked at these requests, so I don't remember what they looked like before. But it seems possible that there may have been some recent update involving App Links or the Android networking framework, where they switched over to protocol buffers for this feature (and forgot to support it in another one).

Another indication that things may have changed, is that the request path today appears different from the ones mentioned in the previous answers:

https://digitalassetlinks.googleapis.com/google.digitalassetlinks.v1.AssetLinks/Check

回答5:

For me, it was the fact that my assetlinks.json file was UTF-8 and contained a byte-order mark (BOM), which is a three-byte magic number at the head of the file that signals the encoding to a consuming program. The BOM is optional, and apparently the Google / Android tools do not like to see it. When it was present, Google's digital asset links verifier (URL below) gave me a "malformed JSON" error.

If you're using Visual Studio, here's how to determine if you have the BOM in your file, and remove it if necessary:

1. Right-click your assetlinks.json file.
2. Choose "Open With..." from the context menu.
3. Choose "Binary Editor" in the "Open With" dialog.
4. Examine the file bytes. If the file starts with EF BB BF, that's the problem.
5. Delete those characters (you can do this via either column) and save the file.
6. Re-upload the file and test it using the Google tools (URLs below) and it should work properly for you.

Here's the URL you can use to check your file (replace example.com with your actual URL):

https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://example.com&relation=delegate_permission/common.handle_all_urls

回答6:

In my case, adb shell dumpsys package d revealed that the packageName was incorrectly configured in assetlinks.json. I had used the package attribute value of my manifest tag in AndroidManifest.xml, but I should have used the android.defaultConfig.packageId value in my build.gradle file.

回答7:

System app selection window in two cases

1) User makes changes to settings related opening links by going to settings > apps > gear icon > opening links > select an app > open supported links > choose prompt every time.

2)Default app is not set by user and auto verify is not enabled in one of the app links supported app

I think in your case auto verify is enabled, so please check user settings.

回答8:

For me, don't change anything of assetlinks.json including trimming blanks and line-breaks.

回答9:

Thanks for all the other answers here, I was able to find my issue. In spite of doing everything right. This was my problem.

• If your project is huge, chances are you have multiple android module dependencies. Check the merged manifest to find all the activities with intent filter(with autoverify = true).

How this can go wrong is simple. If a project has multiple autoverify urls, then the OS tries to verify it all. Even if one fails then the OS fails the verification of every URL.

Open the manifest file in your main app module, then choose the Merged Manifest option from the bottom tab. Now check the Manifest sources(list) on the right and manually look up manifest files of every library project.

In my case, a third-party library's auto verify flag was enabled. My two-day search comes to an end. Good luck to you.

来源：https://stackoverflow.com/questions/35518429/app-links-intent-filters-in-assetlinks-json-not-working-on-android