Automating Android Screenshots with Fastlane Screengrab: Part 5

Turn Play Store screenshot generation into a repeatable, deterministic part of your Android release pipeline.

In this part We'll explore how Fastlane Screengrab can automate Android screenshot generation, how screenshot tests fit into the workflow, how to handle locales and device configurations, and why deterministic screenshot generation matters when the same workflow eventually runs in CI/CD.

In Part 4, we used Fastlane Supply to automate one of the most important parts of Android delivery: publishing the application to Google Play.

But a production release is not just an AAB uploaded to Google Play.

A Play Store release also contains supporting assets such as screenshots, descriptions, release notes, graphics and localized content.

And screenshots are particularly interesting because they are not simply static files.

They are generated from a running version of your application on a specific device configuration and application state.

That makes screenshot generation a perfect candidate for automation.

A screenshot should be a build output,
not a manual release task.

This is the mindset we will use throughout this article.

Instead of asking:

"Who is going to capture the Play Store screenshots?"

we want our release system to answer:

"Which version of the application should generate which screenshots, on which configuration, and where should those artifacts go?"
Android Source
↓
Build
↓
Install on Test Device
↓
Screenshot Test
↓
Screengrab
↓
Screenshot Artifacts

Step 1: Understand What Screengrab Actually Does

Before configuring anything, it is important to understand where Screengrab fits in the architecture.

Screengrab is not a replacement for your Android UI testing framework.

Instead, it provides an automation layer around the screenshot-generation process.

Your application still needs a predictable way to reach the screens that you want to capture.

Important distinction

Screengrab automates screenshot capture. Your Android test code is still responsible for driving the application into the state you want to capture.

Step 2: Add Screengrab to the Project

If Fastlane is already configured as described in the previous parts, Screengrab can be added to the project using: 

fastlane add_plugin screengrab

This adds the Screengrab integration to the Fastlane project.

At this point, don't think about Play Store publishing yet.

First make sure the application can be built, installed and exercised reliably on the Android test environment.

Step 3: Prepare a Deterministic Android Test Device

Screenshot generation depends heavily on the device environment.

If the application behaves differently every time the test runs, your screenshots will also become unpredictable.

For local development, an Android Emulator created through Android Studio's Device Manager is usually the easiest starting point.

A predictable device configuration should control things such as:

  • Screen size and resolution
  • Android API level
  • Orientation
  • Locale
  • Application state
Why this matters for CI/CD

A screenshot pipeline that works only on one developer's laptop is not really release automation. The environment must eventually become reproducible.

Step 4: Create a Screenshot Test

Now we need to define what should actually be captured.

Think of the screenshot test as a small executable specification for your Play Store assets.

For example: 

@RunWith(AndroidJUnit4::class)
class ScreenshotTest {

    @Test
    fun captureHomeScreen() {

        // Launch application

        // Navigate to the Home screen

        // Prepare deterministic test state

        // Capture screenshot
    }

}

Your actual implementation will depend on the UI testing framework and application architecture you use.

Engineering principle

Don't build screenshot tests around random user flows. Build them around stable application states that you intentionally want to publish.

Step 5: Configure the Fastlane Screenshot Lane

Once the Android side is ready, we can expose screenshot generation through Fastlane.

A basic lane can look like this: 

platform :android do

  desc "Generate Android screenshots"

  lane :screenshots do

    screengrab(
      app_package_name: "com.yourapp.package",
      locales: ["en-US"],
      clear_previous_screenshots: true
    )

  end

end

Replace com.yourapp.package with your application's actual package name.

What does the configuration represent?

  • app_package_name identifies the application being tested.
  • locales defines the locale set used by the screenshot workflow.
  • clear_previous_screenshots helps prevent stale output from previous runs from being mixed with the new screenshot set.

Step 6: Run the Screenshot Workflow

Now the entire screenshot workflow can be triggered with: 

fastlane screenshots

Instead of manually launching the application, navigating to the required screens and capturing images, the process becomes executable.

Fastlane
↓
Screengrab
↓
Android Test
↓
Application State
↓
Screenshot Artifact

Step 7: Treat Screenshots as Release Artifacts

This is where screenshot automation becomes more interesting from a release-engineering perspective.

The generated screenshots should not be considered temporary files that disappear after a local test run.

They are release assets generated from a particular application version.

Conceptually: 

Release
├── Android AAB
├── Mapping files
├── Release notes
└── Screenshot assets

