versionCode is monotonic, not marketing
Users see `versionName`; Play enforces `versionCode` integers that must always increase. Reusing a code, even across tracks, blocks upload. We inspect packages with the APK Analyzer before upload to confirm code, name, and permissions match the release notes we are about to publish.
I have seen CI publish the same code twice because a merge skipped the bump script—two green builds, zero store progress.
Internal testing track is your friend—upload there before production promotion when policy allows and nerves are high.
Staged rollouts do not forgive a bad `versionCode`—fix the integer before you chase crash reports that are really “users never got the build.”
Automate the bump in CI with a failing job when `versionCode` is not greater than the last tag—humans forget; scripts do not.
AAB vs APK and splits
Play wants App Bundles for most apps; know which ABIs you ship. Analyzer output shows native libs and suspicious size spikes—often an accidental debug `.so` or duplicated asset.
Signing matters: upload key versus app signing key confusion still trips new teams. Document who holds which keystore and the recovery path before anyone goes on vacation.
Mapping files for deobfuscation belong in the same release ticket as the bundle upload, not in a Slack thread you cannot find later.
Size regressions often trace to forgotten video assets or duplicate fonts—analyzer diffs highlight the megabytes faster than guessing from user complaints about storage.
Manifest and permission drift
A release that adds permissions needs user-facing justification and sometimes policy forms. Compare manifest against last production build, not only against git diff—build caches lie.
Deep links, exported components, and `android:exported` flags belong in release checklist. Analyzer plus manifest validator catch “it worked locally” fantasies.
If Play Protect flags something, analyzer diffs against last good build narrow the cause faster than guessing from the email subject line.
Release afternoon checklist
Bump versionCode, tag git, run analyzer on the artifact you will upload, smoke test install over previous store version, staged rollout percent set, rollback plan written. Boring? Yes. Cheaper than a bricked production track.
We link these tools in Android guides because the console error messages are terse and the fix is usually arithmetic. Do preflight once; ship calmly.
Keep release notes aligned with user-visible changes; store reviewers and users both notice when words and builds disagree.
Screenshot the analyzer summary in the release ticket—next month’s you will forget which ABI split shipped when investigating a crash cluster.