I’m pretty much a complete newbie who managed to build a complicated build script with a very marginal idea of how gradle really works. I’ve been using version 7.5 with Android Studio and it has been recommending I upgrade to a newer version of Gradle for some time, but the automated upgrade feature did not work so I’ve been ignoring it.
Now I’ve had to rebuild my development environment which has forced me to used gradle 8.9 and now the builds are failing with errors that would probably make sense if I really new how gradle works. But I don’t. Can anyone help with this?
Good guess, but no luck. Removing the entire store flavor just moved the error to the next variant. There must be some new way to pass parameters to variants.
No luck there either. The Google documentation on android product flavors is unchanged. According to it, what I have here should work. So what am I missing???
I figured out how to generate a scan. Presumably there is some why to recover the build script text from the scan but I haven’t figured that out yet.
Unfortunately not, unless you find the actual project somewhere like in this case.
I strongly recommend you switch to Kotlin DSL. By now it is the default DSL, you immediately get type-safe build scripts, actually helpful error messages if you mess up the syntax, and amazingly better IDE support if you use a good IDE like IntelliJ IDEA or Android Studio.
Here especially the “actually helpful error messages” for example would kick in.
The message you get means “something within the google { ... } block is wrong, but I don’t tell you what”.
In this case it is a small block so not all too hard to find out, but sometimes you get the same for the android { ... } block for example and can then for a long time comment in and out random things to find the problem.
I guess in your case the problem is, that you nest productFlavors within buildTypes where it does not belong (they are parallel). So my assumption is, that google (or rec now) is not considered a product flavor but a build type, and due to that the configured properties are not the ones that are expected.
I am taking up the suggestion to convert this to Kotlin DSL, which is not going well. But I will address those problems in other questions and let this thread fade away.