Browser does not implement Android App Links

[Zeluok]

App Links are used to redirect to apps using http requests. Apps can use this to provide services, including authentication.

Although there are instances where implementing this functionality is not preferred, it can be very useful and part of an application workflow's critical path.

At the moment, this functionality is not implemented by the browser, but is implemented by others like firefox/mull or monocles.

I like the approach taken by firefox/mull, to have a setting for this (i.e. 'open links in apps' - though it should probably be named 'allow opening app links').

Example, broken authentication:

• OSRS app, for RS authentication, redirects to the browser using an intent. On providing account details it fails to load the address com.jagex.mobilesdk.android.osrs:/oauth2redirect?code=...&state=...

[plateaukao]

@Zeluok could you provide a more specific usage or reproduce step, that I can take as an case to see how to support it? I am not familiar with OSRS.

[Zeluok]

I've built and released a sample app, forked from an old facebook repo, here. ~Perhaps~ this can assist with testing.

I observed however, that facebook's sample app ~produces an app link url http://primenumber.parseapp.com/definition which~ differs to the url scheme created by the OSRS app. EDIT: The sample in the repo is not configured, I'll release a v1.1 that can be used for testing

Neither are handled though.

Usage workflow in OSRS (old school runescape ~110Mb) app:

1. User launches app
2. User clicks on 'Continue with RuneScape account'
3. User is redirected to a browser app with url https://auth.jagex.com/shield/oauth/authorize?redirect_url=com.jagex.mobilesdk.android.osrs%3A%2Foauth2redirect&client_id=com_jagex_auth_moobile_android_osrs&response_type=code&state=...&nonce=...&code_challenge=...&code_challenge_method=S256
4. User completes a user/pass form and clicks on the submit button
5. Submit button redirects back to app with url com.jagex.mobilesdk.android.osrs:/oauth2redirect?code=...&state=...
6. App registers oauth logon and continues to game

Please let me know if I can provide other info or any logs to assist.

[plateaukao]

