Android developer tools

assetlinks.json generator and validator

Build the assetlinks.json file, intent filter and adb commands for Android App Links, check a file you already have, then ask Google what it reads from your domain.

Fill in your app and the hosts your links use. The file, the intent filter and the test commands update as you type.

App 1

    assetlinks.json

    Upload it, unchanged, to:
      Intent filter for AndroidManifest.xml
      Put it inside the <activity> that opens your links. android:autoVerify="true" is what makes Android check the file.
      Verify on a device with adb
      Generating and validating stay in this tab. Test domain sends the domain, and the package name and SHA-256 fingerprint if you enter them, to Google's Digital Asset Links API. Free to use, no account. More Android developer tools 
      How to set up Android App Links
      1. Get the SHA-256 fingerprint of the certificate that signs the app people install. With Play App Signing that is the app signing key in Play Console, not the upload key on your computer. The keystore and APK fingerprint tool reads it from a keystore or an APK.
      2. Enter the package name and fingerprints above and download assetlinks.json.
      3. Upload it to https://<host>/.well-known/assetlinks.json on every host your links use, served over HTTPS as application/json with a 200 response and no redirect.
      4. Add the intent filter with android:autoVerify="true" to the activity that handles the links, then build and install the app.
      5. Use Test domain to see what Google reads, then run the adb commands to make the device verify and print the result for each host.
      What the validator checks
      • The file is a JSON array of statements, with no byte-order mark, comments, trailing commas or curly quotes, and not an HTML error page saved by mistake.
      • Each statement has a relation array and a target. Android App Links need delegate_permission/common.handle_all_urls; get_login_creds and use_as_origin are recognised too, and anything else is flagged as a likely typo.
      • Package names follow the applicationId rules: two or more dot-separated segments, each starting with a letter.
      • Every entry in sha256_cert_fingerprints is 32 bytes written as upper-case hex pairs separated by colons. A SHA-1 or MD5 fingerprint, a Base64 key hash, lower case, missing colons and the placeholder fingerprint from Google's documentation are each reported, and Fix rewrites the ones that can be converted.
      • Common key mistakes, such as sha256_cert_fingerprint without the s, a relation written as a string, and include statements over plain http.
      • Dynamic rules for Android 15 and later: only the /, #, ? and exclude keys, the right value types, rules that can never run because an earlier catch-all wins, and a second dynamic_app_link_components for the same app.
      Play App Signing and the right fingerprint
      Most App Links failures come down to the fingerprint. When Google Play signs your releases, the app on users' phones carries the app signing certificate, while keytool on your machine shows the upload certificate. Android's documentation says the two usually differ, and that Play Console shows the correct SHA-256, and a ready Digital Asset Links snippet, under Release > Setup > App signing. You can list several fingerprints for one app, so a file can cover the Play build, a debug build and a build you sideload for QA at the same time.
      Debug builds are signed with the debug keystore in ~/.android/debug.keystore, whose fingerprint is different on every computer. If you test App Links with a debug build, add that fingerprint as well, or verification fails even though the release works.
      Test domain: what Google's answer means
      Test domain calls two methods of Google's Digital Asset Links API: statements:list, which returns the app statements Google read from the file, and, when you enter an app, assetlinks:check, which says whether that package and fingerprint are linked. When Google can't use the file it returns an error code, such as a fetch error with the HTTP status, a redirect, the wrong Content-Type or malformed JSON, and the tool explains each one.
      Google caches its answers. The API reports how long, and the result shows it, so a file you just fixed can still fail for a while. The API reads the file from Google's servers, so it also helps to know that a firewall rule, bot protection or a login in front of /.well-known/ can block automated fetchers that a browser gets through.
      www, apex and subdomains
      • Android verifies each host in your intent filters on its own. example.com and www.example.com are two hosts and each needs the file.
      • A redirect breaks verification for the host that redirects, including http to https and apex to www. Serve the file directly on each host.
      • A wildcard host such as *.example.com is checked against the file on example.com.
      • On Android 12 and later each host is verified separately, so one broken host doesn't stop the others. On Android 11 and lower, one host that fails verification stops App Links for all of the app's hosts.
      Private by design
      Privacy
      Generate and Validate run in this browser tab: this tool's code doesn't send your package names, fingerprints or pasted file anywhere. Test domain sends the domain, and the package name and fingerprint only if you fill them in, straight from your browser to Google's Digital Asset Links API. The fields aren't saved in the page address.
      This page also shows Google ads, which can use cookies. Privacy and cookies explains how.
      Link to this tool
      Found it useful? You're welcome to link to it from your README, docs or blog.
      Questions
      Why does my assetlinks.json fail to verify?
      The usual causes are a fingerprint from the wrong key (the upload key instead of Play's app signing key, or a release key while testing a debug build), a lower-case or colon-less fingerprint, a redirect from apex to www or from http to https, the file missing on one of the hosts in your intent filter, or an intent filter without autoVerify. Validate the file here, run Test domain, then re-verify on the device with adb.
      Where do I find the SHA-256 fingerprint for assetlinks.json?
      If Google Play signs your app, copy it from Play Console under Release > Setup > App signing, which also offers a ready snippet. Otherwise run keytool -list -v on your release keystore, run Gradle's signingReport, or open the keystore or APK in the keystore fingerprint tool on this site.
      Does assetlinks.json need to be on www and the bare domain?
      Yes, if your links use both. Android checks every host in your intent filters separately, and it doesn't follow redirects, so example.com and www.example.com each need the file served directly with a 200 response.
      How long does Google cache assetlinks.json?
      Google's API returns a maxAge with each answer, often minutes to an hour, and this tool shows it. Devices verify when the app is installed or updated; to test a change right away, run adb shell pm verify-app-links --re-verify with your package name.
      Can one assetlinks.json list several apps or fingerprints?
      Yes. Add one statement per package, and list every signing certificate that should be trusted in sha256_cert_fingerprints, for example the Play app signing key and your debug key. Several apps can also share one host, each handling its own paths.
      From the same developer
      More Android developer tools
      All 4 Android developer tools 
      Also try: AASA validator