Question 2: When you’re configuring <https://developer.android.com/build/build-variants#product-flav...

# gradle

[akapanina]

Question 2: When you’re configuring product flavors, what exactly is different between them in your projects?
1️⃣ Compilation settings
2️⃣ Packaging/distribution configuration
3️⃣ Sources with functionality
4️⃣ Test sources
5️⃣ Resources

[mbonnin]

TBH, I never really grasped why there was a need for 2 different concepts in the first place

[psh]

Pre-release testing of the release build pointing to a staging environment server. The release is my build type, what environment is my flavor. Similarly with recreating production bugs using prod-like backends. QA team wanting to compare across dev / RC versions on the same phone, so changing app id.

Flavor dimensions of both server env ( 5️⃣ ) and app usage type ( 3️⃣ ) give a fun matrix of possible binaries!

[edit] eep. We had to support 2 different barcode scanners (and a lack of one) on that project too.

[mbonnin]

I get the matrix thing but then why limit it to 2 dimensions? Maybe I want a 3 dimensional matrix with R8/no-R8 , playStore/internal and staging/prod (8 possibilities!). Or maybe I want to forbid some cases like internal is always debuggable or what not. The matrix can be made in user-land, it doesn't have to involve different AGP concepts.

[ephemient]

you can have any number of flavor dimensions

[mbonnin]

Right 👍 and these and to the matrix dimension, right? Still feels weird that the "buildType" dimension has a different "type" than the "flavour" ones. Why can I set "applicationIdSuffix" on both but "isDebuggable" is only on the BuildType ? In that sense I like the KGP APIs better. It's all "binaries" and I can create them the way I want.