chore(android): allow versionName to be set at build time

[fanzeyi]

Related issue

N/A — build configuration chore.

Summary

• versionCode was already overridable with -PversionCode=…, but versionName
  was a hardcoded literal, so every release build required editing
  app/build.gradle.kts and committing the bump. Both are now overridable at
  build time, with the checked-in values as defaults.
• Added a buildProperty() helper that reads a Gradle property and treats blank
  as absent. This also fixes an existing rough edge: -PversionCode= with an
  empty value (what the CI workflow passes on PR-triggered runs, where the
  dispatch inputs are unset) was taken literally instead of falling back.
• Threaded a new optional version-name input through the Android Bundle
  workflow and quoted both -P args so an empty value stays a single token.
• Documented the override in web/android/README.md under a new "Versioning"
  heading, and removed the two now-stale "bump versionCode in
  app/build.gradle.kts before each upload" instructions.

Note: the repo's Bump Version workflow still only bumps the Python packages, so
the checked-in versionName default can drift from the release version. Folding
Android into scripts/update_versions.py is left for a follow-up.

Test Plan

Verified the property plumbing at configuration time with a throwaway Gradle init
script that reflects into android.defaultConfig and prints the resolved values:

cd web/android
./gradlew -I /tmp/print-version.gradle.kts help -q                              # name=0.1.3     code=9
./gradlew -I /tmp/print-version.gradle.kts help -q \
  -PversionCode=42 -PversionName=9.9.9-rc1                                      # name=9.9.9-rc1 code=42
./gradlew -I /tmp/print-version.gradle.kts help -q "-PversionCode=" "-PversionName="  # name=0.1.3 code=9

All three matched expectations: defaults apply with no flags, overrides take
effect, and blank values fall back to the defaults (the CI PR-event path).
pre-commit run --files … passes; ktlint rewrapped the helper's signature.

Demo

N/A — no user-visible surface; build configuration only.

Type of change

• Bug fix
• Feature
• UI / frontend change
• Refactor / chore
• Docs
• Test / CI
• Breaking change

Test coverage

• Unit tests added / updated
• Integration tests added / updated
• E2E tests added / updated
• Manual verification completed
• Existing tests cover this change
• Not applicable

Coverage notes

The change is Gradle build configuration, which the test suites do not cover.
Verified manually via the three ./gradlew invocations above, asserting the
resolved versionCode/versionName for the default, overridden, and
blank-value cases. The existing Android Bundle workflow also runs
bundleRelease on PRs touching web/android/**, so this PR exercises the
blank-input path in CI.

[omnigent-ci]

Polly AI Review

Review: chore(android): allow versionName to be set at build time

Blocking issues

None. The Gradle plumbing is correct: buildProperty() reads the property, treats blank as absent (isNotBlank()), and falls back to the checked-in defaults (9 / "0.1.3"). The workflow quotes both -P args so an empty value stays a single token, and inputs.version-code/inputs.version-name resolve to empty strings on the pull_request trigger (the inputs context is only populated for workflow_dispatch/workflow_call), which now safely falls back to defaults. The defaults preserve prior behavior for local/debug builds.

Security vulnerabilities

• Non-blocking (hardening): version-name is interpolated directly into the run: shell script via ${{ inputs.version-name }}. This is the standard GitHub Actions expression-injection surface — a value containing a quote/$() could break out of the quoted token. Realistic risk here is low because the input only comes from workflow_dispatch (requires repo write access to trigger) and is never set on pull_request runs. Still, the safe pattern is to pass it through env: and reference "$VERSION_NAME" in the script. Same applies to the pre-existing version-code. Worth doing but not required to merge.

Non-blocking notes

• The PR description says -PversionCode= was previously "taken literally instead of falling back." That's inaccurate for versionCode: the old code used toIntOrNull(), which already returned null on an empty string and fell back to 9. The blank-handling in buildProperty() is genuinely new/needed only for versionName (no numeric parse to swallow the empty value). Behavior is correct either way; only the rationale is slightly overstated.
• The known drift between the checked-in versionName default and the Bump Version workflow is already called out and deferred to a follow-up — reasonable.
• Docs correctly remove the now-stale "bump versionCode before each upload" edit instructions and add the override guidance; the versionCode-per-upload requirement is retained under the new "Versioning" heading.

Summary

A clean, well-scoped build-configuration change that makes versionName overridable at build time to match the existing versionCode override, with sensible blank-as-absent fallback and matching workflow/doc updates. No correctness bugs; the manual verification covers the default, override, and blank-input paths. The only thing worth acting on is the standard GitHub Actions expression-injection hardening (pass inputs via env:), which is a non-blocking improvement given the dispatch-only exposure. Approve.

---

_{Automated review by Polly · workflow run}

[github-actions]

🏷️ Doc impact: no-doc-update

This only changes Android build/versioning tooling (CI workflow input, Gradle version overrides, and the internal web/android/README.md), not any user-facing Omnigent surface, integration, or built-in policy.

_{Auto-classified on merge. Set the label manually before merging to override. · run}