How I Use Internal Testing to Ship Production-Ready Android Apps | by Anatolii Frolov | Apr, 2025

Even in my personal projects, I follow the same internal testing workflow I use in production environments. This section outlines the full process — from uploading a build to promoting it — step by step.

Step 1 — Google Play Console: Entry Point

Everything starts in Google Play Console. Under the Test and release section, there are several release tracks available: internal, closed, and open. For pre-production validation, I use the Internal Testing track.

It simulates the real user flow while keeping the release limited to selected testers.

Step 2 — Uploading the Release Build

Next, I upload the new app bundle to the Internal Testing track. This is the same build that will go to production — no debug-only configurations, no test flags.

Starting internal testing with the actual release artifact helps ensure that the upgrade path and runtime behavior match what users will experience after the rollout.

Step 3 — Adding a Tester

After the upload, I add testers to the internal track — in my case, it’s just me.

Even when working alone, I go through the full process: joining the tester list, accessing the app via Google Play, and testing the update as a regular user. This helps eliminate inconsistencies that can occur when installing manually.

Step 4 — Installing the Update on a Real Device

The internal build is delivered through Google Play, just like a production release.

In this case, I’m testing my personal app, MovieLand, using the same flow I follow for team projects. The update is installed over the existing version on my device — not as a clean install.

Most production issues related to migrations or state restoration show up specifically during upgrade flows, and this step helps expose them.

Step 5 — Promoting the Verified Build

After the update is tested and verified, I don’t create a new build or make any changes.

Instead, I promote the exact same bundle from the internal track to production. This avoids discrepancies between tested and shipped versions and makes the release process more predictable.