Android Unplugged | Quality Tools for Developers

Designing a repeatable Android delivery pipeline with Fastlane, Jenkins, Gradle, testing, signing, and Google Play. In this part We'll take the Fastlane automation we built in the previous parts and move it into a CI/CD environment. More importantly, we'll define what belongs to Jenkins, what belongs to Fastlane, and what belongs to Gradle. In the previous parts of this series, we built Fastlane automation step by step. We created lanes, automated builds and releases, integrated Google Play, generated screenshots, and automated versioning and changelog generation. But there is an important question left: How do we execute this automation consistently without depending on a developer's local machine? That's where CI/CD becomes the next layer of the architecture. Developer ↓ Git Push / Pull Request ↓ CI/CD System ...

Automate release metadata, connect versions to Git history, and make Android releases traceable and repeatable. In this part We'll look at Android versioning as a release-engineering problem, automate version code management, define version names deliberately, generate changelogs from Git history, and connect release metadata to the Fastlane deployment workflow. In Part 5 , we automated Android screenshot generation with Screengrab . Now we are going one level deeper into the release process. Every Android release carries metadata with it. At minimum, we need to answer three questions: Which release is this? What changed? Which source code produced this release? If these answers depend on someone manually editing Gradle files, writing release notes and remembering what changed since the previous ...

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. ...

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 A...