Your React Native app's recipe App Links open the app from a locally signed release build but open the browser once installed from Google Play; what is the likely cause?

## How Android decides a link is verified An App Link is an `https` intent filter marked `android:autoVerify="true"`. When the app is installed or updated, Android fetches `https://<host>/.well-known/assetlinks.json` for each host in those filters and checks two things against the **installed APK**: - the `package_name` equals the app's package, and - one of the `sha256_cert_fingerprints` equals the SHA-256 fingerprint of the certificate that **signed the installed app**. The second check is what makes App Links trustworthy: another developer can reuse your package name on a sideloaded build, but cannot sign with your key. It is also why the same app can verify in one install and fail in another. The file describes a *signer*, and different installs can have different signers. ## Why Play installs differ Apps on Google Play normally use **Play App Signing**. There are then two keys: | Key | Who holds it | Signs | |---|---|---| | **Upload key** | you, or EAS credentials | the bundle you upload, and builds you sign yourself | | **App signing key** | Google | the APKs Google Play delivers to users | Google strips your upload signature and re-signs with the app signing key. So the fingerprint of a Play-installed app is the **app signing key's**, not the key that signed your local release build. An `assetlinks.json` built from your local keystore, or from `eas credentials -p android`, which shows the fingerprint of the keystore EAS signs with, verifies your own builds and fails for every user who installed from Play. A related variant: debug builds are signed with the debug keystore, so App Links in a debug build only verify if that debug fingerprint is also listed. ## The fix 1. Open Play Console's app signing page and copy the **app signing key certificate** SHA-256 fingerprint (Play Console also offers a ready Digital Asset Links snippet). 2. Add it to `sha256_cert_fingerprints`, keeping the upload or EAS fingerprint if you test locally signed builds against the same domain. The field is an array precisely so several signers can be trusted. 3. Serve the file again over HTTPS, as `application/json`, with no redirect, on **every** host the intent filters name. 4. Re-run verification on a test device and check the result. ## Confirming on a device On Android 12 and later, `pm` exposes the verification state directly: ```bash adb shell pm get-app-links com.example.recipes adb shell pm verify-app-links --re-verify com.example.recipes ``` `get-app-links` lists each host with its state, for example `verified` or a failure state, so you can see which host failed instead of guessing. `verify-app-links --re-verify` asks the system to fetch the files again, which you need after changing `assetlinks.json` because verification otherwise happens at install. To fire a link at the app without a browser, the Expo docs use `adb shell am start -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d "https://..."`. ## Why nobody noticed The failure is silent by design: - On **Android 12+**, a web link that is not verified for any app opens in the **default browser**; the user sees the website and assumes that is normal. - On **older Android versions**, an unverified `https` filter could still surface the app in a chooser dialog, which at least hinted at the problem. - The React Native side cannot help: `Linking.getInitialURL()` only runs if the app is opened, and here it never is. Other causes produce the same symptom and are worth ruling out with `get-app-links`: a host listed in the intent filter that does not serve the file, a redirect on `/.well-known`, or the wrong content type. Since Android 12 verification is tracked per host, so one broken host no longer disables the others; on older versions a single failing host could make the whole app unverified. ## What to take away Treat `assetlinks.json` as part of the release configuration. Whenever the signing setup changes (enabling Play App Signing, rotating the upload key, moving to EAS-managed credentials, adding a flavour with its own package), update the fingerprint list in the same change and verify a store-installed build, not only a local one.