The platform posts one notification per download, so queueing an album buries
the UI in them and they can be swiped away. Hiding them (VISIBILITY_HIDDEN,
which needs DOWNLOAD_WITHOUT_NOTIFICATION) and posting one aggregated
notification instead gives a single ongoing entry with the overall progress and
a Cancel action that stops everything in flight.
It is refreshed from the download state the poller already maintains, so it
tracks the engine without extra queries, and it is tied to this process: if we
are killed the downloads continue with no notification, which is the trade for
not writing a service.
- flake: pin build-tools and platform-tools to 37.0.0 instead of "latest", matching build.gradle.kts
- robolectric: run at sdk 35 (targetSdk) and re-record the golden
- manifest: allowBackup off, drop not-yet-used permissions
- theme: drop no-op status/nav bar colors (edge-to-edge)
- deps: kotlin 2.1.20, drop unused deps and test runner
- wrapper: regenerate jar from 8.11.1, add distributionSha256Sum
- remove stale README
replace the flutter project with a gradle/compose android app:
- nix flake dev shell (jdk21, android sdk 35, build-tools 37, gradle)
- material3 app with a placeholder screen
- roborazzi/robolectric screenshot tests with one golden
- carry over the existing launcher/notification assets
austinried