AndroidAndroid Deep LinkingDeep LinkingGoogleTechnical

Technical Guide to Android Chrome Intents

By October 28, 2015 10 Comments

This is part two of a four-part technical guide to deep linking on Android. The previous post covered URI schemes and the next two will cover Android App Links and Google Play Referrer.

Deep linking on Android

Android Deep Link Protocols: The Neverending Story

Deep linking on Android is incredibly complicated for most developers to adopt because there are so many edge cases. Branch links wrap and standardize all of this complexity so you don’t need to worry about it. We highly recommend using our tools instead of trying to rebuild them from scratch, since we give them all away for free.

To learn more, keep reading or request a Branch demo

Deep Linking with Chrome Intents

Every browser on the Android platform accepts the URI scheme mechanism described in the first post, except Chrome. We believe this is because the Chrome team is very siloed from the rest of the organization and given the freedom to implement things as they see fit. Unfortunately for you, the developer, this means you have to add special handling for the Chrome browser.

Instead of assigning window.location or an iframe.src to the URI scheme, in Chrome, you’ll need to use their intent string as defined in this document. While it adds complexity, the Chrome intent is actually a powerful tool since it automatically handles the case of the app not being installed. Here’s the redirect logic baked into the Chrome intent:

  • -Open app via URI scheme if installed
  • -Fall back to Play Store page if not installed
  • -[Optional] Specify a URL to fall back to, instead of Play Store if not installed

This means that if you use the Chrome intent, you do not need to handle the case of the app not being installed like you do with the URI scheme.

Requirements for Chrome Intents

  • Clicked from Android Chrome browser only
  • Some Galaxy (S4, S5 only) and Note (Note 2) Android default browsers require it

Configuring Chrome Intents

Configuring your app for a Chrome intent is the same as configuring for a URI scheme, since Chrome uses it under the hood. You need to pick an Activity within your app that you’d like to open when the URI scheme is triggered and register an intent filter for it. Add the following code within the <activity /> tag within your manifest that corresponds to the Activity you want to open.

You can change your_uri_scheme to the URI scheme that you’d like. Ideally, you want this to be unique. If it overlaps with another app’s URI scheme, the user will see an Android chooser when clicking on the link. You see this often when you have multiple browsers installed, as they all register for the HTTP URI.

Handling in the app

To handle the deep link in the app, you simply need to grab the intent data string in the Activity that was opened via the click. You can do it like so:

Unfortunately, from here, you’ll need to do string parsing to read the values appended via the path variable described below.

Practical use for Chrome Intents

In Chrome, you cannot use the basic URI scheme to open up the app; instead you will need to issue the formatted Chrome intent string. Here’s the structure, with the variable stuff that you need to specify in bold:

intent://<optional path>#Intent;scheme=<URI scheme>;package=<package>;S.browser_fallback_url=<optional encoded fallback URL>

Here are the variables you can use for the string:

URI scheme [required]: This is the scheme that was configured above. Eg. Pinterest

App package name [required]: This is the package name of the app, as configured for the project.

URI path [optional]: This is an optional string to add which allows you to customize the path. For example, let’s say you wanted to route to pinterest://cats/1234. ‘cats/1234’ would be the URI path. You could then insert ‘cats/1234’ into the path section of the intent string. If not, leave empty. 

Fallback URL [optional]: This is an optional field where you can specify a URL encoded website URL to fallback to if the app is not installed. The default option if not specified is to open the Play Store app page. If you don’t use this variable, just remove the whole ‘S.browser_fallback_url=’ part of the intent string.


Here’s an example completed one that opens up our Branch test app and falls back to our Play Store page:


To use the intent system, you should configure your website host to detect what kind of browser the link is clicked from and use an intent string when it’s the Chrome browser. Ideally, from your web host, on request from the Chrome browser, you should issue a 3XX series redirect back to the browser with the completed intent string. Here’s an example of how we do it from the Branch node app:

Get started below to have Branch handle all of these deep linking use cases for you.

Branch is a mobile linking platform providing unified mobile experiences and measurement for more than 50,000 mobile apps, including Airbnb, Ticketmaster, Reddit, Tinder and Amazon. Branch’s linking platform can help you grow your mobile app through features like deep linking, sharing, referrals, mobile banners and interstitials, custom app onboarding, and unified attribution across platforms and channels. Learn more about Branch or contact sales today.
  • imri

    is there any updates regarding the chrome intents on android? is it still an issue?

    • Alex Austin

      Hey @disqus_2SUIBbmmCF:disqus – Thanks for the question. The issue you’re referring to is the one we filed a while back. The good news is that we’ve got confirmation that it’s resolved in the Chrome beta version (available in the Play Store), which means the next version bump of the Chrome app will resolve it. Huzzah!

  • jasonchartley

    “backed into the Chrome intent” I think should read “baked”.

    • Alex Austin

      Updated! Thanks much

  • Sergey

    Thank you guys!

  • jotte

    Are you saying that my app cannot catch a specific web address that is entered manually in the Chrome browser under Android?! That would be just super-weird. (I can’t seem to get it to work)

    • jotte

      Confirmed it now – intents work as documented with Firefox, but NOT with Google’s own browser Chrome?! How messed up is THAT?

      • Alex Bauer

        This is a known wontfix bug in Chrome 40+ (see the Chromium project ticket here for the full story).

        Essentially, the Chrome team feels that if a user actually types something into the address bar, no redirect should ever happen. As you’ve discovered, this is counter to behavior in all other browsers.

        Fortunately it’s unlikely a user would actually type an intent:// URI by hand. If you wrap the URL inside a link on a webpage, or offer a link to another page and then issue a redirect of some kind (so that you can detect the user agent and not show a ‘broken’ intent:// link to users on other browsers), it should work correctly.

        • jotte

          Thanks for replying!

          I can only say that I believe the Chrome team is thoroughly mistaken. For us it makes a lot of sense providing a simple “getting started” address on physical signs, for on-site services. We let this address lead the user to Google Play or AppStore, depending on what UserAgent (browser&OS) that is used (and a couple more cases). Our app should for sure catch this URL, because it does not make sense to go to Google Play or AppStore if the app is already installed. We have many thousand users. (yes, a very similar case to the one described in the linked page)

          The intent: stuff is way-complicated compared to the simplicity of just adding intent-filters in the app manifest (as documented). I have yet to figure out a way to make intent: work, having added auto-verify in the Manifest and a .well-known/assetlinks file on our completely good HTTPS server, but no luck yet. Using intent: is of course also error prone, having to detect the Chrome browser specifically – in whatever way that that is done, it can very easily break when new browser variants and versions appear. i thought we had left that kind of error-prone stuff behind us years ago?

          What is “omnibox”? And where can I find up-to-date documentation that describes working solutions? I find lots of (old) non-working solutions.

          • Alex Bauer

            Hi @disqus_WXzUKKHZhD:disqus, all of these edge cases are actually the reason we built Branch! I’d definitely recommend giving us a look — it’s free, and you can find the Android SDK integration guide here:

Request Demo Create Links