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

前端 未结 12 1877
时光取名叫无心
时光取名叫无心 2020-12-02 17:12

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


  

        
相关标签:
12条回答
  • 2020-12-02 17:42

    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)
    0 讨论(0)
  • 2020-12-02 17:44

    In our case we had 2 intent filters with applinks in our manifest: one with autoVerify="true" and one without.

    So the verifier tried to verify domains for the 2nd intent filter and failed, and treated all our applinks as "not verified". You can find more details in this question.

    You have to make sure every applink can be verified (which means adding assetlinks.json for every domain to be verified).

    0 讨论(0)
  • 2020-12-02 17:48

    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.

    0 讨论(0)
  • 2020-12-02 17:51

    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.

    0 讨论(0)
  • 2020-12-02 17:52

    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

    0 讨论(0)
  • 2020-12-02 17:52

    I'm sure this doesn't answer the original question, as I think it pre-dates Android App Bundles, but the thing that was ultimately causing a failure for me was that I'd enabled Google Play Console re-signing of the app (required for AABs) and therefore the SHA-256 fingerprint I was getting from keytool did not match the digital signature of the downloaded app.

    Updating my assetlinks.json with the fingerprints from the console solved it.

    0 讨论(0)
提交回复
热议问题