Release smoke automation: 1.5 decision record

The 1.5 signed-release check used a small, local Python helper around ADB and Android’s UIAutomator hierarchy dump. It located visible text/content descriptions, tapped the observed bounds, and saved XML and screenshots. Separate command-line checks verified package/version metadata, signatures, artifact hashes, installation timestamps and crash logs. The helper and evidence remain under ignored build/release-validation; they are not a maintained test suite.

The journeys covered a fresh signed 1.5 installation, onboarding and About identity, then installation of signed 1.4, creation of sample household data, and adb install -r to signed 1.5. Upgrade assertions checked retained data and recipe-catalogue continuity without clearing application state. See the release validation record for results and limits.

The immediate need was a bounded check against the actual minified, signed APKs, with explicit control of baseline/candidate installation and evidence capture. ADB was already available, and a small helper made it straightforward to inspect the live hierarchy and collect those records without modifying the app.

This was a convenience and scope decision, not a demonstrated limitation of Maestro or another standard framework. Framework availability and existing automation should have been checked before writing the UI helper. A later focused check found no Maestro executable on PATH or existing Maestro flows in this repository; it did find Espresso/Compose instrumentation dependencies and existing Android tests. Those later findings do not retrospectively establish why a framework was not used.

Before the next recurring release check, inventory existing tools and journeys, then evaluate reusing a standard UI framework. Maestro is a candidate for external, installed-APK journeys; its Android documentation describes driving the rendered UI without adding app instrumentation. Confirm support for the chosen host and API-36 device in practice before adopting it.

Keep artifact/signature checks and baseline/candidate installation orchestration in ordinary build/ADB tooling. Put durable user journeys and their UI assertions in the selected framework, with explicit waits, failure diagnostics and repeatable reporting. Keep Kotlin/Compose and database tests for focused component and migration checks.

The first reusable journeys should be fresh setup and About identity, plus seeded 1.4-to-1.5-style upgrades that preserve application state across installation. Fresh-install reset steps must never leak into the upgrade phase. App-specific flows belong with Homey; generic CI execution belongs in the shared CI repository.

The local helper was adequate to collect this release’s evidence, but its custom text/bounds matching, manual orchestration and limited synchronization/reporting should not become the default automation architecture. This record proposes a later evaluation; it does not change the completed 1.5 checks or claim that a Maestro suite has been implemented or run.