+++ This bug was initially created as a clone of Bug #1551639 +++

Bug 1551639 didn't address Android because updating buildid.h on every build has some impact on gradle.

One from mobile/android/base/generate_build_config.py:
https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/mobile/android/base/generate_build_config.py#138
https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/mobile/android/base/generate_build_config.py#147

And another from mobile/android/geckoview/build.gradle:
https://searchfox.org/mozilla-central/source/mobile/android/geckoview/build.gradle#57

While the former is easy (removing those lines would make things sort of work like buildid.cpp in toolkit/library), the latter needs more thought.

(In reply to Mike Hommey [:glandium] from comment #0)

+++ This bug was initially created as a clone of Bug #1551639 +++

Bug 1551639 didn't address Android because updating buildid.h on every build has some impact on gradle.

One from mobile/android/base/generate_build_config.py:
https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/mobile/android/base/generate_build_config.py#138
https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/mobile/android/base/generate_build_config.py#147

And another from mobile/android/geckoview/build.gradle:
https://searchfox.org/mozilla-central/source/mobile/android/geckoview/build.gradle#57

While the former is easy (removing those lines would make things sort of work like buildid.cpp in toolkit/library), the latter needs more thought.

The latter is only used (at this time) to populate the build ID in the crash reporter. So as long as it's correct in automation builds, it's sufficient.

Would it make sense to add a build ID (generated like MOZ_APP_BUILDID) that is fixed at configure time for this use case? Or even a build ID specifically for this Android crashreporter usage? The build ID has so much history and has meant so many different things :(

I wonder why BuildConfig is not handled like AppConstants. In fact, why are there two things that seemingly provide the same values?

(In reply to Mike Hommey [:glandium] from comment #2)

I wonder why BuildConfig is not handled like AppConstants. In fact, why are there two things that seemingly provide the same values?

A totally reasonable question. The answer is that AppConstants is the odd one out: Bug 1443202. With Fennec being deprioritized it's never been worth the effort to migrate the last "better in Gradle" things to Gradle. (That and the manifest includes aren't well supported in the Gradle pipeline.)

Now, why do it in Gradle at all? The goal is (was?) to be able to build the Android bits without needing much (preferably, any) of the moz.build system; doing that we get much better IDE integrations. Given how much things have changed in the last few years, that might no longer be the right approach.

Oh -- I forgot to say that we could make AppConstants point at geckoview.BuildConfig, or replace all instances of AppConstants.MOZ_APP_BUILDID with geckoview.BuildConfig.MOZ_APP_BUILDID. But I think the hard part is reckoning with the Gradle integration which is legitimately a little different.