Previously, I described a Gradle script that handily generates release version codes for Android apps. The generated version codes take the form [date][number]
.
I finished that article with a litany of Gradle bugs. Today: fresh Google bugs!
In May, Google added automatic crash reporting to the Google Play developer console. Before auto-reporting, users had to explicitly send reports when apps crashed. So far so good, but if you’re testing on a physical device, you might notice something alarming: reports of bugs you already fixed, or crashes you only saw in development.
Apparently, Google forgot to filter out reports from debug-mode applications. Perhaps Google would claim this is a feature, but it means that you can’t tell which crashes are actually happening in the wild.
Google says crash reporting is “opt-in.” This is meant ironically, since the option to turn it off doesn’t actually exist on, for example, the Samsung S8. (There is a different option, “report diagnostic information.” As far I can tell, it’s a placebo.)
To work around this, we need to make crash reports from the debug version look somehow different from the production version. Crash reports include the version code, so remember that suffix? We can use that. Instead of using one number per release, use two: one for the release, one for the next development version:
// Version code updates when released to a date-based format. Even-numbered version codes are // release builds, odd-numbered version codes are debug builds. MAX five releases per day. def releaseVersionCode = null def writeVersionCode(versionCode) { def releaser = project.plugins[net.researchgate.release.ReleasePlugin] def propsFile = releaser.findPropertiesFile() def props = new Properties() propsFile.withInputStream { props.load(it) } props.versionCode = versionCode.toString() propsFile.withOutputStream { props.store(it, null) } } task nextDebugVersionCode { doLast { // Even though this runs after the release build, project.versionCode is still the version // code *before* release. The Release plugin runs the release build in a separate Gradle // invocation, so the release package picks up version changes in gradle.properties. When // control returns here though, it's the original Gradle invocation, and has *not* reloaded // gradle.properties. writeVersionCode(releaseVersionCode + 1) }} updateVersion.dependsOn nextDebugVersionCode task setReleaseVersionCode { doLast { def current = project.versionCode.toInteger() releaseVersionCode = new Date().format('YYMMdd0', TimeZone.getTimeZone('UTC')).toInteger() if (releaseVersionCode <= current) { // Should only happen when there is more than one release in a day releaseVersionCode = current + 1 } writeVersionCode(releaseVersionCode) }} unSnapshotVersion.dependsOn setReleaseVersionCode
So, now the first release of the day gets suffix zero, the debug version that follows gets suffix one, and so on. I’m writing this on July 26, so if I cut two releases today, my version codes will be:
- 1707260, production
- 1707261, debug
- 1707262, production
- 1707263, debug
It’s subtle, but at least now we can tell which crashes actually happened to people using your app: they are even numbers.
Or are they?
It appears that Google stores the crash data on the phone and reports it only once per day. The version code it reports is the version running on the phone when it sends the report, not when the crash actually happened.
If the app updates in the interim, we can still get crash reports for bugs already fixed and they will seem to come from a version that includes the fix.
I don’t know of any workaround.