fix(bugsnag): give the app and the uploaded mapping the same build UUID

[bmc08gt]

Release crashes come through obfuscated. Bugsnag joins an uploaded ProGuard mapping to an incoming event on build UUID, falling back to applicationId + versionName + versionCode — and neither side of this build was supplying a build UUID, so matching rested entirely on the version numbers.

The app never reported one

com.bugsnag.gradle 1.2.0 emits the UUID as a string resource (GenerateResourcesTask), but bugsnag-android 6.27 reads com.bugsnag.android.BUILD_UUID only as manifest meta-data — ManifestConfigLoader lists it among the meta-data keys, and no class in the AAR looks up a string resource by that name (its R.txt has no bugsnag entry). The merged release manifest carried exactly one bugsnag meta-data entry, API_KEY.

Nothing references the resource, so it does not reach the APK either. From mapping/release/resources.txt:

string:com_bugsnag_android_BUILD_UUID:2131820793 is not reachable.

aapt2 dump resources on the release APK finds no bugsnag entry.

The upload omitted it too

registerProguardMappingTask sets the field conditionally:

buildUuidResolver.value?.let { task.buildUuid.set(it) }

BuildUuidResolver.value resolves to buildUuidGenerator or buildUuid from the bugsnag DSL, per variant then global. This project set none of them, so UploadMappingTask sent no build-uuid.

Change

Use the commit SHA on both sides:

• buildUuid on the release variant in the bugsnag block, so the mapping upload is tagged;
• a com.bugsnag.android.BUILD_UUID manifest meta-data entry backed by a manifestPlaceholders value, so the app reports the same string. Manifest meta-data is also out of the resource shrinker's reach, which the generated resource was not.

The release workflow builds the bundle and runs bugsnagUploadReleaseProguardMapping in one job on one checkout, so both Gradle invocations resolve the same HEAD.

Why it matters now

versionCode was the sole remaining join key, and the AGP 9 migration (c9edfc7) changed how it is produced: de.nanogiants.android-versioning was Gradle 9 incompatible, so versioning.getVersionCode() became git rev-list --count HEAD. Within a single CI job the two invocations agree, but a value derived from commit count is easy to desynchronise and fails silently when it does. An explicit build UUID removes the dependency.

Worth reporting the resource-versus-meta-data mismatch upstream as well: com.bugsnag.gradle 1.2.0 generates a resource that its own runtime never reads.