Once you think about screenshots this way, the next question becomes much more useful:

Can the same release pipeline generate every artifact required for a release?

Step 8: Handle Multiple Locales

Modern applications often publish their Play Store listings in multiple languages.

Screenshot automation becomes especially useful here because every additional locale increases the amount of repetitive manual work.

For example: 

screengrab(
  app_package_name: "com.yourapp.package",
  locales: [
    "en-US",
    "es-ES",
    "de-DE",
    "fr-FR"
  ]
)

The exact locale strategy should match the locales supported by your application and the Play Store markets you target.

The scaling advantage

Adding another locale should increase configuration, not increase manual release effort.

Step 9: Think About Device Configurations

Android runs across a wide range of screen sizes and configurations.

That doesn't mean you should generate screenshots for every device that exists.

Instead, define the device configurations that matter to your product and release requirements. 

Screenshot Matrix

Phone
├── Compact
├── Standard
└── Large

Tablet
├── Portrait
└── Landscape

The important engineering decision is not the number of screenshots. It is defining a reproducible screenshot matrix.

Don't optimize for device names

Optimize for the screen configurations and product experiences that your application actually needs to validate and publish.

Step 10: Make Screenshot Generation Deterministic

This is probably the most important part of screenshot automation.

A screenshot that changes between two identical builds is difficult to trust.

Several things can introduce unexpected differences:

  • Live network data
  • Current timestamps
  • Randomized content
  • User-specific state
  • Animations
  • Different emulator configurations

A Better Screenshot Environment 

Fixed Test Data
      +
Controlled Application State
      +
Predictable Device
      +
Stable Locale
      +
Controlled Network
      =
Deterministic Screenshot
CI/CD lesson

Screenshot automation is ultimately a test workload. If the test environment is not deterministic, the generated release assets will not be deterministic either.

Step 11: Connect Screenshots to the Release Pipeline

Now we can connect the screenshot stage with the release automation we created in the previous parts.

A simplified workflow might look like: 

platform :android do

  desc "Prepare Android release"

  lane :release do

    gradle(
      task: "test"
    )

    gradle(
      task: "bundle",
      build_type: "Release"
    )

    screengrab(
      app_package_name: "com.yourapp.package",
      locales: ["en-US"]
    )

    upload_to_play_store

  end

end

The exact ordering and configuration should be adapted to your project, especially when screenshot generation requires a specific test APK, instrumentation setup or build variant.

Source Code
↓
Validation
↓
Build
↓
Screenshot Generation
↓
Release Assets
↓
Play Store Deployment
One important distinction

Screengrab generates screenshots.

Supply handles Google Play deployment.

They solve different problems and become more powerful when composed into the same release workflow.

What Changed?

Before

Launch the application manually, navigate through screens, capture screenshots, switch devices or locales, rename files and repeat the process for every release.

After

Define the screenshot workflow once and generate a repeatable set of release assets through automation.

Developer
↓
Fastlane
↓
Android Test
↓
Deterministic Device
↓
Screenshot Artifacts
↓
Release Pipeline
The bigger picture

Screenshot automation may look like a small productivity improvement.

But the underlying principle is much larger: every repetitive release activity should become a reproducible, version-controlled step in the delivery system.

The Release Engineering Perspective

At this point in the Fastlane series, a pattern should be starting to emerge.

We started with individual developer tasks:

  • Building the application
  • Managing release configuration
  • Uploading to Google Play
  • Generating screenshots

We are gradually turning those individual actions into a release system.

Build → Test → Generate Assets → Version → Deploy

That is the real reason to learn Fastlane.

Wrapping Up

Play Store screenshots are easy to capture once.

The problem begins when you have multiple locales, multiple device configurations and frequent releases.

That is when manual screenshot management becomes another hidden release cost.

Screengrab gives us a way to turn that repetitive work into an executable workflow.

More importantly, it introduces a valuable release-engineering concept: release assets can be generated, validated and managed just like other build outputs.

And once builds, tests, screenshots and deployment are all represented as automation, the next natural step is to bring versioning and release information into the same system.

Coming Next — Part 6 We'll look at Android application versioning and changelog management — and how Fastlane can turn another manual release activity into a predictable, automated workflow.
Fastlane for Android — Part 5
Automating screenshot generation for a repeatable mobile release workflow.

Comments

Post a Comment

Featured Articles

Building a Production-Ready Kotlin Multiplatform Platform Kit: Lessons from My BlrKotlin x InMobi Talk

