Press enter to begin your search
Filter By:
Categories |
Features
October 30th, 2015
This is part three of a four-part technical guide to deep linking on Android. The previous posts covered URI schemes and Chrome Intents and the next will cover Google Play Referrer.
With the recent release of Android Marshmallow (6.0), Android introduced a new mechanism for opening up the app directly, called App Links. This mechanism is meant to replicate the functionality of Universal Links from iOS 9, where if a normal HTTP/HTTPS link is clicked and the corresponding app is installed, it will open immediately. Here’s the redirect logic of the App Link:
The Android App Link is simply a way to turn your existing website links into app links as well. An example would be: https://imbd.com/title/12345. If IMDB properly configures their website for app links, when IMDB is installed on the phone, it will open up immediately when the link is clicked. If the app is not installed, the web URL will be opened in a browser.
In a few months, after 6.0 becomes more prevalent, it could bypass the standard URI and Chrome intent mechanisms. In the meantime you’ll need to support it alongside all other mechanisms to be sure you handle all of the edge cases– again, Android is extremely fragmented. To learn more, keep reading or request a Branch demo.
There are two steps to configure your service to use app linking:
This is fairly straightforward. You need to tell Android what web site(s) should open your app instead of the site.
You must create a file called assetlinks.json file in the following format:
Note: we’ve gotten App Links to work without changing the default value of “android_app”.
The SHA256 fingerprints of your app’s signing certificate. You will need to use the keytool to generate the fingerprints. From the command line, cd into the java home directory, then cd into the bin folder. Then run the following command:
$ keytool -list -v -keystore my-release-key.keystore
(For help locating the keytool, see this example on Mac or Windows.)
Lastly, the assetlinks.json file must be hosted at /.well-known/assetlinks.json. We setup the one for all Branch integrated apps using our Node+Express link servers. Here’s the code we used:
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 full string of the App Link which triggered the app to open.
Practically, this would be the easiest mechanism to use if everyone were on 6.0+ and you had a website built. Since that won’t happen for another few years, you’ll need to handle the edge cases.
For now, we recommend enabling your website with App Links, but still leveraging your existing deep link mechanisms around the URI scheme and Chrome intents until these are more universal. For example, if a user opens up your site and has the app installed, you want to trigger a Chrome intent or URI scheme if they click a button on your mobile site to launch the app. It appears that App Links do not handle that scenario.
If you don’t have a website, but want to leverage App Links, we’d recommend incorporating Branch Deepviews into your overall product strategy. They are mobile web previews of your app content, automatically generated and hosted by us. Deepviews offers a good alternative for users to view/experience content when they don’t have your app installed, and is a good fallback for Android App Links.
Stay tuned for upcoming episodes of Android deep linking.
Featuring Bnext and OneFootball
Watch Now
Subscribe now for a weekly blog digest containing mobile growth tips, industry updates, and product announcements!