Support for Dynamic Feature Modules

Hello,

I know there is support for AppBundles which makes things easier, but i couldn't find whether Dynamic Feature Modules is supported or not. Support of Dynamic Feature Modules will be really really helpful for us so please share any plan you have.

Thanks,

@fruitedev

@fruitedev I remember there might have been some limitations when I first implemented app bundles:

https://github.com/xamarin/xamarin-android/blob/master/Documentation/guides/app-bundles.md#what-are-app-bundles

I remember something about needing to support "Instant Apps" for dynamic modules to work, which has a hard file-size limit. The Mono runtime was over the limit.

We should still look into this again. Anyone interested, please give a thumbs up above and that will help us know the demand, thanks!

@jonathanpeppers

@jonathanpeppers Let's consider that the module I want to load dynamically is an aar archive with some jar dependencies and I have a binding over this one. Would that make the process easier on your side ? I mean I do want to load this aar dynamically since it's pretty heavy.

Now that Apple has introduced App Clips, clients are now more interested in Android Instant Apps. Using app bundles may not be so possible due to the Mono runtime limit and that is fine, but if there was a way we could at least attach natively written instant app apk's as feature modules to the Xamarin.Android app that would be great.

@jonathanpeppers

Still really really interested in the dynamic delivery for our applications. We are open for a quick call to explain more about why if you want.
@jonathanpeppers @davidortinau.

I found that a community member has already bound the PlayCore library, https://github.com/PatGet/XamarinPlayCoreUpdater. This might have enough support to allow you to deliver a natively written apk as a dynamic feature and keep the main app as a Xamarin App.

@dellis1972

@dellis1972 Hum that might be but actually "publishing" this module to the play store will maybe be tricky if even possible as the application is in Xamarin. Even by creating a native application just for packaging this module I think it will not work well.
Have you heard about someone doing it ?

@johnthiriet

@johnthiriet I haven't heard of anyone doing it yet. The developer it seems only used it for in app updates.

[Xamarin.Android.Build.Tasks] Allow users to specify modules for apks…

I did some investigation last week as to what might be needed to support this feature.
Firstly the API's required do use this feature are not currently working in https://github.com/PatGet/XamarinPlayCoreUpdater. When trying to use them you will get a javac error at build time. This is down to the actual binding itself. One of the problems is that the SplitInstallManager uses Listener types which make use of Generics. Our binding story for generics is not completely working at this time. So that will be the first hurdle, get the binding working somehow. This might end up being something like a custom .jar which has a wrapper with a simplified API. We then bind the simplified API rather than use the code google provides. While this is not a great approach, it might be our only option.

The next issue is how do we build a "feature". Some investigation into this shows that it is not going to be straight forward.
The "feature" apk/zip needs to be built against the apk of the application. So we need to build any features after we have built the main application , but before we do the final bundling. The best option is to run a custom target before _PrepareBuildApk which will allow us to build the features, and gather any outputs.

The reason we need to build the features after is the packaged_resources zip file that gets produced by aapt2 as part of our build process MUST be passed as a -I argument to aapt2 when building the "feature"

aapt2 link --allow-reserved-package-id --package-id 0x7e --auto-add-overlay -o $(LevelPackageTemp) -I $(JavaPlatformJarPath) -I $(_PackagedResources) --manifest AndroidManifest.xml -A assets

This is required because the entires in the AndroidManifest.xml we need to include in the "Feature" MUST use resources from the main app for its distribution elements. This is a sample of a working AndoridManfiest.xml for an "Asset Feature"

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:tools="http://schemas.android.com/tools"
        xmlns:dist="http://schemas.android.com/apk/distribution"
        android:versionCode="1"
        android:versionName="1.0"
        package="com.infinitespacestudios.adtest"
        featureSplit="level1"
        android:isFeatureSplit="true">
	<dist:module dist:title="@string/level1" dist:instant="false">
		<dist:delivery>
            <dist:on-demand />
   		</dist:delivery>
		<dist:fusing dist:include="false" />
	</dist:module>
    <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="30" />
	<application android:hasCode="false" tools:replace="android:hasCode" />
</manifest>

Note the @string/level1 resource. That item must be present in the main app strings.xml. So we need to build the main app before we build the feature. Also we cannot build the resources using the --proto-format it seems. We need to build as a normal apk then use the aapt2 convert call to change the format later.

aapt2 convert --output-format proto -o $(LevelPackageProtoTemp) $(LevelPackageTemp)

We then need to manipulate the output file to move things around a bit. By default aapt2 places the compiled AndroidManifest.xml in the root of the zip file. However for aab files it needs to be in a manifest subdirectory within the zip. So we need to fix up the zip. Luckily we already have a task that can do that, so we can probably reuse some code to handle this. Any assemblies we include in the "feature" zip file need to be in the root/assemblies folder as per our normal aab code. At this time the runtime does not support "reloading" our assembly list so we cannot support dynamic delivery of assemblies at this time. However with some additional investigation we might be able to support it.

