I\'m experimenting with Dynamic Features and Instant Apps. To navigate between various features, I use Deep Links.
Each time I navigate to another Activity, I see the d
There is a possible solution for using URI intents with dynamic features instead of switching to reflection. You can use a trick where you can get the needed class name during run time with packageManager.queryIntentActivities(), so you don't have to use the hardcoded Activity name.
The following extension function is an example of how you could convert your Intent using the URI or deep link into one that will not show the chooser dialog:
fun Intent.convertToSafeDynamicFeatureModuleIntent(context: Context) {
//Get list of all intent handlers for this Intent. This should only be the actual activity we are looking for
val options = context.packageManager.queryIntentActivities(this, PackageManager.MATCH_DEFAULT_ONLY)
//Set the activity that supported the given intent
setClassName(packageName, options[0].activityInfo.name)
}
Then you can simply do:
intent.convertToSafeDynamicFeatureModuleIntent(context)
startActivity(intent)
A longer explanation can be found here
So yes... I believe I have seen this before, it is some odd behavior when navigating from one dynamic-feature (instant) to another (non-instant) via a URL intent.
Until this gets addressed, I don't recommend using a URL intent to navigate between modules, instead, use reflection to directly get to the other module's activity, example:
if (doesModuleExist()) {
val intent = Intent()
.setClassName(getPackageName(), "com.sample.ProfileActivity")
.addCategory(Intent.CATEGORY_DEFAULT)
.addCategory(Intent.CATEGORY_BROWSABLE)
startActivity(intent)
}
Where doesModuleExist()
checks if either:
examining your sample manifest, it looks like your profile module is not part of your instant app dist:instant="false"
, so you would never have access to it, therefore you could simply do a isNotInstantApp()
check instead and never attempt the launch while as instant app.
once in your installed app, then you technically don't need to check, as it is always include="true"
but if your profile module is an onDemand module, or just for safety precautions, you should utilize splitInstallManager.getInstalledModules()
, see /app-bundle/playcore#manage_installed_modules (note, you can also use this API in your instant app)
And since it looks like this odd behavior varies between different devices, that might mean they've implemented subtle differences in intercepting and handling that URL intent, and/or it's just a different Android version (pre-O vs O+).
Also yes, associating multiple package names to a single website domain for common.handle_all_urls
might cause some additional misbehavior when the system tries to verify the association when your app goes live.