Open-Source Testing · pedrovgs

Shot

Shot is an Apache 2.0-licensed Gradle plugin and Android library for screenshot testing on Android apps, including Jetpack Compose support. It automates UI regression detection by capturing, recording, and comparing screenshots across test runs with integrated reporting.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/pedrovgs/Shot

1.2k

GitHub stars

111

Forks

Kotlin

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	pedrovgs/Shot
Owner	pedrovgs
Primary language	Kotlin
License	Apache-2.0 — OSI-approved
Stars	1.2k
Forks	111
Open issues	63
Latest release	6.1.0 (2024-02-12)
Last updated	2026-01-16
Source	https://github.com/pedrovgs/Shot

What Shot is

Shot provides a Kotlin-based instrumentation testing framework with a ScreenshotTest interface and custom ShotTestRunner, integrating as a Gradle plugin. It supports traditional Android Views and Jetpack Compose, generates diff reports, and manages screenshot storage via adb with flavor and build-type configurations.

Quickstart

Get the Shot source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/pedrovgs/Shot.git2cd Shot3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Android App UI Regression Testing

Detect unintended visual changes across feature branches and releases by comparing current screenshots against baseline versions. Particularly effective for apps with complex custom Views or design-sensitive UIs.

Jetpack Compose Component Verification

Validate Compose component rendering consistency across different configurations and API levels. The library provides native Compose support without external wrappers, simplifying test setup.

Multi-Flavor Build Variant Testing

Automate screenshot testing for apps with multiple flavors and build types. Shot generates per-flavor tasks, allowing you to maintain separate screenshot baselines for different app variants.

Implementation considerations

Requires testInstrumentationRunner configuration in build.gradle and custom AndroidManifest.xml with sharedUserId for SDCard write access.
Screenshots must be committed to version control as baselines; diff reports are generated per test run but baselines need manual review and approval.
Emulator GPU mode should be set to swiftshader_indirect for Compose tests to avoid rendering inconsistencies in CI environments.
API 28+ requires adb commands to enable non-SDK interface access; ensure CI environment has adb available and necessary permissions.
For Android libraries, testApplicationId must be configured separately to avoid conflicts with other installed apps.

When to avoid it — and what to weigh

Web-Only Projects — Shot is Android-specific. Web applications require different screenshot testing tools (e.g., Percy, BackstopJS, Puppeteer).
Real Device Testing Required — Shot relies on emulator execution and adb access. If your CI/CD environment cannot run Android emulators or lacks adb, deployment will be difficult.
Low-Touch Integration Needed — Integration requires modifying build.gradle, AndroidManifest.xml, configuring test runners, and managing screenshot baselines in version control—not suitable for lightweight, minimal-config setups.
API 28+ Without Non-SDK Access — Shot on API 28+ requires enabling non-SDK interface access via adb commands. Environments that cannot execute these commands (locked CI systems) will face blockers.

License & commercial use

Apache License 2.0 (Apache-2.0). Permissive OSI-approved license allowing commercial use, modification, and distribution with attribution and liability disclaimer.

Apache 2.0 is a permissive license compatible with commercial use. You may use Shot in proprietary Android projects, modify it, and distribute modified versions. Retain license notices and disclaimers. No patent grant or indemnification; review Apache 2.0 terms if patent concerns exist.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Moderate
DEV.co fit	Good
Assessment confidence	High

Security considerations

Shot uses adb for device communication and SDCard file I/O; ensure emulators/devices run in isolated CI environments. Non-SDK interface access (API 28+) via adb policy flags operates outside Google's public API guarantees—monitor for breaking changes in future Android versions. No encryption for stored screenshots; treat baselines as potentially sensitive UI data.

Alternatives to consider

Roborazzi

Kotlin/Compose-native screenshot testing library with built-in Paparazzi integration; may offer simpler setup for Compose-only projects but less mature than Shot.

Facebook Screenshot Tests for Android

The canonical Android screenshot testing library (Shot's README cites its documentation). Requires more manual configuration but has wider adoption in large Android codebases.

Pixelated / Manual Espresso + Image Diff

Custom approach using Espresso tests + external image diffing tools (ImageMagick, Perceptual Diffs). Offers full control but requires significant scaffolding and maintenance.

Software development agency

Build on Shot with DEV.co software developers

Shot integrates into your Gradle workflow to catch visual regressions before production. Start with the README examples and evaluate for your team's CI/CD setup.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

react-screenshot-test roborazzi jest-image-snapshot

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Testing AI Application Development DevOps Talk to DEV.co

Shot FAQ

Can Shot run in headless CI without a graphical display?

Yes, Shot works with headless Android emulators (no GPU required for recording/comparing), but requires adb and emulator binary support. GPU mode swiftshader_indirect is recommended for Compose tests to avoid rendering issues.

How are screenshot baselines stored and updated?

Baselines are stored in the project directory (per flavor/build type) and committed to VCS. Running `./gradlew executeScreenshotTests -Precord` updates baselines locally; you must review and commit changes to version control.

Does Shot support testing across multiple Android API levels?

Shot tests run on a single target emulator/device. To test multiple APIs, run tests multiple times on different emulator configurations or use flavor/build-type variants with separate baselines.

What happens if a screenshot test differs from the baseline?

Shot generates a diff report showing expected vs. actual screenshots and visual deltas. The build fails; you must review the diff, update the baseline if intentional, or fix the code.

Work with a software development agency

Adopting Shot is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source testing software in production.

Ready to automate Android UI testing?

Shot integrates into your Gradle workflow to catch visual regressions before production. Start with the README examples and evaluate for your team's CI/CD setup.

Talk to DEV.co Schedule a Consultation