Skip to content

Support different set of assets depending on --flavor xxx #21682

Description

@zoechi

Edit by @christopherfujino

A design doc for this proposal is at https://flutter.dev/go/flavor-specific-assets


I want to create different flavors of the app and they differ (among other things) on the used assets (icons, backgrounds, fonts, logos, ...)

Currently this seems to require to modify pubspec.yaml before running flutter build
but that is cumbersome.

I'd prefer something like

flutter_assets.yaml # shared assets
flutter_assets_chocolate.yaml # additional assets for chocolate flavor
flutter_assets_strawberry.yaml # additional assets for strawberry flavor

where the shared assets and the assets where the file suffix matches the --flavor xxx value are merged and the result used for flutter build.

Activity

  1. added
    c: new featureNothing broken; request for a new capability
    a: assetsPackaging, accessing, or using assets
    on Sep 11, 2018
  2. added this to the milestone on Sep 11, 2018
  3. added
    toolAffects the "flutter" command-line tool. See also t: labels.
    on Dec 10, 2018
  4. sestegra commented on Dec 18, 2018

    @sestegra

    @zoechi
    Shared assets could be defined in pubspec.yaml. What do you think ?

  5. zoechi commented on Dec 18, 2018

    @zoechi
    ContributorAuthor

    @sestegra I don't think it's a good idea to define them in pubspec.yaml, but as far as I am aware there are people drawing plans about that topic with better insight already than I have.

  6. sestegra commented on Dec 18, 2018

    @sestegra

    See my proposal #25487

  7. sestegra commented on Dec 19, 2018

    @sestegra
  8. yousifk commented on Jun 22, 2019

    @yousifk

    @sestegra
    I check your project,that all asset adds to apk becuase

    Bundling of package assets
    If the desired asset is specified in the pubspec.yaml file of the package, it is bundled automatically with the application. In particular, assets used by the package itself must be specified in its pubspec.yaml.

    A package can also choose to have assets in its lib/ folder that are not specified in its pubspec.yaml file. In this case, for those images to be bundled, the application has to specify which ones to include in its pubspec.yaml. For instance, a package named fancy_backgrounds could have the following files:

    content_copy
    .../lib/backgrounds/background1.png
    .../lib/backgrounds/background2.png
    .../lib/backgrounds/background3.png
    To include, say, the first image, the pubspec.yaml of the application should specify it in the assets section:

    content_copy
    flutter:
    assets:
    - packages/fancy_backgrounds/backgrounds/background1.png
    The lib/ is implied, so it should not be included in the asset path.

    https://flutter.dev/docs/development/ui/assets-and-images#from-packages

    SceenShot about analysis apk
    https://imgur.com/2HmGHC1

  9. sestegra commented on Jun 22, 2019

    @sestegra

    @yousifk Good remark, but I won't have time to update my pull request #25487 to support further versions. In fact, this pull request only supports Flutter 1.0.0.

    Moreover, I guess that Flutter team wouldn't integrate it in short terms.
    I suggest you to develop some scripts to update pubspec.yaml when compiling different flavors and/or targets.

  10. yousifk commented on Jun 25, 2019

    @yousifk

    @sestegra
    Thanks so much ... I do it .bat script
    I will share it at github

  11. droplet-js commented on Aug 14, 2019

    @droplet-js

    any update?

  12. ljg-7f commented on Oct 10, 2019

    @ljg-7f

    #41094
    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.

  13. jonahwilliams commented on Nov 15, 2019

    @jonahwilliams
    Contributor

    @Hixie do you recall the format you described several weeks (months) ago?

  14. PandaGeek1024 commented on Dec 10, 2019

    @PandaGeek1024
  15. 55 remaining items

  16. andrewkolos commented on Aug 1, 2023

    @andrewkolos
    Contributor

    I've written a proposal in the form of a design document, Flavor-specific Assets. This will be discussed in the next Dash Forum (August 8th, US time).

  17. giaur500 commented on Aug 2, 2023

    @giaur500

    Regarding to flavors, there is one more thing to be discussed. You probably know how it works with native Android apps. You can declare main resources and all flavors will use them, unless you overwrite any item for specific flavor. So, there's not need to duplicate assets, if you don't define any flavor specific one, default will be used.

    As far as I understand, all ideas that have been considered here assume full set of assets for each flavor, so some assets must be actually duplicated.

  18. andrewkolos commented on Aug 2, 2023

    @andrewkolos
    Contributor

    As far as I understand, all ideas that have been considered here assume full set of assets for each flavor, so some assets must be actually duplicated.

    Duplicate declaration (or any kind of duplicate work) is something the designs try to avoid. For all the pubspec-based proposals on the design doc (as of 8/2), the user would only need to declare every asset (or asset directory) once. Said another way:

    • If an asset is common to all flavors, the user would simply declare it without a flavor.
    • If an asset is unique to a flavor (or subset of flavors), the user would add the flavor(s) to that asset entry (or asset group, if choose to implement such a syntax).

    I'll try to revise the document to make that aspect more clear. Also, anyone can comment on the doc using the comments feature in google docs, so feel free to add a comment to a part of the doc if it seems confusing.

  19. added
    r: fixedIssue is closed as already fixed in a newer version
    on Dec 8, 2023
  20. passsy commented on Dec 9, 2023

    @passsy
    Contributor

    Related #65065

  21. github-actions commented on Dec 23, 2023

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  22. locked as resolved and limited conversation to collaborators on Dec 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Important issues not at the top of the work lista: assetsPackaging, accessing, or using assetsa: sizeReducing IPA/APK/JS sizesc: new featureNothing broken; request for a new capabilityc: performanceRelates to speed or footprint issues (see "perf:" labels)customer: crowdAffects or could affect many people, though not necessarily a specific customer.design docTracks a design discussion documentperf: app sizePerformance issues related to app size (binary/code size) or disk spacer: fixedIssue is closed as already fixed in a newer versionteam-toolOwned by Flutter Tool teamtoolAffects the "flutter" command-line tool. See also t: labels.triaged-toolTriaged by Flutter Tool team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions