For customers who critically care about the artifact size and don't mind spending time fine tuning a custom engine build to trim unneeded features, we should support a semi-convenient workflow.

@dnfield also floated some ideas previously.

Letting the user turn flags on and off via gn files manually and building local engines is likely ok as long as they're documented and runtime errors are properly surfaced.

For readers: your feedback is also extremely valued (in helping us determine how to slice and dice the engine for optional modularity). To see the current engine size breakdown, please see https://ci.chromium.org/p/flutter/g/engine/console, click on the latest Linux/AOT build. Under gsutil upload treemap for out/android_release_arm64/libflutter.so, click Open Treemap.

Example from 2019-09-11: https://storage.googleapis.com/flutter_infra/flutter/e2cc04c3fc74473cc3f2fbf45ae02e72b0f3594e/android-arm64-release/sizes/index.html

Each box in the graph is also double-clickable to further drill down into the contents. (cc @goderbauer to proof-read instructions)