test: add end-to-end smoke tests covering every demo activity

[kikoso]

Problem

Following up on a pull request currently means cloning it, building it, and clicking through every screen of the sample app to confirm nothing regressed. That is slow, easy to skip, and the coverage varies with whoever is reviewing.

What this adds

Two instrumentation tests in maps-app, both driven off allActivityGroups in Demo.kt, the single registry that already builds the on-screen demo list. A demo added to the app is covered automatically, with no change to either test. That is the property that makes this worth having rather than another list to keep in sync.

DemoAppSmokeTest

Parameterized over all 22 demos, two checks each:

• demoLaunchesAndShowsMap: the activity reaches RESUMED, a MapView or StreetViewPanoramaView is attached, visible and non-zero sized, and nothing crashed on a background thread. The map surface is polled rather than checked once, because AndroidView lays it out a frame or more after the activity resumes.
• demoSurvivesConfigurationChange: the same checks, then recreate(), then the same checks again. Configuration changes are where camera and marker state holders tend to regress and are tedious to verify by hand.

Map content is deliberately not asserted. Whether a particular marker or overlay is drawn belongs in the focused tests alongside this one; the value here is breadth.

DemoRegistryTest

Guards the registry itself. A demo is described in two places that have to agree: allActivityGroups and AndroidManifest.xml. Adding it to one and not the other compiles, builds, and only fails when someone taps the entry. Four checks: every demo resolves via PackageManager, is enabled, has non-blank title and description strings, and is not registered twice.

Verification

Run against a Pixel 8 emulator (API 36) with a valid Maps API key:

Suite	Result
DemoAppSmokeTest	44 tests, 0 failures, 0 errors, 0 skipped, 138.6s
DemoRegistryTest	4 tests, 0 failures
:maps-app:lintDebug	BUILD SUCCESSFUL, 0 issues

All 22 demos launch, show a map surface, and survive recreation today, so no demo needed an exemption and DEMOS_WITHOUT_MAP_SURFACE is empty.

Cost

DemoAppSmokeTest adds about 2.5 minutes to the emulator job, which currently runs 16 to 28 minutes. If that proves too much for the pull request gate, demoSurvivesConfigurationChange is the half to move to a nightly run: it roughly doubles the class's runtime and catches the rarer class of bug.

Notes

Both tests skip rather than fail when no Maps API key is configured, via assumeTrue(hasValidApiKey), matching how forks run CI without access to the secret. Worth knowing when reading a green run from a fork: the emulator job injects the key, so skipping only happens where the secret is genuinely unavailable.

[github-actions]

Coverage (unit tests)

No unit baseline recorded in coverage/history.csv yet, so this run only reports absolute numbers.

Module	Line %	Change	Branch %	Change
maps-compose	0.00%	new	0.00%	new
maps-compose-utils	2.04%	new	0.49%	new
maps-compose-widgets	0.00%	new	0.00%	new
TOTAL	0.42%	new	0.09%	new

_{Line and branch coverage from unit test reports. History is recorded in coverage/history.csv after each merge to main.}

[kikoso]

Added three commits:

