Deep links are how a tap in an email, an ad, a text in a chat app, or a search result lands a user on the right screen inside your Android app. When they break, users end up on a generic home screen or in the browser, and the campaign or onboarding flow behind that link quietly loses people. This guide covers how to test deep links and verified Android App Links. It also shows where a real physical device adds coverage on top of an emulator.
Deep links vs verified App Links
Android supports two related mechanisms:
- Deep links use intent filters to route a URI, such as a custom scheme or an https URL, into your app. If more than one app can handle the link, Android may show a chooser.
- Android App Links are https links your app has verified ownership of. You do this by declaring autoVerify in the manifest and hosting a Digital Asset Links file at /.well-known/assetlinks.json on your domain. Once a link is verified, Android opens it directly in your app with no chooser.
Most real bugs show up in the verification step and in how different source apps hand the link off.
What an emulator handles well
Be honest about this part: an emulator is a good tool for a lot of deep link work. You can fire intents, check that each URI pattern reaches the right activity, and unit test your routing logic quickly. For early development that is often enough.
Where a real device adds coverage
- Real source apps. Links behave differently depending on where they are tapped: Chrome, Gmail, a social app in-app browser, or a QR code scanner. A real Pixel with the actual apps installed from Google Play shows you the handoff your users really get.
- Production Google Play services. On recent Android versions, App Link verification runs through system components that update in the background. A consumer Pixel runs the same release builds your users have, not an emulator system image.
- Real network path. Verification fetches your assetlinks.json over the network. Testing on a real US carrier connection shows how your CDN, redirects, and any geo-based routing respond to a normal US mobile user.
- Install and update flows. Verification state can change when an app is installed, updated, or cleared. Walking through these on real hardware catches links that silently fall back to the browser.
A practical QA checklist
- Confirm assetlinks.json is served over https with a 200 response, the correct content type, and no redirects.
- Check that the SHA-256 fingerprint in the file matches your release signing key, including the Play App Signing key if you use it.
- Install the release build and check whether links open directly in the app or fall back to the browser.
- Tap the same link from Chrome, Gmail, and at least one in-app browser.
- Test cold start versus app already running, and confirm the correct screen and back stack.
- Test logged-out users, and make sure the destination survives the login redirect.
- Update the app and repeat to confirm verification persists.
Scope to keep in mind
A Google Pixel represents stock Android behavior. Some manufacturers change default browsers and link handling, so a full release matrix may still include other brands. For a clean reference baseline on real US hardware, a dedicated Pixel you control from your browser is a fast way to check your link flows before every release. Each DistrictDroid rental is a dedicated device that is reset between customers, so every test cycle starts from a known state.
DistrictDroid rents real US Android phones with full browser access and a real US SIM, from $30/day or $150/month. Crypto accepted.