@mosuem and I had a bunch of discussions around loading units and native assets.

Tree shaking whole native assets if they're completely unused is kind of a special case of loading units. E.g. the asset doesn't end up in any of the loading units.

One of the main questions is whether we can let the Dart&Flutter SDK do this, or whether this needs to be part of the native_asset_cli protocol.

If assetLoadBytes has a must be const assetId (and @Native already has a const asset id), then we might be able to do it in the SDK and avoid ever having to add loading units to the build and link hook protocols.

If making the assetId being const in loadBytes is too restrictive, we could consider having an AssetReference(String assetId) implements RecordReference which can be sprinkled on methods.

However, if even that turns out to be too restrictive (because some const string arguments are passed to some method, and there is some arbitrary mapping to asset Ids which is easily implemented in build or link hooks), then the loading units should be part of the (build and) link hook protocol.

Currently, the tree-shaking of whole assets must also be implemented by a package author in their link hook. We have an open issue for automatically not bundling it based on the @Native annotations (#52970 (comment)).