Once we have this "feature" zip file build we can then pass that to the bundletool via the AndroidAppBundleModules ItemGroup (see here)

The current idea on how an end user might use this is that we allow for an additional piece of meta data on the ProjectReference ItemGroup.

  <ItemGroup>
      <ProjectReference Include="Levels\Level1\Level1.csproj">
         <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
         <AndroidDynamicFeature>true</AndroidDynamicFeature>
      </ProjectReference>  
  </ItemGroup>

In this case ReferenceOutputAssembly HAS to be false otherwise our build system will just include the assembly in the final package. AndroidDynamicFeature is the new item and if 'true' means that during packaging, the feature package will also be produced. The nice thing about using ProjectReference is that the feature will be built as part of a normal build.

At runtime once a user has installed a "feature" they can then use CreatePackageContext to get a new instance of an AssetManager which will contain the new assets.

var ass = CreatePackageContext(PackageName, 0);

For assemblies we need to decide what to do. For java apps they can call StartActivity to kick off an activity assuming the feature contains android activities. The AndroidManifest.xml for the feature would also need to have those activity elements in it so android can pick those up. This might work once we have runtime support to detect new split installs. However we are currently unsure how to do this.

The other option is to use Assembly.Load to load the new "feature" assembly. This might be required if you want to call C# code since there is no reference between the main app and the feature. Reflection will probably be needed to create an instance of a feature class and execute methods. We might be able to hook into the runtime Assembly.Load method do so a search in additional apks/directories if we don't find an assembly in our current mapping list. However this will need us to be able to known "where" the new things are installed.

So we have a number of things we need to implement and investigate before we can fully support this. We will probably have to break this up into a smaller set of projects. The initial goal will be to support dynamic delivery of "assets" the follow that up with dynamic delivery of assemblies later since the runtime changes will not be easy.

UPDATE: So more investigation has turned up some interesting info. Each "Feature" needs to have a different package-id. By
default the package-id is 0x7f for an app. What gradle seems to do is DECREMENT this value for each "feature" that is in the project. So your first "feature" will be 0x7e , you second 0x7d etc. So there is a hard limit on the number of features you can have. This value will need to be passed to aapt2 via the --package-id argument in addition to the --allow-reserved-package-id.

Some thoughts on using ProjectReference. I don't think we can use that now, mostly because we probably need to be able to reference the main app from the feature. To do this we need to pass the feature a path to the main app assembly which needs to be built first. So using a ProjectRefernce will not work since they will be built before the main app. So we will probably need to create a new ItemGroup AndroidDynamicFeature which we can then build after the main app.

<ItemGroup>
     <AndroidDynamicFeature Include="Features/Asset/AssetFeature.csproj" />
</ItemGroup>

This will allow us to pass in not only the main app dll but also all the references which the main app have. This will include things like AndroidX.* and GooglePlayServices. So there should be no need to add those things to the "feature" as PackageReference .

So a new todo items are.

This is just a brain dump of all the stuff I have found other the last couple of days. There are probably more things we need to do but this is a good starting point. To manage some expectations, this is not going to be a quick process. We have not even mentioned IDE integration or the actual end user experience yet. So this is going to be an on going process. But we are looking at it, which is a start :)

Ah, so we should be able to knock this out in an afternoon, right??? 👀

@dellis1972

@dellis1972 That is the most interesting thing I have read in weeks :-)

[Xamarin.Andorid.Build.Tasks] First Pass on Dynamic Asset Features

For those of you who are interested in asset packs I have a new PR up at #8631.

We could use some feedback on the approach we plan to take on this if anyone has the time :)

[Xamarin.Android.Build.Tasks] %(AndroidAsset.AssetPack) Support (#8631)

Asset Pack support has been merged, should be in the next .NET 9 Previous.

Still trying to figure out how we can even support feature packs :/

Navigation Menu

Repository navigation

Support for Dynamic Feature Modules #4810

52 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for Dynamic Feature Modules #4810

Description

Activity

jonathanpeppers commented on Jun 16, 2020

johnthiriet commented on Jun 29, 2020

evansmj commented on Jul 30, 2020

johnthiriet commented on Sep 16, 2020

dellis1972 commented on Sep 16, 2020

johnthiriet commented on Sep 19, 2020

dellis1972 commented on Sep 21, 2020

dellis1972 commented on Dec 2, 2020

jonathanpeppers commented on Dec 2, 2020

johnthiriet commented on Dec 2, 2020

52 remaining items

dellis1972 commented on Jan 17, 2024

dellis1972 commented on Mar 18, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions