Digital Asset Links File: Hosting and Fields

The fields, one by one

The file is a JSON array of statements. A minimal statement for one app looks like this; the fingerprint below is a placeholder in the right format:

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.sportsbook",
      "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 is the relation App Links verification looks for.
• target.namespace: android_app for an app.
• package_name: the application ID in your build, such as com.example.sportsbook.
• sha256_cert_fingerprints: an array, so it can hold several fingerprints, for example the Play signing key and a key used for another release channel.

If one host serves several apps, for example a casino app and a sportsbook app under the same brand, add one statement per app to the same array.

Hosting rules

Two server habits break this on gambling sites more than anywhere else. Geo-blocking rules that answer some requests with a redirect or a block page can catch the verifier, and a content delivery network rule that forces the bare domain to www redirects the file. Exempt /.well-known/ from both. The troubleshooting guide adds one more check: example.com., with a trailing period, should serve the same content as example.com.

Which fingerprints to list

The fingerprint must match the certificate that signed the build on the device. The troubleshooting guide puts it plainly: "If you are using Play App Signing, make sure you're using the signature that Google uses to sign each of your releases." Your upload key is not enough when Google re-signs the app. The same guide lists two quieter faults: a lower-case fingerprint, since "The signature should be in upper case," and a debug-signed build tested against a file that only holds the release fingerprint.

Copy fingerprints from the Play Console or your keystore rather than retyping them, then paste the whole file into the association file linter to catch format slips.

Dynamic rules on Android 15 and later

Android 15 added an optional relation_extensions block that narrows which paths open the app without shipping a new build. It works on Android 15 (API level 35) or later on devices with Google services; Android 14 and earlier ignore it. Place it inside each statement object, next to relation and target.

"relation_extensions": {
  "delegate_permission/common.handle_all_urls": {
    "dynamic_app_link_components": [
      {"/": "/help/*", "exclude": true},
      {"/": "/events/*"},
      {"/": "/bet/*", "?": {"market": "*"}}
    ]
  }
}

• Matcher keys are / for the path, # for the fragment and ? for a dictionary of query parameters; exclude set to true keeps matching links out of the app.
• Wildcards: * matches zero or more characters, ? exactly one, ?* one or more.
• Rules run in order and the first match wins. A link that matches no rule does not open the app, so put exclusions first.
• Rules can only cover hosts already declared in the manifest. They cannot widen it.
• Declare one dynamic_app_link_components object per site, relation and app statement. If any field is malformed or empty, Android discards the dynamic rules and falls back to the manifest.

For a sportsbook, this lets you keep a safer gambling or help path on the web while the rest of the site opens in the app, and change that list between releases. The manifest side of the same setup is in the Android App Links setup guide.

How long changes take

Android 15 and later re-check the file in the background: "Changes can take up to seven days to propagate to all end-user devices due to the system's caching and scheduled re-verification." On Android 14 and lower, "The system does not perform periodic background re-verification," so a device's stored result does not refresh on a schedule. Plan file changes ahead of a campaign, and use the Digital Asset Links API to see what Google reads: Record each host as done in the deep link implementation checklist.

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

How these timings compare with Apple's content delivery network is set out in the comparison of the two association files.