From Android SDK 30, it has restrictions on apps to query whether a uri scheme can be resolved by other apps (https://support.google.com/googleplay/android-developer/answer/10158779?hl=en).

I could try to support links like com.jagex.mobilesdk.android.osrs:/oauth2redirect?code=...&state=... by directly asking system to handle it. But for app link like http://primenumber.parseapp.com/definition, I have no way to tell whether it can be handled by other apps or not, since it's just as other normal urls.

Although theoretically, I could add QUERY_ALL_PACKAGES to ask system show me all possible apps; however, it has more strict release rules and actions to take on Google Play Store, and I don't want to jeopardize the release of EinkBro on Google Play Store.

Also, I tried the steps you described above. At step 3, in my (normal) phone, it does not redirect to a browser app, instead, it shows an in-app webview (chrometab?) May I know what device you are installing EinkBro? Maybe if you install Chrome, then the OSRS will use chrome's chrometab instead, then it won't have issues with EinkBro.

[Zeluok]

I tried to mess around with the samples and got it to work with fernix internals (on mull - a firefox port without significant code changes). There are a few steps to prepare for testing, and a few things to note. I'll release a few versions that can be tested with tomorrow afternoon (AEST).

My device isn't really a 'normal' device and I can't use the normal one for testing at the moment. Though it's got near-stock Android 10 functionality on it at the moment. I'll have to test again with a normal device tomorrow.

There's 2 android apps in the sample repo I shared: a test app, and an 'app link opener' app. I haven't spent much time on the link opener app, and it's not working perfectly for me. I have succeeded in reproducing the osrs app link functionality with the test app though and can confirm it works with mull/firefox and monocles.

How the test app works:

• Based on a great answer on SO, we can firstly disregard some of the commentary related to meta tags (e.g "al:android:url") from the facebook repo.
• The intent requires a data intent-filter on the activity, defined in the manifest, with a defined android:scheme and android:host. This scheme can be, for example, http or some custom.scheme. The host can be, for example, facebook.com or some custom.domain.
• When a browser that supports opening app links gets a webpage with a href/link to http://facebook.com or custom.scheme://custom.domain (based on above), it'll open in the app instead. (ElinkBro does not do this).
• This will not work - and is not expected to work - if it's provided in the URL/search bar, where it will trigger a standard DNS lookup instead (or a search when the scheme is not supported for standard use).
• So, I used a simple python3 -m http.server serving a test.html to test

Good pick up about android 30, though that link says "Permitted uses include device search, antivirus apps, file managers, and browsers." It appears to be expected for being able to handle deep links, but I'm not sure about the implementation yet. The repo does provide hints for an implementation here, I haven't looked into it deeply yet though.

In my testing I used a custom scheme and also tested by trying to replace http://google.com/definition. The custom scheme and google override both worked with mull/firefox.

Again, I'll have to share code tomorrow since it's late, but ty for looking into this!

[plateaukao]

When a browser that supports opening app links gets a webpage with a href/link to http://facebook.com or custom.scheme://custom.domain (based on above), it'll open in the app instead. (ElinkBro does not do this).

As I said, I could try to support custom.scheme://custom.domain part, since it's not normal http nor https. As for normal urls that are registered with app link (e.g., https://facebook.com), I could not know it's actually an app link url, so I can't pass it to system, and ask system to open it for me; I'll just treat it as normal url.

In your provided link above (https://github.com/Zeluok/android-applinks-samples/blob/master/AppLinkPasteboardSample/src/main/java/org/applinks/AppLinkDetail.java#L72), it's from facebook SDK, and the real implementation actually tries to connect the url, and check if it has applink related information. I don't think it's a good way to handle applink.

[plateaukao]

Also, android app link setup is between the app's related website, android system, and the app (https://developer.android.com/training/app-links). As a browser app, unless android system provides some API for me to know whether a normal http/https url is an app link url, I could not know it in advance, and ask android system to handle it for me. I'll just treat all http/https url as normal url, and use WebView to load these urls.

[Zeluok]

I'll try to find more info from the firefox implementation & release some test code today.

[Zeluok]

Ok the current Firefox implementation is here and called by here. Tests here show handling http schemes and this is a list of all the use cases that are tested.

See moz-android/#2974 and moz-android/#2976 for the workflow. This commit was easiest to read for me. Particularly, see AppLinksUseCases.GetAppLinkRedirect.

Overall firefox has rules like:

• require QUERY_ALL_PACKAGES
• ignore testing for applink if user prefs/setting says to ignore (default), unless it's in the app's safelist ("about", "data", "file", "ftp", "http", "https", "moz-extension", "moz-safe-about", "resource", "view-source", "ws", "wss", "blob")
• ignore testing for applink if same domain (example.com, www.example.com and m.example.com are considered the same domain)
• ignore testing for applink if triggered by a non-human interaction (e.g. automatic redirection)
• replace with a marketplace intent if is a package intent that isn't installed (context.packageManager.isPackageInstalled)
• block applink if it is one of the block list ("jar", "file", "javascript", "data", "about")
• discover http(s) 'browsable' apps by using an unlikely-to-be-used-by-applink address (i.e. https://${UUID.randomUUID()}.net) to exclude actual 'browsers' from resolving activities

[Zeluok]

Reconfigured and released sample app for testing, refer to release notes for usage.

However, I didn't change much code so it's not very robust... If you create a detailed activity intent via the definition activity before creating a detailed activity intent from your browser, it won't read/parse the URL parameter.

Just close the detailed activity from the multitasking menu before using the browser applinks if you want to test passing URL parameters.

[Zeluok]

I've found a way to get around the URLs with HTTP and HTTPS - ElinkBro can sidestep this by using its 'open link with' function:

As I said, I could try to support custom.scheme://custom.domain part

Absolutely happy with only this - because HTTP and HTTPS can be handled by users using 'open link with' if they need the functionality. Please however, make the custom scheme applinks optional with a preference for 'allow opening app links' in settings.

However, the workflow is a little bit messed up because you can't do it for links that haven't been clicked yet... so could you please allow for somehow sharing and using 'open link with' for links that haven't been clicked?

[Zeluok]

@plateaukao, Maybe long-press on a link also triggers a similar context menu as you have already made for highlighting text, difference is that it should have both options 'share' and 'open with...' and the text used for the intent should be the link's 'href' property.

[plateaukao]

@Zeluok

For custom scheme uri, I already ask system to open them in latest version, since EinkBro has no way to handle them in any ways. Please try it with v8.29.3 when it's ready.

As for http/https applinks, as you said open link with... can do the trick in most cases. Not only in long press a link, but it's also available in menu too. That's how I used to open Youtube video in Youtube app when I need more native controls in Youtube app.

please allow for somehow sharing and using 'open link with' for links that haven't been clicked?

Now long pressing a link already has a context menu with share and open link with...

[Zeluok]

You're the best. Ah but long pressing a link is not doing anything for me in 8.29.0 - you mean to say you have added it now or it was already there?

[plateaukao]

try 8.29.2

there's an issue on v8.29.0

[Zeluok]

Thank you. It's perfect. Now only thing left is settings option if you want to, happy for you to close this issue! Btw, favorite browser (I've uninstalled all the others).