It looks like this pull request may not have tests. Please make sure to add tests before merging. While there are exceptions to this rule, if this patch modifies code it is probably not an exception.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@Liujingguang we should support loading flavor specific assets, but this is not the approach that I would take. For more information see #21682. Instead, we should probably update the asset manifest to allow specifying flavor/platform/mode et cetera and otherwise preserve the existing behavior.

If you're interested in working on this, i can give some pointers - or we could discuss in chat

add --flavor-assets-dir parameter. Directory for storing different flavor's assets. When compiling, only the specified flavor directory will be loaded from this directory. --flavor-assets-dir and --flavor are used in combination.

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@Liujingguang we should support loading flavor specific assets, but this is not the approach that I would take. For more information see #21682. Instead, we should probably update the asset manifest to allow specifying flavor/platform/mode et cetera and otherwise preserve the existing behavior.

If you're interested in working on this, i can give some pointers - or we could discuss in chat

@jonahwilliams This PR is mainly for the specific loading of resources for the flavor, and does not consider the factors of platform and mode. If you consider platform and mode, the idea is similar to the PR.
The resources that need to be distinguished according to flavor/platform/mode are uniformly placed in a folder, and the name of the folder is specified by --flavor-assets-dir (or other parameters), so that it allows you to filter specific resources based on the flavor/platform/mode information in this folder.

What is the method you want to take?

Passing flavor through the tool invocations is fine, since it allows the flutter tool to determine via the asset manifest which assets to include. What advantage does also specifying a flavor asset directory have over this?

Passing flavor through the tool invocations is fine, since it allows the flutter tool to determine via the asset manifest which assets to include. What advantage does also specifying a flavor asset directory have over this?

The idea of multi-channel resource filtering originally came from Android. Putting all resources in one folder can be managed in a unified way. The directory level will be clear. What's more, it can facilitate us to filter specific resources. If you have a better plan, please let me know.

I think this is a point to reduce the size of the installation package，In different flavor，we use different resource files, We don't need to import other resource files from other flavors，and we can use the one same yaml file, it's important.

I'm not against the idea of flavor specific assets or further filtering of assets, but this isn't the way I'd like to see it done