In my current App I have 2 builds, lets call them build 1
and build 2
. I understand that two flavours can share common code/resources but can also have separate code and resources such as the following:
What i am trying to do is expand build 2
so that it shares some code with another build (e.g build 3
). Either sharing some code such as the following:
This would be build2 and build 3 sharing some code/resources while also having the ability to have their own unique code sets. Or:
Here, build 3
is extending build 2
so that all code and resources from build 2
are available in both builds but build 3
can also have its own unique code/resources.
I think that extending build 2
is the best way (if it is possible) but any advice or pointing me in the right direction would be much appreciated. I have spent over 6 hours scouring the internet with no avail.
Once the new project is created, by default it consists of two build types/variants - debug, release. Debug is the build type that is used when we run the application from the IDE directly onto a device. A release is the build type that requires you to sign the APK.
So, product flavors allow you to output different versions of your project by simply changing only the components and settings that are different between them. Configuring product flavors is similar to configuring build types: add them to the productFlavors block of your project's build.
You use same core ingredients to make the base but will use different toppings for each one to have a different taste. Similarly, android apps can have the same base functionalities with changes to some of the features like styles, logo etc. This can be achieved using product flavours.
Build Type applies different build and packaging settings. An example of build types are “Debug” and “Release”. Product Flavors specify different features and device requirements, such as custom source code, resources, and minimum API levels.
There's not good support for this. If you really wanted to do it you could explore some hackery with symlinks to try to make different flavors effectively share folders, but that will make things a little weirder with source control, and I can't be sure it won't cause subtle problems in the build.
I would encourage you to not try to do a lot of trickery in the build system, because in the long run it will make your app harder to write and maintain, especially since at present the IDE doesn't have good facilities for dealing with code across product flavors (e.g. if you refactor code, there's no way to have the refactoring apply across a non-active product flavor; you can only work with one at a time).
A better approach would be to take the stuff that's common to Build 2 and Build 3 and extract it out into an Android Library module that's a dependency for those flavors but not for the Build 1 flavor. Different product flavors can have different dependencies, and that mechanism is supported and works well.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With