[cheetahbyte]

Summary

A vMAJOR.MINOR.PATCH tag now publishes a signed release APK with FCM on GitHub Releases.

push tag v1.2.3
└── release.yml
    ├── version 1.2.3, code 10203 (MAJOR * 10000 + MINOR * 100 + PATCH)
    ├── restore release.jks and google-services.json from secrets
    ├── ./gradlew assembleRelease, signed with alias crumble
    └── gh release create v1.2.3 crumble-1.2.3.apk

• app/build.gradle.kts signs release builds when CRUMBLE_KEYSTORE_PATH and CRUMBLE_KEYSTORE_PASSWORD are set, and reads the version from crumble.versionName and crumble.versionCode, defaulting to 1.0 and 1.
• The README describes the release flow, the secrets, and local signing.

Why

There was no way to ship an installable APK: release builds were unsigned, the version code was fixed at 1, so updates couldn't install over older builds, and google-services.json only existed on the maintainer's machine.

Evidence

• Signed with a throwaway key: assembleRelease succeeds, apksigner verify passes, and aapt2 reports ng.crumbli.android, versionName 0.1.0, versionCode 100. processReleaseGoogleServices generated the Firebase values.
• Without a key: assembleRelease succeeds and produces app-release-unsigned.apk.
• Tag parsing: v0.1.0 gives 100, v1.2.3 gives 10203, v2.10.99 gives 21099; v1.2 and v1.100.0 are rejected.
• The keystore at ~/crumble-release.jks has the alias crumble. Its password was not verified.
• Not run: the workflow on GitHub, or signing with the real key.

Risk & Rollback

Reversibility: Reversible for the code; a published release can be deleted, but installed APKs stay installed.

Blast Radius: Release builds and tag pushes. Debug builds and the Android checks workflow are unchanged.

Every future update must be signed with this keystore; losing it means users reinstall. A wrong ANDROID_KEYSTORE_PASSWORD fails the signing step on the first tag. Targets android-web-parity until #8 merges.