Question 2: When you’re configuring <https://devel...
# gradle
a
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
1️⃣ 3
2️⃣ 8
4️⃣ 1
3️⃣ 21
5️⃣ 18
m
TBH, I never really grasped why there was a need for 2 different concepts in the first place
💯 3
p
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.
m
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.
e
you can have any number of flavor dimensions
👍 1
m
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.