Automate pre-release test-APK flow for feature/fix branches and PRs to main

[ShubhamJ010]

Context

While testing Issue #2 (lowering minSdk to 29), we needed a way for users/QA to grab a sideloadable APK of a feature branch without waiting for a tagged release. We did this ad-hoc: a manually created pre-release (apk-test-issue-2) holding the locally built signed APK, plus a build-apk.yml workflow that uploads a debug APK artifact.

That works, but it is manual and inconsistent — the pre-release tag has to be created by hand, there's no cleanup of old test builds, naming isn't tied to the branch/PR/commit, and the two mechanisms (manual pre-release vs CI artifact) aren't unified. This should be a first-class, automated part of CI/CD.

Goal (industry practice)

Every push to a feature/** or fix/** branch, and every PR opened/updated against main, should automatically produce a downloadable, installable test APK that anyone can grab from the pipeline — no local build, no manual release tagging. This is the standard "test build / pre-release" pattern used by most mobile CI setups.

Proposed approach

Enhance .github/workflows/build-apk.yml (or add a companion test-release.yml) so it:

• Builds a sideloadable APK on the same triggers we already use (feature/**, fix/** pushes; PRs to main; workflow_dispatch).
• Publishes it as an automated pre-release / "test build" keyed to the source:
  • Branch pushes → pre-release tagged like test-<branch-slug> (e.g. test-feature-issue-2-lower-minsdk-api29).
  • PRs to main → pre-release tagged like pr-<number> (e.g. pr-4), updated in place on each push.
  • Asset name includes the short SHA and build type (e.g. ssjanitor-<sha>-debug.apk).
• Reuses the existing upload-artifact step so the APK is also available as a pipeline artifact (faster download, no release page needed).
• Cleans up stale test pre-releases (e.g. keep the latest N per branch/PR, or delete the PR pre-release when the PR is closed/merged) to avoid tag/Release clutter.
• Handles signing gracefully: CI has no keystore, so it must clearly label the artifact as debug-signed for sideloading; optionally allow a release-signed APK when repo secrets (SIGNING_KEY, KEYSTORE_PASSWORD, KEY_ALIAS, KEY_PASSWORD) are configured, falling back to debug otherwise.

Acceptance criteria

• A push to any feature/** or fix/** branch yields a downloadable test APK automatically (no manual steps).
• Opening/updating a PR to main yields a downloadable test APK, refreshed on each push.
• Test pre-releases are clearly named/labeled and linked to their branch/PR/commit.
• Old test pre-releases are pruned (no unbounded growth of tags/Releases).
• The flow is documented in docs/ (e.g. docs/testing.md or a CI section) so contributors know where to grab a test build.
• Debug vs release signing is explicit and the fallback path is safe.

Out of scope

• Promoting a test build to a real SemVer release (that stays manual via the existing release.yml).
• Unit/instrumentation test coverage (separate concern, handled by ci.yml).

References

• Current manual pre-release: apk-test-issue-2 (attached APK for Issue Feature Request: Lower minSdkVersion to support older Android versions (Android 10 / 12) #2 testing).
• Current workflow: .github/workflows/build-apk.yml (artifact only).
• Related: Feature Request: Lower minSdkVersion to support older Android versions (Android 10 / 12) #2 (lower minSdk), PR Lower minSdk to 29 (Android 10) — closes #2 #4.