Skip to content

General: Test first launch and app updates on Android emulators - #722

Merged
d4rken merged 3 commits into
mainfrom
emulator-tests
Sep 24, 2026
Merged

d4rken merged 3 commits into
mainfrom
emulator-tests

Conversation

@d4rken

@d4rken d4rken commented Sep 24, 2026 •

Copy link
Copy Markdown
Member

What changed

No user-facing behavior change. Every PR now runs the app on Android 11 and Android 16 emulators:

  • a fresh install goes through onboarding and the dashboard's permission prompts;
  • the sponsor and upgrade screens are opened in both flavors;
  • an in-place update from the previous release has to keep the user's profile, supporter status and theme.

Technical Context

  • The upgrade test builds the previous v* tag as a FOSS debug APK and re-signs both APKs with a throwaway key. The published release APKs are release-signed, so a debug build can't update them in place.
  • The tests tap "Wait" when another app's "isn't responding" dialog appears, because the slow API 30 runner showed one for the launcher over onboarding. A dialog naming CAPod still fails the test.
  • Supporter status is unlocked through the real sponsor flow in the old build. The supporter record keeps an older storage format, and a record that fails to load silently counts as "not a supporter". Deleting that record after the upgrade makes the test fail.
  • The Play flavor test only covers the case without a Play Store: the google_apis images have no billing. The screen first shows "Google Play services are unavailable", then settles on "Prices unavailable".
  • The tests wipe eu.darken.capod, which debug builds share with the release application id. upgrade-test.sh refuses to run on anything that isn't an emulator, and the docs require ANDROID_SERIAL for the Gradle runs.

Adds :app-e2e, a self-instrumenting com.android.test module that drives the
real debug APK with UiAutomator, plus an Emulator tests workflow (API 30 and
36) modelled on Butler's.

- GoldenPathTest: onboarding, granting the dashboard's permissions through
  its cards and the system dialog, relaunch skips onboarding.
- SponsorPitchTest (foss): the pitch is reachable from the dashboard, a
  locked setting and the upgrade status.
- UpgradeScreenTest (gplay): without a Play Store the screen reports Play as
  unavailable and settles on "prices unavailable". No purchase is possible
  on these images.
- UpgradeTest (foss, via tools/upgrade-test.sh): the previous v* tag is
  built as fossDebug, both APKs are re-signed with the local debug key, and
  state set up in the old build must survive `install -r`.

The upgrade test becomes a supporter through the real sponsor flow in the
old build. The supporter record keeps a retained serialization schema and
an undecodable record silently reads as "not a supporter", so only a real
old-to-new APK install catches a regression that strips supporters. The
5-second heuristic itself stays covered by FossUpgradeViewModelTest. Removing
settings_foss after an upgrade makes afterUpgrade fail at "Upgrade active".

scrollTo swipes the screen instead of using UiAutomator's scrollable lists
because API 30 marks no Compose list as scrollable.
The unqualified connectedFossDebugAndroidTest in build-commands.md now
reaches :app-e2e, which clears and (through Gradle) uninstalls
eu.darken.capod on every attached device. Point it at :app-e2e with
ANDROID_SERIAL, and make upgrade-test.sh refuse a device whose
ro.kernel.qemu is not 1 (set on both the API 30 and 36 images). An
in-test check would not help: Gradle uninstalls the app when a run ends,
so a phone's data is gone either way.

Also note that afterUpgrade may only check state the baseline release's
own beforeUpgrade sets up, and fix two comments.
On the API 30 runner a 'Pixel Launcher isn't responding' dialog covered onboarding, so every test timed out. await and scrollTo now tap Wait on another app's ANR dialog, and fail if the dialog names CAPod.

The runner has no ~/.android/debug.keystore (debug builds there are signed with a fallback key), so apksigner failed. The upgrade script now re-signs both APKs with a throwaway key it generates per run.
@d4rken
d4rken marked this pull request as ready for review September 24, 2026 21:54
@d4rken
d4rken merged commit 57f7cbe into main Sep 24, 2026
22 of 23 checks passed
@d4rken
d4rken deleted the emulator-tests branch September 24, 2026 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant