Play Store Uploads with Fastlane Supply: Part 4

Getting an Android app from a local build to Google Play often involves a surprising amount of repetitive work.

You need to build the correct artifact, manage versioning, authenticate with Google Play, choose the right release track, and eventually upload the application. As the number of releases increases, these manual steps become both time-consuming and error-prone.

This is where Fastlane Supply becomes useful.

Supply is Fastlane's Android tool for interacting with the Google Play Store. It allows you to automate application uploads and several parts of your Play Store release workflow directly from your Fastfile.

In this part of the series, we'll build on the workflow from Part 3 and look at how to automate Google Play uploads, release tracks, version codes, metadata, and deployment.

Step 1: Set Up Google Play API Access

Before Fastlane can communicate with Google Play, it needs to authenticate with the Google Play Developer API.

A typical setup consists of creating a Google Cloud project, enabling the required API, creating a service account, generating credentials, and then granting that service account access to your application in the Google Play Console.

1. Create or Select a Google Cloud Project

  1. Open the Google Cloud Console.
  2. Create a new project or select an existing project that you want to use for Play Store automation.

2. Enable the Google Play Developer API

Inside Google Cloud, locate the Google Play Android Developer API and enable it for your project.

This allows your automation workflow to communicate with Google Play through Google's developer APIs.

3. Create a Service Account

  1. Open IAM & Admin → Service Accounts.
  2. Create a service account for your deployment workflow.
  3. Create credentials for the service account.
  4. Download the JSON credentials file.
Important:

Creating the service account is not enough. The service account must also be granted the appropriate permissions in the Google Play Console before Fastlane can perform operations on your application.

4. Keep the Credentials Secure

Your service-account JSON file contains sensitive credentials. Never commit it directly to Git.

For local development, keep the credential outside your repository. For CI/CD, use your CI platform's encrypted secret management instead of storing the JSON file directly in source control.

Step 2: Configure Fastlane Supply

Once Google Play API access has been configured, Fastlane can use upload_to_play_store to upload your Android application. 

upload_to_play_store

The action can be used by itself, but in a real Android release workflow it is usually combined with Gradle so that Fastlane first creates the release artifact and then uploads it.

A Basic Release Lane

A simple release lane could look like this: 

platform :android do

  desc "Build the app and upload it to the Play Store"

  lane :release do

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

    upload_to_play_store

  end

end
Why use an AAB?

For Google Play distribution, the Android App Bundle (.aab) is generally the preferred release artifact. If your workflow specifically requires an APK, you can use the appropriate Gradle assemble task instead.

Step 3: Control Where the Release Goes

Uploading an application is only part of a release strategy. Google Play provides multiple release tracks that allow you to control how your application reaches users.

Common tracks include:

  • Internal testing
  • Closed testing
  • Open testing
  • Production

Fastlane allows you to specify the destination using the track parameter. 

upload_to_play_store(
  track: "beta"
)

This makes it possible to create separate deployment lanes for different environments. 

platform :android do

  desc "Upload to Play Store Beta"

  lane :beta do

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

    upload_to_play_store(
      track: "beta"
    )

  end


  desc "Upload to Play Store Production"

  lane :production do

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

    upload_to_play_store(
      track: "production"
    )

  end

end
Release strategy tip:

A mature pipeline does not necessarily deploy every build directly to production. You can progressively promote builds through testing tracks before releasing them to production.

Step 4: Automate Version Code Management

Android releases require a unique and increasing versionCode. When releases are created frequently, manually maintaining this value becomes another repetitive part of the release process.

Fastlane provides the increment_version_code action to automate this step. 

platform :android do

  desc "Increment version code, build and upload"

  lane :release do

    increment_version_code

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

    upload_to_play_store(
      track: "production"
    )

  end

end
Important:

Uploading an artifact with upload_to_play_store does not automatically mean that Fastlane will increment your versionCode. If you want Fastlane to modify the versionCode, explicitly include increment_version_code or use another versioning strategy.

Step 5: Trigger the Release

Once your Fastfile and Google Play authentication are configured, the release workflow can be triggered with a single command: 

fastlane release

Depending on the lane you've created, Fastlane can then:

  1. Increment the version code.
  2. Build the release AAB.
  3. Authenticate with Google Play.
  4. Upload the artifact to the configured track.

If you created separate lanes for different environments, you can trigger them independently. 

fastlane beta

or 

fastlane production

Step 6: Automate Play Store Metadata

The application binary is only one part of a Play Store release. A production release can also contain descriptions, release notes, screenshots, localized content, and other store metadata.

Keeping this information under version control makes the release process more reproducible and easier to automate.

Fastlane can work with Play Store metadata as part of your release workflow. For example: 

upload_to_play_store(
  metadata_path: "./metadata"
)

This approach allows your store metadata to live alongside your release automation rather than requiring every release to be prepared manually through the Play Console.

CI/CD Tip:

Metadata automation becomes especially valuable when Fastlane runs inside CI/CD. Your repository can become the source of truth for the release configuration, while the pipeline performs the repetitive deployment work.

🚀 Putting Everything Together

By combining the pieces we've covered, your Android release workflow can look like this: 

Developer
    ↓
Fastlane
    ↓
Run tests
    ↓
Increment versionCode
    ↓
Build Release AAB
    ↓
Authenticate with Google Play
    ↓
Upload to Internal / Beta / Production
    ↓
Release

A Practical Release Lane

Bringing the core concepts together, a simple production-oriented lane could look like this: 

platform :android do

  desc "Build and deploy Android app"

  lane :deploy do

    increment_version_code

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

    upload_to_play_store(
      track: "production"
    )

  end

end

Wrapping Up

With Fastlane Supply, the Play Store no longer needs to be a completely manual step in your Android release process.

You can automate the journey from building your application to selecting a release track and uploading the final artifact. You can also bring version management and Play Store metadata into the same automation workflow.

The bigger idea is not simply uploading an AAB with one command. It's about making the release process repeatable, predictable, and automation-friendly.

And when this workflow moves into CI/CD, Fastlane becomes an important automation layer between your Android build system and Google Play.

In the next part, we'll move beyond the application binary and automate another time-consuming part of Android releases: generating and managing screenshots with Screengrab. 🚀

LinkedIn: https://www.linkedin.com/in/vikas-soni-052013160/

Email: vikasacsoni9211@gmail.com

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

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

🗂️ 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

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