Setting Up Fastlane in an Android Project: Part 2

Setting up Fastlane in an Android project

From a local automation tool to the foundation of a repeatable Android release workflow.

What we'll build In this part, we'll install Fastlane, initialize it inside an Android project, understand the files it creates, and design our first automation lanes.

More importantly, we'll establish an architectural boundary: Gradle builds the application. Fastlane orchestrates the delivery workflow.

In Part 1, we looked at why release automation becomes important as Android projects grow.

Building an APK or AAB is rarely the hardest part. The complexity usually appears around the build: validation, signing, versioning, artifact handling, screenshots, metadata, distribution and eventually CI/CD.

That's where Fastlane becomes useful.

Instead of giving developers a collection of commands and asking them to remember the correct order, we can encode the workflow as automation.

Developer / CI → Fastlane → Gradle → Artifact → Distribution

This separation will become one of the most important ideas in the series.

Step 1: Install Fastlane

Fastlane is a Ruby-based automation platform used to automate many parts of the mobile application delivery lifecycle.

On macOS, Homebrew provides one of the simplest ways to install it: 

brew install fastlane

You can also install Fastlane using RubyGems: 

gem install fastlane
Engineering note: installation is not reproducibility

Getting Fastlane installed locally is only the first step. A release pipeline should eventually control its toolchain versions so that local development and CI/CD don't silently use different environments.

We'll revisit reproducibility when we move this workflow into CI/CD.

Verify the Installation 

fastlane --version

If the command returns the installed Fastlane version, the installation is ready.

Step 2: Initialize Fastlane in Your Android Project

Fastlane configuration should live alongside the Android project it automates.

Navigate to your project root: 

cd path/to/your/android-project

Then initialize Fastlane: 

fastlane init

Fastlane will start an interactive setup process and create the configuration structure for the project.

Important: initialization is not architecture

fastlane init gives us a starting point. It does not decide how our release process should be designed.

That responsibility belongs to us.

The Fastlane Directory

A typical Android Fastlane setup contains a fastlane directory: 

fastlane/
├── Appfile
└── Fastfile

Fastfile

The Fastfile is where we define lanes and compose Fastlane actions into workflows.

Appfile

The Appfile stores application-specific information used by Fastlane, such as the Android package name.

Engineering principle: the workflow is code

Your release process should not exist inside someone's memory, terminal history or private documentation.

The Fastfile and other non-secret configuration should be version-controlled, reviewed and evolved alongside the application.

Step 3: Understand the Role of a Lane

A lane is a named automation workflow.

Instead of asking every developer to remember a sequence of Gradle commands, we can expose meaningful operations:

  • test — run validation.
  • build — create an application artifact.
  • deploy — distribute an artifact.
  • release — orchestrate multiple release stages.

This introduces an important principle:

Good automation exposes intent,
not implementation details.

Step 4: Create Your First Android Lane

Let's create a simple lane that delegates the Android build to Gradle. 

default_platform(:android)

platform :android do

  desc "Build the release artifact"

  lane :build_release do
    gradle(
      task: "assemble",
      build_type: "Release"
    )
  end

end

You can execute the lane with: 

fastlane build_release
Why Fastlane doesn't replace Gradle

Fastlane is not an alternative Android build system.

Gradle owns the Android build. Fastlane sits above it and coordinates the broader delivery workflow.

Breaking Down the Lane

  • platform :android — identifies the target platform.
  • lane :build_release — defines a named workflow.
  • gradle(...) — delegates the Android build operation to Gradle.

Step 5: Separate Validation from Building

A release pipeline should not simply execute:

Build → Hope → Upload

Validation should happen before an artifact becomes a candidate for distribution.

Create a dedicated validation lane: 

lane :test do

  gradle(
    task: "test"
  )

end

Run it with: 

fastlane test

As the pipeline evolves, this lane can coordinate unit tests, lint, static analysis, instrumentation tests and other quality gates.

Fastlane is the orchestrator

Fastlane doesn't replace Android's testing or analysis tools. It coordinates them as part of a larger delivery workflow.

Step 6: Compose a Release Workflow

We now have two independent operations:

  • Validate the project.
  • Build the release artifact.

We can compose them into a higher-level release workflow: 

lane :release do

  test

  build_release

end

Now the workflow has an explicit sequence:

