3 min read

Android App Link Quirks

Verification quirks, manual link overrides, and Chrome vs. Firefox redirect handling
Android App Link Quirks

These are my learnings from my deep dive into android <intent-filter> app links and the /.well-known/assetlinks.json from my time working at Check24 Autoteile. So I was working on just the Carparts/Tires Plugin of the Check24 iOS and Android Apps.

There unfortunately is conflicting information available, I'll try to stick to official info, no AI or random outdated stackoverflow answers.

The device starts an asynchronous verification process that takes ~20 seconds in certain situations:

  • After installation completes
  • After an update completes (my assumption update == installation)
  • Forced verification over adb

From documentation it's unclear if the device checks all links itself or if it uses digitalassetlinks.googleapis.com. I intercepted network traffic and it seems like it actually checks through google servers. But other manufacturers (chinese like huawei) might be doing it differently as they are less googley. On old Android versions < Android 12 (API level 31) a single assetlinks.json fail means all links are marked unverified. Starting with Android 12 (API level 31) it handles each site-link individually, a single link fail only means that specific link isn't marked verified. Almost 70% of users have that version or higher (as of 2025). Breaking App linking at Check24 always was a big deal. If we at Carparts/Tires broke app links due to a downed assetlinks.json, it was seen as breaking them for the other ~50 verticals too (Flights, Insurance, Credit, Hotels, etc). One could argue that the panic we had at Check24 about breaking app linking might be a bit exaggerated, but 30% of devices getting broken app links is still a lot.

Tech-savvy Android users know that we can go into App-Info->Open by default and add unverified links that should be opened in the app.

⚠️ This isn't mentioned in the documentation, but this manual action leads to a different behavior than the automatic verified link addition. Manually added links will ignore any pathPrefix or pathPattern configurations that exist in the AndroidManifest.xml. Our intention is to only allow links with /ul/ in the Manifest. So just reifen.auto.check24.de will open in the browser. Only when /ul/ is added, the link opens in app. Sometimes we actually want the user to stay in the browser, so having control over this is useful! But when the user adds reifen.auto.check24.de manually it will always open it in the app even without /ul/.

This makes testing difficult as developer builds will always show as unverified (also with adb triggered verification) because they're signed with a different key than what's in the assetlinks.json file [no source]. There are some extra conditions like android:autoVerify="true" being present in the Manifest, but I'm leaving out some details. You can check the detailed behavior in the Android Documentation.

Browser behavior

As if that isn't complicated enough I noticed Chrome and Firefox behaving differently.

Case 1: auto.check24.de
Opening auto.check24.de (no /ul/) should stay in the browser, not open the app.
However: the URL returns a 301 redirect to /ul/.

Chrome
Reconstructs the full URL (auto.check24.de/ul/) from context.
That is a valid App Link → opens the app.

Firefox
Evaluates the redirect target as just /ul/ (path-only, no domain).
Just /ul/ doesn't contain a domain and is therefore not recognized as an App Link → stays in the browser.

The behavior of Chrome is the one I would expect.

Case 2: reifen.auto.check24.de
By coincidence, this domain has two chained redirects:
1. 301 → /ul/ (path only)
2. 301 → https://reifen.auto.check24.de/ul/ (full domain)

Chrome
Still opens the app immediately (same behavior as before).
Firefox
First redirect behaves as in the first case, but the second redirect happens to contain the domain so it recognizes the second one as a valid App Link → opens the app.

TL;DR Expect the unexpected. The chaos is upstream.