Let’s break down the possible gaps in your configuration that might be causing the inconsistent test results:

1. Ensure HTTPS is used for your website #

Google’s Digital Asset Links verification requires your website to use HTTPS (except for localhost testing). Your test URL uses http://(MY_WEBSITE), but if your production site is hosted over HTTPS, make sure you’re testing with the https:// scheme in all tools. Mismatched protocols (HTTP vs HTTPS) will cause verification failures even if the assetlinks.json is correctly deployed.

2. Double-check AndroidManifest.xml configuration #

You didn’t mention this, but it’s critical for App Links to work:

• Add android:autoVerify="true" to your intent filter that handles deep links. This tells Android to automatically verify the App Links association.
• Ensure your <data> tags match your website’s scheme and host exactly. Example:

  <activity android:name=".DeepLinkActivity">
      <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" android:host="yourdomain.com" />
      </intent-filter>
  </activity>
  

Without android:autoVerify="true", the system won’t trigger the verification process, which could explain why some tools don’t detect the permission.

3. Validate assetlinks.json delivery details #

Even if you can access the file in a browser, confirm these details:

• Content-Type header: Use a tool like curl or your browser’s dev tools to check that the response returns application/json as the Content-Type. If IIS’s MIME type configuration isn’t applied correctly (e.g., overridden by a parent config), this can break verification.
• Exact file path: Ensure the file is hosted at https://yourdomain.com/.well-known/assetlinks.json (no extra subdirectories, correct casing for .well-known).
• No syntax errors: Recheck the JSON content for accidental typos—even a missing comma or extra space can invalidate the file. Paste it into a JSON validator to confirm it’s fully valid.

4. Rule out caching issues #

Google’s Digital Asset Links tools often cache verification results. Try:

• Testing in an incognito/private browser window to bypass local cache.
• Waiting 10-15 minutes after deploying changes, as server-side caches might take time to update.

5. Confirm domain consistency #

Make sure the domain you’re testing with matches exactly what’s hosted:

• Avoid mixing www.yourdomain.com and yourdomain.com—these are treated as separate domains. Pick one and use it consistently in your manifest, assetlinks.json, and test tools.
• Ensure there are no redirects (e.g., from HTTP to HTTPS) that might interfere with the verification request. The tool needs to access the assetlinks.json directly without redirects.

6. Verify signature fingerprint alignment #

You mentioned using the SHA256 from Google Play’s App Signing page—this is correct if you’re using App Bundles or Google Play’s app signing service. However:

• If you’re testing a local APK (not downloaded from Google Play), its signature fingerprint will match your upload key, not the Google Play app signing key. This will cause verification to fail for local builds, which could explain inconsistent test results.
• Double-check that you copied the fingerprint correctly—no missing colons, extra spaces, or incorrect casing (SHA256 fingerprints are typically uppercase with colons separating pairs).

7. Re-run verification with correct parameters #

When using the Digital Asset Links Generator/Tester, make sure you input:

• The exact website domain (with https://)
• The correct package name (matches what’s in your manifest and Google Play)
• The SHA256 fingerprint from Google Play’s App Signing page

If all these checks pass, the verification should start working consistently across tools.

内容的提问来源于stack exchange，提问作者Alexander