Repository navigation
Support creation of an engine AAR instead of a JAR for Android. #22102
Description
Support creation of an AAR instead of a JAR for Android.
Android uses XML resources as a canonical element of everyday development. It is possible to reference FlutterFragment and FlutterView from XML, but the Flutter embedding currently has no capability to expose XML attributes to customize those elements.
For example, we might want to do this:
<io.flutter.embedding.FlutterView
android:layout_width="match_parent"
android:layout_height="match_parent"
app:splash="@android:color/blue"
/>The definition of app:splash needs to be setup as an XML resource. But we can't do this in the embedding because we aren't producing AARs and therefore we cannot include any resources.
The JAR restriction also prevents us from defining any of our own XML layouts, defining our own colors, defining any Flutter-specific IDs, etc.
Activity
dnfield commentedon Oct 16, 2018
I'm not actively working on this, removing assignment - please let me know if you're looking for anything from me on it though!
matthew-carroll commentedon Jun 6, 2019
@blasten I wanted to put this ticket on your radar. It's been here for a while. I think this is something you plan to work on at some point, right? There are many reasons why we'd like to generally support the production of AARs. There may be duplicate tickets based on other reasons.
blasten commentedon Jun 6, 2019
@matthew-carroll Let's chat about this. I need to figure out the priority.
blasten commentedon Jun 6, 2019
cc @xster
dnfield commentedon Jun 6, 2019
AFAICT, the following changes would be needed:
flutter_java.jartoclasses.jarin the engine build scripts (Trivial)It would probably be helpful for someone to manually do this (manually compose an .aar from the existing .jar) and make sure the benefits we think we'll get from it actually pan out.
matthew-carroll commentedon Jun 6, 2019
@dnfield also, the reason I identified this need way back last year was specifically because I wanted to include Android resources. So in addition to the technical build steps, we need a location for those resources: styles, IDs, colors, etc. We are currently encoding random integers as IDs, for example.
3 remaining items
xster commentedon Dec 19, 2019
This bug is about us building the engine into an AAR on LUCI rather than users building their modules into an AAR via Flutter tools
jmagman commentedon Dec 19, 2019
Ah, thanks.
dnfield commentedon Feb 6, 2020
Would this be needed to support delivering assets from the engine as configuration APKs?
In particular, if we could manage to split ICU up into various locales, could we ship them as configuration APKs that are loaded only by users who need them?
/cc @blasten
https://developer.android.com/guide/app-bundle/dynamic-delivery
xster commentedon Mar 12, 2020
I suspect this is orthogonal to dynamic delivery from what I can think of. This is mostly about compile time dependencies such as downstream consumers can reference the engine and make compile time assumptions about what resources are available. Once we actually build and bundle runtimes with an APK, we can make that APK do anything including use dynamic delivery to load more APK contents.
matthew-carroll commentedon Mar 12, 2020
I think this was also about the ability to reference resources, like IDs from within the embedding. Currently, I think we generate some random numbers in places where the correct answer is
R.id.something. But that ID system only exists when building AARs.