Home > Enterprise >  Build multiple flavors into a single app bundle with separate launchers
Build multiple flavors into a single app bundle with separate launchers

Time:01-07

I want to build an app with different configurations. Let's say there are two flavors, A and B, which depend on different third-party libraries to perform similar tasks. I want to offer a default configuration on Google Play which comes with a separate launcher for each flavor. Both launcher instances should share local data. However, I also would like to keep the option to build and ship just one of the flavors without including the third-party libraries required for the other one.

From what information I've found, I could either use a single flavor with two launchers, losing the option to build just for one of the third-party libraries. Or I could use two flavors, but would have to separate the whole project into multiple apps with separate ids which would have to be updated separately, presumably require more storage and require some kind of workaround for sharing local data.

So, is there a way to build multiple flavors into a single app bundle with separate launchers or a similar solution for these requirements?

CodePudding user response:

is there a way to build multiple flavors into a single app bundle with separate launchers

I am assuming that by "flavors" you mean product flavors in the Android build system. If that is correct, then... no, sorry, there is no simple option for this.

or a similar solution for these requirements?

It might be possible to pull off something like this with a careful subdivision of your app into modules. You would have three app modules — I will call them a, b, and ab after your naming system. Those would be as small as possible. Most of your code would reside in a series of library modules. In particular, code tied to each third-party SDK would be isolated in its own library (or libraries). a would link to library modules tied to one SDK (plus common modules), b would link to library modules tied to the other SDK (plus common modules), and ab would link to (probably) everything.

  • Related