You tap a YouTube, Reddit, shopping, banking, or news link and expect the installed app to open. Instead, Android launches Chrome. On another phone, the same URL opens directly in the app. On a third device, Android asks which app you want to use every time.
This behavior is not controlled by one “open links in apps” switch. Android uses several layers: the app’s intent filters, website verification, the app’s signing identity, the domain’s assetlinks.json file, user defaults, and—on newer Android versions—dynamic App Link rules.
Android has more than one kind of deep link
Android’s intent system lets apps declare that they can handle specific links. That broad category is called deep linking.
But Android App Links are a special, stronger form of deep linking. They use normal HTTP or HTTPS website URLs and add domain verification so Android can confirm that the website actually authorizes the app to open those links.
That verification is the reason a properly configured App Link can open directly in the app without asking the user which app to choose.
What makes an Android App Link “verified”
There are two sides to the relationship.
The app declares which website URLs it wants to handle in its Android manifest. The website publishes a Digital Asset Links file at:
https://example.com/.well-known/assetlinks.json
That file identifies the Android package and the signing-certificate fingerprint authorized for the domain.
Android checks the relationship. If the app and website agree, the domain can become verified for that app.
Why an app can be installed but its website still opens in Chrome
Installation and App Link verification are separate processes.
The APK can install perfectly while link verification fails because:
- the website has no
assetlinks.jsonfile; - the file is invalid JSON;
- the file redirects instead of being served directly;
- the package name is wrong;
- the signing fingerprint does not match the installed release;
- the app did not request verification for that host;
- the URL path falls outside the app’s declared or dynamic rules.
None of those problems makes the APK itself uninstallable.
The signing key can break link verification even when the package name matches
Android App Links rely on the app’s signing certificate as part of the trusted website-to-app relationship.
If you install a differently signed build with the same-looking package identity, the fingerprint published by the website may no longer match.
This is another reason APKApps.cloud’s signature mismatch guide matters beyond updates. Signing identity affects trust relationships outside the installer too.
Google Play App Signing changes which fingerprint developers must publish
Developers using Play App Signing need to use the fingerprint corresponding to the key Google uses to sign the distributed app—not simply whichever local development keystore they happen to have.
Android’s App Links FAQ specifically points developers to the Play Console app-signing key certificate as the reliable source for the production SHA-256 fingerprint.
If the website lists only a debug or upload-key fingerprint, the production app may install but fail domain verification.
Why the phone may ask “Open with?” instead of opening directly
Ordinary deep links can be claimed by multiple apps.
If Android cannot establish a verified association for one app, it may show a disambiguation dialog so the user decides which handler should receive the link.
Verified App Links are designed to avoid that ambiguity for website URLs owned by the app developer.
Why a link can open in the wrong app
Several apps may declare similar URL patterns.
A browser, shopping app, social app, or third-party client can all express interest in a link. If a verified relationship is missing or user defaults were changed, Android may route the link somewhere you did not expect.
The wrong-app problem therefore is not always “Android ignored my choice.” Sometimes the operating system is resolving multiple valid handlers under the rules it currently has.
User choices can override part of the automatic behavior
Android settings usually expose an “Open by default,” “Open supported links,” or similar screen for installed apps. Wording varies by manufacturer and Android version.
That screen lets users inspect or change whether supported links should open in the app.
Before reinstalling anything, check the app’s default-link settings. A previous “always open in browser” choice or disabled supported-link setting can explain the behavior.
Clearing defaults is different from clearing app data
If the issue is only link routing, you usually do not need to erase the app’s entire storage.
Clearing or changing default-link handling is a much narrower action than clearing app data.
APKApps.cloud’s App Cache vs App Data guide explains why destructive resets should not be the first troubleshooting step.
Why reinstalling can sometimes appear to fix App Links
Android performs verification as part of the app/domain relationship. Reinstalling can trigger fresh state and verification attempts.
But if the website configuration itself is wrong, reinstalling only repeats the same failure.
A temporary fix after reinstall can also hide the real issue if the website’s Digital Asset Links file was changed at roughly the same time.
Android 15 added Dynamic App Links
Starting with Android 15, developers can refine App Link routing through server-side dynamic rules in the website’s assetlinks.json file.
That lets a developer change which paths, query parameters, or fragments should open in the app without shipping a new APK every time.
This is useful, but it also introduces another reason two URLs on the same domain may behave differently.
A domain can be verified while one particular URL still opens in the browser
Dynamic rules can exclude certain paths or query patterns.
For example:
example.com/products/123might open in the app;example.com/help/returnsmight intentionally stay in the browser;- a campaign URL with a specific query parameter might be excluded.
So “the domain is verified” does not guarantee every URL under that domain must open the app.
Dynamic rules cannot expand beyond the app’s manifest scope
Android’s documentation is explicit about this.
The app manifest defines the broadest allowed scope. Server-side Dynamic App Link rules can narrow or refine it, but they cannot magically add a completely unrelated domain or path outside that static scope.
If the developer made the manifest too narrow, changing the website file alone cannot fully solve the problem.
Why redirect links often behave differently
Many email, advertising, affiliate, and analytics links do not point directly to the final website.
You may tap:
tracker.example.net/click?id=123
which then redirects to:
shop.example.com/product/123
Android initially resolves the URL you actually tapped. If the first domain is not verified to the app, the browser may open before the final destination appears.
Short links add another domain to the chain
A branded shortener or generic short-link service can create the same effect.
The final site may be a valid App Link, but the short-link domain is a different host with its own association requirements.
If “full links open correctly but shortened links stay in Chrome,” the redirect domain is an important clue.
Why links from some apps behave differently from links typed into the browser
Where the link originates can matter.
A messaging app may launch a normal Android VIEW intent. A browser may keep navigation inside its own tab depending on the interaction. An in-app browser may intercept the URL. Some apps deliberately prevent leaving their embedded web view.
That means testing from only one source can mislead you.
A good user test uses the exact same URL from different places
Try the identical HTTPS URL from:
- a plain text message;
- a notes app;
- Google search results;
- the browser address bar;
- another app that normally hands links to Android.
If only one source behaves differently, that source may be intercepting the link.
Why sideloaded builds can behave differently from the Play version
A sideloaded APK may use a different signing key, package variant, build type, or domain configuration from the official Play release.
Even when the UI looks identical, the website may not authorize that signing fingerprint for App Links.
So “the Play version opens links but this APK does not” can be an identity/configuration issue rather than an Android bug.
Split APKs rarely cause App Link verification by themselves
App Link declarations normally live in the app’s installed package metadata. Missing required split packages can create broader installation or runtime problems, but an App Link opening in Chrome should first be investigated as a domain/intent/default issue.
Do not jump immediately to downloading a different APK set unless other symptoms point there.
Worked example: banking link opens in Chrome after reinstall
You reinstall a banking app from an unofficial source. Login works, but links from transaction emails open the bank website in Chrome.
The unofficial build has the same visible app name but a different signing certificate. The bank’s assetlinks.json file authorizes only the official production signing key.
The app can run, but the trusted web-to-app relationship does not match.
Worked example: only promotional links fail
Normal product URLs open the shopping app correctly. Links from promotional emails open a browser first.
The promotional links use a marketing redirect domain before reaching the product page.
The main store domain is verified. The tracking domain is not. The different behavior now makes sense.
Worked example: Android 15 opens some paths in app and others on web
A news app opens article URLs directly but keeps subscription and help pages in Chrome.
That can be intentional Dynamic App Link configuration. The developer may have excluded account-management paths because they work better on the website.
User troubleshooting order
- Confirm the app is actually installed and current.
- Open the app’s “Open by default” or supported-links settings.
- Check whether supported-link handling is enabled.
- Test the same direct HTTPS URL from more than one source.
- Remove tracking or short-link wrappers when possible and test the final URL.
- If using a sideloaded build, compare it with the official release.
- Avoid clearing all app data unless the problem extends beyond link routing.
What only the developer or website owner can fix
If the domain verification file is wrong, users cannot repair it from their phones.
The developer/site owner must fix:
- manifest intent filters;
android:autoVerifyconfiguration;- the server’s
assetlinks.jsonfile; - package name and SHA-256 fingerprint entries;
- redirect and HTTPS behavior;
- Dynamic App Link rules.
Do not confuse link routing with app availability
An app can be unavailable in Google Play and still have valid App Links on a device where it is installed. An app can also be available in Play but have broken App Link configuration.
APKApps.cloud’s Why an App Is Not Available for Your Device covers store compatibility. App Links are a different layer.
The mental model that makes link problems easier
Think of a tapped link as a routing decision:
- What URL did you actually tap?
- Which apps claim they can handle it?
- Is one app verified by the website?
- Did the user disable or change default handling?
- Do Android 15 dynamic rules include or exclude this path?
- Is an intermediate app or redirect intercepting the URL?
Once you separate those questions, “Android keeps opening Chrome” stops being a mysterious browser problem.