Support creation of an engine AAR instead of a JAR for Android.

[matthew-carroll]

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.

[dnfield]

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]

@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]

@matthew-carroll Let's chat about this. I need to figure out the priority.

[blasten]

cc @xster

[dnfield]

AFAICT, the following changes would be needed:

• Rename flutter_java.jar to classes.jar in the engine build scripts (Trivial)
• Change create_flutter_jar.py to actually create an aar (Seems trivial)
• Update the tooling to look for the .aar instead of the .jar (Seems non-trivial - requires updates to templates, tooling code, gradle code)

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]

@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.

[xster]

It seems like #34459 is a separate issue (the flutter engine jar vs the flutter add to app wrapper module).

[jmagman]

Is this done with #35217?

[xster]

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]

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

Ah, thanks.

[dnfield]

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]

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]

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.