Image
How I built an open-source Kotlin Multiplatform reference project to help Android teams move beyond tutorials and start thinking about production-ready architecture. Last weekend, I had the opportunity to speak at the BlrKotlin x InMobi Android Meetup in Bengaluru, where I shared something I've been working on over the past few months—a practical Kotlin Multiplatform Platform Kit . Rather than giving another introduction to Kotlin Multiplatform, I wanted to focus on a question many Android teams eventually ask once they move past the excitement of "Hello World" examples: "We understand what Kotlin Multiplatform is—but how do we actually structure a project we'd be comfortable maintaining in production?" To answer that question, I built kmp-platform-kit , an open-source reference repository that demonstrates how to organize a Kotlin Multiplatform codebase with clean architecture, modular boundaries, and engineering decisions inspired by re...
Read more

Android Device Security: Sandboxing, Rooting, and Attestation Explained

Image
  As Android developers, understanding device security is essential to protect our apps and users. In this comprehensive guide, we’ll explore Android’s security architecture, including sandboxing, rooting and jailbreaking, and how to implement device attestation using SafetyNet and Play Integrity. We’ll cover each topic in detail, providing code snippets and best practices, following. What is Sandboxing in Android? Sandboxing is the security mechanism that isolates each app’s code and data from other apps and from the underlying system. In Android, this ensures that one app cannot freely read or modify another app’s private data or perform privileged operations unless explicit permissions or IPC channels are used.​ High-Level Idea Each app runs in its own isolated environment with: Its own Linux user ID (UID) and process. Its own private data directory (e.g., /data/data/<package_name>/ ). By default: One app cannot directly access another app’s files. An app cannot perfo...
Read more

đź—‚️ Heap Dumping Explained - LeakCanary's Bold Move

Image
Heap Dumping Explained — Why LeakCanary Freezes Your App to Find the Truth Learn what a heap dump is, when LeakCanary triggers one, why it briefly pauses your app, and how the resulting .hprof snapshot enables Shark to find real Android memory leaks. In the previous part of this series, we explored ObjectWatcher , the component that keeps an eye on destroyed Activities, Fragments, Views, and custom objects. But ObjectWatcher does not prove a leak on its own. It only tells LeakCanary that some objects still look suspiciously alive after they should have been garbage collected. That is the moment when LeakCanary makes its boldest move: it captures a heap dump . Heap dumping is the turning point in LeakCanary’s workflow. It briefly freezes the app, records a binary snapshot of memory, writes that snapshot to disk as a .hprof file, and passes it to Shark for analysis. [page:1] Table of Contents 1. What Is a Heap Dump? ...
Read more

JIT vs AOT Compilation | Android Runtime

Image
           D id you ever think, what happens when you install your app in your Android device, it shows INSTALLING for fraction of second and app get opens. What happens exactly behiend the scene? Found Interesting???? Cool !!! let’s clear all the doubt in this blog. You would have definetely read the buzz words JIT(Just-in-time) and AOT(Ahead of time) at many ocassions. We’ll dig it down in details in this article, stay tuned…. Android apps run on Android Runtime (ART) , which replaced Dalvik since Android 5.0 (Lollipop). ART supports both JIT (Just-In-Time) Compilation and AOT (Ahead-Of-Time) Compilation to improve performance and efficiency. JIT (Just-In-Time) Compilation How it Works: Compiles bytecode into native machine code at runtime (when the app is executed). Stores frequently used methods in memory to speed up subsequent executions. Advantages: Faster app installation because it doesn’t require full compilation beforehand. Reduces s...
Read more

Why Memory Leak Detection Shouldn’t Run on Your Device: Building LeakLens for Android Studio

Image
Why Memory Leak Detection Shouldn’t Run on Your Device How LeakLens moves Android heap analysis out of the app process and into Android Studio with a dual-layer model of static analysis and runtime inspection. You are in the middle of a refactor, your test device lights up, and a familiar notification appears: 4 retained objects, dumping heap. The report is useful, but the interruption is not. You pick up the device, inspect the notification, try to remember the class names, then jump back into Android Studio to find the source. That debugging loop is exactly the problem this article addresses. The core question is simple: why is the tool that finds memory leaks running inside the same application process you are trying to debug? [page:1] That question became LeakLens , an Android Studio plugin that moves memory leak analysis into the IDE instead of embedding an SDK inside the application. [page:1] Table...
Read more