Deep Link Doctor
Home / Developer notes

assetlinks.json has the wrong package name

App Links fail when package_name in assetlinks.json does not match your applicationId. How to find the right package name and cover debug and release builds.

SymptomApp Links verify for one build of the app but not for the build users install.
Likely causeThe package_name in assetlinks.json does not match the application ID of the installed app.
FixSet package_name to the exact applicationId from build.gradle and add a statement for each variant that should open links.

Short answer: package_name must equal the application ID from your build.gradle, exactly. A debug suffix, a flavour suffix or a typo means the statement is for a different app, and verification fails. Check the installed package with adb and update the file.

What is happening

package_name: the field in an assetlinks.json target that names the Android app by its application ID, which Google defines as the value from build.gradle.

Android matches the statement against the installed app. If the package does not match, the statement does not apply, even when the fingerprint and relation are correct.

  • Build variants often have different application IDs, for example com.example.app.debug.
  • adb shell pm get-app-links com.example.app shows no verified domains, and Google's Statement List tester reports no match for your package name.

Why does this happen?

Most mismatches come from build configuration, not typos. A suffix added for one variant is easy to forget when writing the file.

  • Variant suffixes: debug or flavour builds with their own ID, such as com.example.app.debug.
  • Typos: a missing segment or a swapped word in a long ID.
  • Renamed app: the file still carries an old application ID.

How to confirm it

  1. Check the application ID in build.gradle for the variant users install.
  2. Confirm what is on the device: adb shell pm get-app-links com.example.app. If the package is unknown, the ID is different.
  3. Fetch the file: curl -s https://example.com/.well-known/assetlinks.json and compare package_name.
  4. Test the live file and your package name with Google's Statement List tester.

How to fix it

  1. Set package_name to the exact application ID of each build that should open links.
  2. Add a separate statement for each variant with a different application ID.
  3. Pair each package with the fingerprint of the key that signs that variant.
  4. Deploy, then re-verify: adb shell pm verify-app-links --re-verify com.example.app, wait a few minutes, then adb shell pm get-app-links com.example.app.
  5. Test a link: adb shell am start -W -a android.intent.action.VIEW -d "https://example.com/product/1" com.example.app.
[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.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"]
    }
  }
]

Add one statement per package, as shown in the Android App Links setup guide. If the package matches but verification still fails on Play installs, the cause is usually the signing key fingerprint.

FAQ

Common questions

Where do I find the package name for assetlinks.json?

Google says to use the application ID from `build.gradle`. Check the value for the build variant you ship, since suffixes change it.

How can I check what Google reads for my package?

Call the Digital Asset Links API `statements:list` endpoint with your site and the `handle_all_urls` relation. The response lists each target package and fingerprint it found, so you can compare them with your build.

Can my debug and release builds both verify?

Yes, if both are in the file. Add a statement for each application ID, each with the fingerprint of the key that signs it.

What if two apps on a device claim the same domain?

Google says only one app at a time can be associated with a domain on a device, and if two resolve the same host and path, the most recently installed one wins. Keep test builds off devices you use for release checks.

What are UTM parameters?

UTM parameters are tags added to the end of a link, such as utm_source and utm_campaign, that tell analytics tools where a visit came from. They let you see which campaign, channel and ad brought each visitor.

Which UTM parameters are required?

Use utm_source, utm_medium and utm_campaign on every campaign link. utm_term and utm_content are optional and help you compare keywords or ad variants.