• CI on API 36: emulators never update Google Play services, and older images bundle a version that crashes inside Play services when adding advanced markers (found in test: add end-to-end demo smoke test android-maps-utils#1805).
• CI on Ubuntu with KVM: on macOS-latest-large the API 36 emulator took over five minutes to boot and the job hit its 30 minute timeout. Timeout raised to 45 minutes.
• Zoom check: demoLaunchesAndShowsMap now zooms each map out and back in. With requireMapLoaded=true (passed by CI when ACTIONS_API_KEY is available) it also waits for tiles to render.

Locally on an API 34 emulator with a real key: DemoAppSmokeTest 44/44 pass with requireMapLoaded=true.

[kikoso]

Added the menu flow:

• DemoMenuNavigationTest (new): starts MainActivity, taps each demo's group and entry, waits for its map, and presses back to the menu, so a broken menu entry, click handler or back navigation is caught. DemoAppSmokeTest still launches each demo directly for the in-depth checks.
• DemoRegistryTest.everyDeclaredActivityIsInTheMenu (new): the reverse of the manifest check, failing when a demo activity is declared but missing from the menu.
• Test tags on the menu cards in Demo.kt, the only app change.

Locally on an API 34 emulator: DemoMenuNavigationTest 22/22 (about 1 minute), DemoRegistryTest 5/5.

[googlemaps-bot]

Code Coverage

Overall Project	24.66% -0.08%	❌
Files changed	0%	❌

File	Coverage
Demo.kt	0% -1.73%	❌

[kikoso]

Split the smoke tests from the regular instrumentation tests:

• DemoAppSmokeTest, DemoMenuNavigationTest and DemoRegistryTest moved to com.google.maps.android.compose.smoke.
• New Demo smoke test workflow runs only that package on API 36 with KVM, a real key and requireMapLoaded=true. It skips with a notice when ACTIONS_API_KEY is not available.
• Run instrumentation tests now excludes the package (notPackage) and is otherwise back to what it is on main (macOS, API 29, 30 minutes), so coverage history stays comparable.
• Fixed a flaky wait: DemoAppSmokeTest now zooms a map that is fully on screen, which matters for MapsInLazyColumnActivity.

Locally: package=smoke runs 71/71 (44 + 22 + 5) with requireMapLoaded=true, and notPackage=smoke runs the 41 other tests, all passing.

[dkhawk]

LGTM with a few minor observations and suggestions:

1. assumeValidApiKey in DemoMenuNavigationTest: The PR description notes that both suites skip when an API key is not present via assumeTrue(hasValidApiKey). DemoAppSmokeTest has this, but DemoMenuNavigationTest appears to be missing the @Before check (or assumeValidApiKey()). Adding it will prevent unexpected timeouts if someone runs the smoke suite locally without a key in secrets.properties.
2. Defensive scroll on group headers: In DemoMenuNavigationTest, adding .performScrollTo() before .performClick() on groupTestTag(group) would protect against smaller screens or landscape orientation where lower groups might be below the fold.
3. StreetView coverage in navigation: In DemoMenuNavigationTest, DEMOS_WITHOUT_MAP exempts StreetViewActivity because findMapView only looks for MapView. Since StreetViewPanoramaView supports getStreetViewPanoramaAsync, supporting both (like DemoAppSmokeTest does with mapSurfaces) would eliminate the exemption.
4. Background crash detection: DemoAppSmokeTest's uncaught exception handler is great. Consider applying the same check to DemoMenuNavigationTest, and also checking assertNoUncaughtExceptions() in @After tearDown() to catch any crashes during activity teardown.

Overall, the design is excellent—generating the test matrices directly from allActivityGroups and keeping the manifest in sync via DemoRegistryTest makes this completely maintenance-free.

[kikoso]

Thanks @dkhawk! Pushed c189955 with these:

1. API key in DemoMenuNavigationTest: I didn't add assumeTrue here, for two reasons. Without a key the maps still become ready, so the menu test runs fine (I ran it locally with YOUR_API_KEY). And in this repo a failed assumption is reported as a failure, not a skip: without a key, all 44 DemoAppSmokeTest cases show up as failed with AssumptionViolatedException. That also affects the assumeValidApiKey() tests from test: skip map instrumentation tests when no Maps API key is available #1016, I think it's worth a follow-up. The one case that does need a key is StreetViewActivity (it waits for a Street View metadata request), so without a key that demo is only checked for opening. With the change, the menu test is 22/22 both with and without a key.
2. Scroll before clicking: done, it now scrolls the LazyColumn to the group and then to the demo (performScrollToNode), since items below the fold are not composed until the list scrolls to them.
3. StreetView: done, the exemption is gone and it waits for the StreetViewPanoramaView. This one was interesting: it timed out at first even with a key, because the compose rule drives the frame clock of every composition in the process, and the panorama only shows after a recomposition that follows the async request. The wait now advances mainClock.
4. Background crashes: done, DemoMenuNavigationTest installs the same handler, and both tests also check in @After. I also made tearDown only restore the handler it replaced: when the key check skipped a test, it was restoring null.

Locally with a real key: 71/71 (44 + 22 + 5).

[kikoso]

Correction on point 1: I mixed up the report with the build result. As #1016 notes, AGP records skipped assumptions as <failure> in the XML, but the build still passes, and keyless Dependabot runs have been green since. So no follow-up is needed for #1016. Not adding the assumeTrue here still makes sense, since the menu test doesn't need a key.