원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Flutter Android visual test
Interactive, on-device verification of a Flutter Android app — the "did my last change actually render correctly" check you'd otherwise do by squinting at an emulator. Builds and runs the app on a device or emulator, captures real screenshots via adb, reads the logs, and gives you enough evidence to answer did the change render correctly.
Works for any Flutter app, including multi-entry apps where the default entry point throws by design and a --target flag is mandatory. Android only — iOS needs a Mac and xcrun simctl, which is out of scope here.
When to use
- "Test the app / run it on Android / see the visual changes."
- "Did my UI fix work? Does this screen render correctly now?"
- "Compare the capture screen to this Figma design." (optional Figma add-on)
- Any request for empirical, on-device confirmation of a visual or runtime
change — even without the words "screenshot" or "logs".
How it works
- Follow `references/capture-loop.md` — the universal procedure: preflight,
launch in the background, wait for the first real frame, screenshot, capture logs, analyze the PNG against the change, report a verdict.
- For the Flutter specifics — the exact
flutter runcommand and flags,
the first-frame log signal, where Flutter logs, hot reload, and cold-build timing — read references/flutter.md.
- To navigate the UI before screenshotting, see
references/driving-the-ui.md. - When something looks off, see
references/troubleshooting.md. - (Optional) compare to a Figma design →
references/figma-comparison.md
(requires the Figma MCP server; skip entirely if you don't use Figma).
- Reached here with a non-Flutter Android app? See
references/other-frameworks.md or use the matching skill.
Bundled scripts
scripts/check-devices.sh, launch.sh, snap.sh, capture-logs.sh, stop.sh wrap the common adb/run commands with device disambiguation. capture-loop.md shows how they fit together.