Validate → Build → Artifact

And the developer only needs to invoke: 

fastlane release
This is the architectural shift

We have moved from documenting a sequence of commands to encoding the sequence into the release system itself.

Step 7: Keep Deployment as a Separate Concern

Building an artifact and distributing an artifact are different operations.

That distinction becomes extremely important once we introduce Google Play tracks, approvals, credentials and CI/CD.

Fastlane can interact with Google Play using actions such as upload_to_play_store. 

lane :deploy do

  upload_to_play_store(
    aab: "app/build/outputs/bundle/release/app-release.aab"
  )

end

We won't build the complete Play Store deployment architecture yet. That deserves its own dedicated part of the series.

Why separate build and deployment?

Because an artifact can be built without being immediately released.

This gives us room for verification, approval, staged rollout and environment-specific deployment strategies.

Step 8: Design for CI/CD Before You Need CI/CD

There is a useful test for release automation:

Can another machine execute the same workflow
without relying on your memory?

If the answer is no, the workflow is still too dependent on the developer's environment.

The architecture we are building should eventually look like this:

Git → CI Runner → Fastlane → Gradle → Artifact → Distribution

GitHub Actions, Jenkins, GitLab CI and other CI platforms can invoke the same Fastlane lanes later.

That's why we're deliberately avoiding a giant script that only works on one developer machine.

A Note About Credentials and Secrets

As soon as deployment enters the picture, authentication becomes part of the release architecture.

Google Play deployments commonly use service-account based authentication with the appropriate Play Console permissions.

The important rule at this stage is simple:

Configuration can be committed.
Secrets must not be.

Authentication credentials should be supplied through secure mechanisms, especially when the workflow eventually runs inside CI/CD.

What Have We Built?

At this point, we have not built the entire release pipeline. And that's intentional.

We've built the foundation.

  • Fastlane is installed and available locally.
  • Fastlane configuration lives inside the Android project.
  • Lanes represent meaningful release operations.
  • Gradle remains responsible for Android builds.
  • Validation and build operations can be composed into workflows.
  • Deployment is treated as a separate concern.
  • The workflow is designed with future CI/CD execution in mind.
Developer / CI
↓
Fastlane
↓
Validation
↓
Gradle
↓
Artifact
↓
Distribution
The real takeaway

The most important thing we created isn't the Fastfile.

We started converting an implicit release process into an explicit, version-controlled and composable workflow.

Foundation Checklist

Before moving forward, your project should satisfy these basics:

  • Fastlane is installed and verified.
  • A fastlane directory exists in the project.
  • Your Fastfile is committed to source control.
  • You have a working validation lane.
  • You have a working build lane.
  • The release workflow composes those operations.
  • No credentials or secrets are stored in Git.

Wrapping Up

Fastlane is now part of our Android project.

But we're not going to stop at:

fastlane → build → done

The goal of this series is much bigger.

Don't automate commands.
Design the release system.

In the next part, we'll go deeper into the build and release workflow: connecting Fastlane with Android build variants, artifacts and the operations that happen between "code merged" and "release delivered."

Coming Next — Part 3 Automating the Android Build and Release Process

We'll connect Fastlane with real Android build variants, artifacts and release operations to build a more complete delivery workflow.

Fastlane for Android — Part 2
From installing Fastlane to designing a repeatable release workflow.

Comments

Post a Comment

Featured Articles

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

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

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

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

🦈 Shark Heap Analysis - LeakCanary's Detective at Work

Image
Shark Heap Analysis — How LeakCanary Turns Heap Dumps into Actionable Leak Traces Learn how Shark parses Android heap dumps, builds a HeapGraph, traces GC-root paths, filters known leaks, and generates actionable LeakCanary reports. In the previous article, we saw how LeakCanary freezes the app briefly to capture a .hprof heap dump. But a heap dump on its own is only raw binary data. To make it useful, LeakCanary needs an analysis engine that can parse memory records, reconstruct object relationships, and explain why retained objects are still alive. That analysis engine is Shark . Shark is where memory leak debugging becomes understandable. It transforms a raw heap snapshot into a structured object graph, finds the most relevant retaining paths, and produces the LeakTrace reports developers use to fix leaks. Table of Contents 1. What Is Shark? 2. Why Shark Matters 3. Parsing the Heap Dump 4. Building t...
Read more