# Google Play release checklist ## External account gate - [x] Google Play developer identity verification approved. - [x] Contact phone verification completed. - [x] Play Console enables **Create app**. ## App identity and signing - [x] Create Android app `Who Need Help` with package `org.whoneedhelp.mobile`. - [x] Default language: English (United States). - [x] App: not a game; free; no ads. - [x] Accept Play App Signing. - [x] Record the upload-certificate SHA-1 and SHA-256 with the source-bound candidate. - [x] Record every Play App Signing SHA-1 and SHA-256 displayed by Play after the first AAB upload makes Play generate its signing identities and before any tester rollout. Do not assume that a new app has only one Play certificate: current Play quantum-ready hybrid signing can expose multiple classical/post-quantum identities for different Android generations. The protected identity document records all three Play identities shown for version `0.1.0 (1)` plus the independent upload identity; no certificate values are stored in this public checklist. - [x] Add every applicable Play App Signing SHA-1/SHA-256 identity to the production Google/Firebase Android configuration. A freshly downloaded production client configuration was validated after the import. - [x] Publish and verify `https://whoneedhelp.com/.well-known/assetlinks.json` for the Play certificate identities used to sign delivered APKs. Use `scripts/import-play-android-config.sh` in plan mode first, then `--apply`; it must match every Play SHA-1 to the production Firebase Android OAuth client and preserve the upload identity. ## Build - [x] Freeze the exact internal-release identity and localized release notes in `internal-release-v1.md`; final save/publish remains a separate explicit external action. - [x] Build from the exact committed candidate with the validated Android allow-list read from the production checkout’s single `.env`. - [x] Run `scripts/android-release-build.sh`. - [x] Verify source fingerprint, signing certificate, bundletool validation, lint, package name, version code/name, target SDK, and production origin. - [x] Install the release APK generated from the same source-bound build on the authorized physical phone and run the release smoke test. - [x] Save and publish the source-bound AAB currently uploaded to the internal testing draft. Do not mark this complete until Play Console shows one accepted artifact and the internal release is available to testers. The exact `0.1.0 (1)` release is active only on the Internal testing track; no Closed or Production rollout was started. - [x] Build and locally validate source-bound candidate `0.1.2 (3)` from commit `cd15476`; release tests, lint, signing, bundle validation, App Links validation and API 37 instrumentation passed. The candidate is documented in `internal-release-v3.md`; its subsequent Internal-track upload and Play-delivered verification are recorded in the next item. - [x] Upload the exact recorded `0.1.2 (3)` AAB to Internal testing, install it through Google Play and repeat the strict physical-device verification. Play Console showed release `0.1.2 Location consent clarity` available to internal testers on 2026-08-10 with one version code and no Closed or Production rollout. The installed package was delivered by `com.android.vending`; its Play signing identity, version, verified production App Link, and `MainActivity` resolution passed the strict verifier. ## Production capability gate - [x] On 2026-08-08, run the current candidate validator against the live production `.env` with `--require-server-release`: all twelve capability checks reported `READY`, with zero blocking items and zero local-only warnings. The validator did not print secret values and did not modify production. - [x] Pass the stricter `--require-release` gate. On 2026-08-09 the live production `.env` reported all twelve capabilities `READY`, with zero blocking items and zero local-only warnings after the Play identities were imported. ## Store presence Complete the mandatory foreground-service declaration under **App content** before attempting to publish Store Presence changes. The current Play Help states that an unresolved permissions declaration for an active bundle can block publishing changes, including Store Listing, Pricing, and Distribution. - [x] 512×512 Play icon prepared. - [x] 1024×500 24-bit PNG feature graphic prepared. - [x] Four current 1080×1920 physical-phone screenshots captured and reviewed. - [x] English, Ukrainian, and Russian listing copy prepared. - [x] Alt-text copy (≤140 characters) prepared in `store-assets/README.md`. - [x] Revalidate the exact prepared listing text and visual assets immediately before Console entry. On 2026-08-10 the repository validator passed all three localized text limits, the 512×512 icon, the 1024×500 RGB feature graphic, and all four 1080×1920 RGB phone screenshots. - [ ] Enter the prepared alt text when the assets are uploaded in Play Console. - [ ] Choose category/tags in the current Console options. - [ ] Complete **Select an app category and provide contact details** in Play Console. Read-only Dashboard inspection on 2026-08-10 showed this task incomplete; no values were selected or saved during that inspection. `contact@whoneedhelp.com` must not be entered yet: a same-day public DNS check found no MX record and no observed SMTP greeting on the web-server address, so inbound delivery has not been demonstrated. Configure and test that mailbox/forwarder, or deliberately choose another monitored public support address, before saving the field. - [ ] Complete **Set up your store listing** in Play Console using the prepared localized copy and assets. The same Dashboard inspection showed overall app setup at 9 of 11 tasks. - [ ] If the truthful category remains **Social**, publish and verify the `/child-safety` standards, select a monitored child-safety point of contact, verify that contact can access the urgent queue, and complete the Play child-safety self-certification only from observed operational evidence. Adult-only positioning does not remove this requirement for an app declared as Social. A repeated public check on 2026-08-10 returned `200` from `https://whoneedhelp.com/child-safety` after production was observed on local revision `dafcdb36`. The frozen hackathon test remains intentionally unchanged and returns `404`. The public page is only one gate: do not self-certify until the monitored contact and real escalation workflow are also verified. ## App content - [x] Privacy policy URL saved as `https://whoneedhelp.com/privacy`. - [x] Ads declaration saved: no ads. - [x] Both App access accounts and both sides of the reviewer instructions tested from a clean Play-delivered install. - [x] Target audience/adult-only positioning saved as **18 and over**. - [x] Content rating questionnaire completed and saved truthfully. The current Console result is BR 12+, North America Teen, Europe parental guidance, Germany 12+, and 12+ in the other displayed regions; this is a Console result, not a product age-verification claim. - [x] Local Data Safety worksheet reconciled with the source-bound candidate, a fresh resolved release dependency report, and the published privacy and account-deletion pages. - [x] Enter and review those reconciled answers in the current Play Console Data Safety form. The form was saved on 2026-08-09, and the overall Publishing overview was deliberately not sent for review. - [x] Account deletion questions and external URL completed. - [x] Government, financial, and health declarations saved from actual app behavior: not a government app, no financial features, and Healthcare services and management only. The app is not described as a medical service. - [ ] Complete the mandatory Play Console foreground-service declaration for the `location` service used by the exact AAB. Read-only inspection on 2026-08-10 showed this as the only App content item under `Need attention`. A repeated read-only inspection showed all task choices unchecked, with **Save** and **Discard** disabled. The truthful prepared choice is **User-initiated location sharing**; no incomplete form was saved or submitted. - [ ] Upload the unlisted demonstration video showing the user-triggered start, prominent disclosure, Android permission, persistent notification, minimized-app operation, and Stop action. The final local 21.379802-second Play-delivered evidence file has been visually and server-side verified; its exact path and checksum are recorded in `location-and-fgs-declaration.md`. Hosting it as an unlisted video and saving the resulting URL in Play Console remain incomplete. Immediately before upload on 2026-08-10 the exact final file was revalidated as H.264, 720×1600, 21.379802 seconds, SHA-256 `3c5f52019bf8a42ff42e1d9232afc126b62627390d74eed75084d82ecb33ac56`; a fresh contact-sheet review still showed the disclosure, Android prompt, minimized persistent notification with Stop, and returned stopped state. - [ ] Reconcile any target-SDK-37 persistent precise-location declaration shown by Play Console with the exact artifact. The app uses a user-started location foreground service and does not declare `ACCESS_BACKGROUND_LOCATION`; do not answer that it requests the background-location runtime permission. - [ ] Use and verify the prepared declaration copy in `location-and-fgs-declaration.md`. ## Testing - [x] Internal track smoke test passed. Before exercising product flows, run `scripts/verify-play-installed-android.sh` with the protected Play identity document, physical-device serial, and exact expected version. It must confirm the Google Play installer, Play signing identity, verified production App Link, and `MainActivity` resolution. The 2026-08-09 v2 physical-device replay passed that verifier, Google sign-in, production App Link routing, Android notification permission, production FCM receipt and notification-tap routing. The same Play-delivered build then passed the separate consent-driven foreground location flow: explicit disclosure, Android permission, persistent notification, minimized-app sampling, notification Stop cleanup, offline/reconnect, and stopped-process recreation without sticky tracking. On 2026-08-10 the Play-delivered v3 install passed the strict delivery-boundary verifier and a new production fixture replay observed the disclosure, Android runtime prompt, active in-app state, minimized foreground-service notification, 41 server samples, notification Stop, and zero retained raw positions after Stop. The run-scoped fixture was then deleted and both production and frozen-test readiness remained healthy. This verifies observed app behavior; it does not complete the separate Play Console policy declarations or the final video above. The strict verifier passed again on 2026-08-10 after the physical phone was reconnected: Google Play installer, version `0.1.2 (3)`, Play signing identity, verified production App Link, and `MainActivity` resolution all matched the protected production identity record. - [ ] Closed track created and opt-in link tested. - [ ] At least 12 testers continuously opted in for 14 days. - [ ] Tester feedback and fixes documented. - [ ] Production-access questionnaire completed from actual evidence. On 2026-08-10 Play Console showed Closed testing locked until the two remaining app-setup tasks are complete and reported `0 testers currently opted-in`. No Closed or Production release was created during this inspection. ## Publishing - [ ] Managed publishing enabled if desired. - [ ] Countries/regions and support contact reviewed. - [ ] Production submission reviewed for accidental test URLs or credentials. - [ ] Rollback and support/incident response are ready. Official references: - https://support.google.com/googleplay/android-developer/answer/9859152 - https://support.google.com/googleplay/android-developer/answer/9842756 - https://support.google.com/googleplay/android-developer/answer/9866151 - https://support.google.com/googleplay/android-developer/answer/9859455 - https://support.google.com/googleplay/android-developer/answer/10787469 - https://support.google.com/googleplay/android-developer/answer/13327111 - https://support.google.com/googleplay/android-developer/answer/14151465