IssueTracker

Thanks for the update, Nick. This will only be part of the LLVM 13 major release, right?

We may upgrade upstream SwiftShader to the LLVM 12 release (or 12.0.1) in the not too distant future, and it looks like we should still be using the -warn-stack-size command line flag. In my previous change I was wrong to assume 12 hadn't been released yet, and the "older than version 12" description doesn't match the code. :-(

I'm considering this fixed for now since it won't affect us until we upgrade to LLVM 13+, and there's a check in place so it won't regress unnoticed. No strict need to make use of the function attribute before the upgrade, since that will involve a bunch of work anyway. Patches welcome though!

As part of b/217573066 we're going to add support for building with a more recent version of LLVM. https://reviews.llvm.org/D103928 has landed quite a while ago so we can make use of the attribute instead of the command line option.

This called a "breaking change."

Why not first deprecate VERSION_CODE and VERSION_NAME ?

Same problem. It seems VERSION_CODE and VERSION_NAME generated only for application module. Other library gradle module don't have these constants in their BuildConfig.

Hi all,

Yes, we should have deprecated this first. Since this happened (several months ago), we have put in place better policies for deprecation/removal of properties. This happened kind of late for 4.1 though, and this particular issue fell through the cracks so we did not get a chance to decide whether to revert this change (and we even missed putting this change in the release notes at first). We apologize for this.

Some of the motivation behind this were to reduce/remove the confusion around 2 points:

• Users accessing the BuildConfig fields but not setting them in the DSL. This would definitively be broken and not do what one would expect (ie these are static values, and won't magically reflect the version of the app the library is embedded in)
• The library AndroidManifest.xml file contains the values set in the DSL, but these values are completely ignored by the consuming app(s) during manifest merging (they are also overridden)

If you want to keep injecting the values from a common place into all your library project's BuildConfig fields, you could continue to do this manually with your own custom fields. These fields will only exist if you set them via the DSL (therefore preventing problem #1 above), and will not impact the library manifest (problem #2 above).

However, if you have a large setup with many library projects, this pattern will generate a lot of duplicates. It would make more sense to have a single module that generates a similar class, and have all your library projects (or at least the ones that need the info) depend on it.

Why do you still set

defaultConfig {
        versionCode project.android_version_code
        versionName project.android_version_name
}

?

This has no impact on the library. All this does is put the version in the manifest, and this gets overridden by the app anyway.

as we mentioned in the release note update we pushed yesterday, we will remove versionCode and versionName from the library DSL at some point (ETA is early 2022 as we need to move fully to our new DSL interfaces first.)

This should be marked duplicate of https://issuetracker.google.com/issues/158695880.

I just ran into this issue and find this change absolutely ridiculous.

Rather than deprecating a valuable field that many library developers rely on for logging, crash reporting, serialization, HTTP request tagging, and more, why not rename the field to LIBRARY_VERSION_NAME/CODE if preventing confusion was the rationale behind this change?

And considering it was removed without deprecation, I find it very unprofessional.

I vote to bring it back.

it is true that we should have deprecated it first, we will be more careful next time.

as for your example, if you are ready to change your code to use a new property name, then nothing prevents you from generating an appropriate build config field and use that throughout your code.

#22, it should only affect libraries. can you share a repro case ?

#24 So, this actually means that the change itself is helpful. And for anybody who for whatever reason cannot use any of the workarounds listed above, they should simply delay upgrade to the new version of AGP.

And what to do with BuildConfig.DEBUG? (Sorry it is not for this thread, but I didn't found thread for BuildConfig.DEBUG).