How Android App Links Work
Android App Links are the platform's standard for creating verified associations between web URLs and native apps. When a user taps an App Link, Android opens the associated app directly without displaying a disambiguation dialog, the "Open with..." prompt that asks users to choose between the browser and one or more apps. This seamless behavior is possible because Android verifies that your app legitimately owns the domain through a cryptographic handshake.
The verification relies on Digital Asset Links, a protocol that uses a JSON file hosted on your domain to declare the relationship between your website and your app. Android fetches this file during app installation and periodically re-verifies it. The file contains your app's package name and the SHA-256 fingerprint of your signing certificate, creating a chain of trust that prevents other apps from intercepting your URLs.
When verification succeeds, Android designates your app as the default handler for the specified URL patterns. Tapping any matching link opens your app instantly. When verification fails, or when the app is not installed, the URL opens in the user's default browser. This fallback behavior ensures links always work, even if the app experience is not available.
Setting Up Digital Asset Links
The Digital Asset Links file is the cornerstone of App Links verification. It must be hosted at /.well-known/assetlinks.json on your domain, served over HTTPS, accessible without redirects, and return a Content-Type of application/json. The file contains an array of statement objects, each declaring a relationship between your domain and an app.
Each statement includes a relation array specifying the type of association (for App Links, this is delegate_permission/common.handle_all_urls), and a target object containing your app's package name and SHA-256 certificate fingerprints. If you use multiple signing certificates, for example, a debug certificate and a release certificate, include all fingerprints in the array.
On the app side, you need to add intent filters to your AndroidManifest.xml with android:autoVerify="true". Each intent filter declares the scheme (https), host (your domain), and path patterns your app handles. Android will attempt to verify every domain declared in intent filters that have autoVerify set to true. If verification fails for any declared domain, it may affect the verification status of all domains, so only declare domains you have properly configured.
Google provides a Digital Asset Links testing API and the App Links Assistant in Android Studio to validate your setup. Always test with a release-signed build on a physical device, debug builds use a different signing certificate that will not match your production assetlinks.json configuration.
App Links vs Universal Links
App Links and Universal Links solve the same fundamental problem on their respective platforms: creating verified, secure associations between web URLs and native apps. While the concepts are parallel, the implementation details and platform behaviors differ in ways that matter for cross-platform growth teams.
Both systems use a JSON verification file hosted on your domain. Apple uses apple-app-site-association while Android uses assetlinks.json. Both require HTTPS and prohibit redirects. However, Apple's AASA file supports more complex path matching patterns including wildcards and exclusions, while Android's intent filters handle path matching in the manifest rather than the verification file.
A significant behavioral difference is how each platform handles user override. On iOS, a user who long-presses a Universal Link and chooses "Open in Safari" effectively disables Universal Links for that domain until they manually re-enable it. On Android, users can manage default app associations in system settings, and Android 12 introduced more granular domain verification controls that give users explicit approval over which domains an app can handle.
For growth teams running cross-platform campaigns, the practical implication is that you need platform-specific testing and monitoring. A link that works perfectly on iOS might fail on Android due to a mismatched certificate fingerprint, or vice versa. Unified link management tools that abstract these platform differences become essential at scale.
App Links in Growth Campaigns
App Links play a critical role in Android growth campaigns by eliminating the friction of disambiguation dialogs. When a user taps an ad or a shared link and sees a prompt asking which app to use, conversion rates drop significantly. Every additional step between click and content is a point where users abandon the journey. Verified App Links remove that step entirely.
For re-engagement campaigns, App Links ensure that push notifications, emails, and retargeting ads route users directly into the app without interruption. The user taps, the app opens, and they land on the intended content. This is particularly important for time-sensitive campaigns like flash sales or limited-time offers where any delay reduces urgency and conversion.
Linkrunner handles the complexity of App Links alongside Universal Links through a single smart link that works across both platforms. When a user taps a Linkrunner link on Android, the system routes through verified App Links when the app is installed, ensuring instant app opens without disambiguation. Attribution parameters persist through the entire flow, giving your team accurate campaign data. For new users without the app, the link routes through the appropriate install flow while preserving the deep link payload for post-install delivery.
Debugging and Monitoring App Links
Debugging App Links requires a systematic approach because failures are often silent, the link simply opens in the browser instead of the app, and there is no error message to guide you. Start by verifying your Digital Asset Links file using Google's testing tool at https://digitalassetlinks.googleapis.com/v1/statements:list. Pass your domain and package name to confirm the verification status.
On the device, you can check verification status using ADB commands. The command adb shell pm get-app-links shows the verification state for all domains associated with your app. Look for the verified status, if you see ask or never, verification has failed for that domain. On Android 12 and later, you can also manually trigger re-verification using adb shell pm verify-app-links.
Common failure points include serving the assetlinks.json file behind a CDN that adds redirects, using a certificate fingerprint from the wrong keystore, or having a mismatch between the package name in the manifest and the asset links file. Another subtle issue is that some hosting providers serve the file with incorrect headers or add a BOM (byte order mark) to the JSON file, which breaks parsing. Always validate the raw response using curl -v to inspect headers and content before assuming the file is correct.
Monitor your App Links performance in production by tracking the ratio of app opens to browser fallbacks. A sudden increase in browser opens for a campaign targeting existing users signals a verification problem that needs immediate attention.
