We have flavors in Android. This is a mechanism for separating builds. Everyone knows this is for separating all those dev/qa/prod, gms/hms, free/paid, driver/rider. Google advertises it like this. By the way, there are also build types, which are literally no different, but that's a completely different story.
Why do we need them? Supposedly to simplify switching between different types of builds for developers and to customize the settings of these builds, including source sets, resources, configs, basically anything.
What if I told you that we already have a mechanism for controlling what gets into the build or not? Dependencies between modules! Create application modules for different types of builds, connect the corresponding modules implementing different functionality, and that's it. A bit more code for configuration, a million times fewer problems.
Flavors are a cure that's worse than the disease. It's always some quick crutch that immediately starts working against you.
Why? At least because of the impact on configuration and build. Let's imagine we have 100 Gradle tasks, so with debug and release build types there will be 200, with dev/prod flavors there will be 400, with gms/hms there will be 800. And so on. And they have different suffixes, well, literally different tasks. So what? - You'll ask. Well, for example, the cache between them is poorly reused. The fact that you built a dev build doesn't make the prod build easier right after it. Gradle builds it from scratch, even though they differ, for example, only by one line of server URL, but the configuration has changed. Well, configuring 800 tasks also takes a bit longer than 100, as you understand.
Superpositions of build types and flavors are called variants. As for the ease of switching between variants, there are also questions. As soon as you switch to another variant in the Studio, it immediately starts ignoring everything that was used in other variants, code is not checked, refactoring doesn't work, it simply doesn't participate in indexing. This fragile construction is very unpleasant to maintain. And also, what if I told you that we already have variant switching? Where you choose which run configuration (app module) to launch.
Don't use flavors on projects bigger than hello world. DI and dependencies between modules calmly solve the same task, and much more explicitly. And it's still tolerable if you have one flavor, and that in the app module - that's tolerable, but when there are more and they spread to library modules, that's too much. I want to unsee how flavors were used on all projects where I worked.