Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability for branded APKs to deep link/register intents to wildcard domains #310

Open
mrjones-plip opened this issue May 23, 2023 · 3 comments
Labels
Type: Improvement Make something better

Comments

@mrjones-plip
Copy link
Collaborator

What feature do you want to improve?
Right now we tightly bind the APKs intent to the app_host (see step 3 in "New Brand"). This does not enable a way to link to something like *.cht.domain.com.

Describe the improvement you'd like
Enable an extensible way to add a wildcard domain for all intents.

Describe alternatives you've considered
NA

Additional context
This will work well when we deliver on #309. We also already have a deployment that needs this.

@jkuester
Copy link
Contributor

jkuester commented May 24, 2023

@mrjones-plip @kennsippell I am slightly concerned that wildcards in the intent might be more trouble than it is worth in the long term (e.g. when we go to fix #308). Auto-verifying a wildcard intent in Android 12+ is going to require the assetlinks.json file be published "at the root hostname". What is tricky here is that in most of these cases I can think of where the wildcard intent would be useful, there will probably not actually be a CHT instance running on the root domain. So, the deployment of that file would have to be a custom/bespoke process for each case....

The Android docs I linked note that registering multiple links for the intent works different from a wildcard intent. When multiple links are registered, the assetlinks.json file needs to be accessible at each of the links. Technically this will be more moving parts when managing multiple CHT instances because you will end up with n files that have to be deployed. However, a likely solution to #308 is to add support to cht-core/cht-conf for just deploying the file to the CHT server along with the rest of the configuration....

Also, for what it is worth, additional custom links can already be registered by specific brands just by creating a custom AndroidManifest.xml file for the brand and adding something like this:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools"
  package="org.medicmobile.webapp.mobile">

  <application>
    <activity android:name="AppUrlIntentActivity"
      android:launchMode="singleInstance"
      android:exported="true">
      <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="@string/scheme" android:host="not.app_host.com" android:pathPattern=".*"/>
      </intent-filter>
    </activity>
  </application>
</manifest>

When the brand gets built, this AndroidManifest gets merged with the main one.

@mrjones-plip
Copy link
Collaborator Author

Thanks for the update @jkuester !

tl;dr - feel free to make this work at scale using the best means possible. I think using multiple links might be more scalable than a wildcard per you above concerns. My detailed thoughts below.

cc @kennsippell and @dianabarsan and @Hareet


I think it is fair to make this somewhat difficult, but possible, for a national scale deployment with multiple CHT instances, but easy for a single CHT instance.

When multiple links are registered, the assetlinks.json file needs to be accessible at each of the links.

I believe this means we can fix #308, again presuming CHT Core/cht-conf allow the instance to natively host the assetlinks.json file, by publishing as many URLs in Manifest as shown in the docs instead of a wildcard. Here's a handy inline example illustrating the .net and .com intents in the same manifest:

<application>

  <activity android:name="MainActivity">
    <intent-filter android:autoVerify="true">
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="http" />
      <data android:scheme="https" />
      <data android:host="www.example.com" />
    </intent-filter>
  </activity>
  <activity android:name="SecondActivity">
    <intent-filter>
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="https" />
     <data android:host="www.example.net" />
    </intent-filter>
  </activity>

</application>

On the server side of the equation it's a huge benefit to use a single APK, like in #309, as it means there's just a single assetlinks.json file with a shared package_name and sha256_cert_fingerprints for all servers visible in the list at launch. See docs for more info on these two tokens used in the JSON.

@kennsippell
Copy link
Member

kennsippell commented May 25, 2023

I've updated #311 to implement this via 47 unique intents in AndroidManifest.xml.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Improvement Make something better
Projects
None yet
Development

No branches or pull requests

3 participants