Internal Testing Track in Google Play: Track Setup Explained

What is Internal Testing Track?

Internal Testing Track is the first level of testing in Google Play Console, designed for distributing builds within the development team. The main goal is quick sanity checks, integration testing, and identifying critical bugs before expanding the audience to Closed or Open tracks.

Unlike other Google Play tracks, Internal Testing does not require Google review before activation. The build becomes available to testers within minutes after uploading to the console. This makes the track ideal for daily builds and automatic delivery from the CI/CD pipeline.

According to Google Play Console documentation (2024), the Internal Testing Track supports two distribution options: email list (up to 100 participants) and Google Groups (no quantity limit). Groups are suitable for larger teams where members change more frequently, while email works best for a fixed set of developers.

When to Choose Internal Testing Track

The Internal track is chosen in the early stages of development when the app is still unstable and APIs may change. A CI/CD pipeline uploads each new build to the Internal track, and the team receives the latest version immediately. Errors and crash logs are collected through Play Console before the build reaches external testers or users.

For new developer accounts, the Internal Testing Track serves as the first step in preparation for publication. Google does not review builds at this stage, allowing the team to verify product quality on their own before submitting for review.

How to Set Up Internal Testing Track in Google Play Console

Setting up the Internal Testing Track is done in Google Play Console under Release > Testing > Internal Testing. The process includes creating the track, uploading the first build, and adding testers.

To create the track, go to the Internal Testing section and click Create track. After creating the track, the system will prompt you to upload the first build in AAB (Android App Bundle) format. Google recommends AAB for all types of testing, as the format optimizes the app size for the device architecture.

After uploading the build, access to the track is opened by adding testers. Without at least one tester, the track is not considered active. Google Play Console shows the track status, a list of uploaded builds, and installation statistics for each participant.

// build.gradle - automatic upload to Internal Testing Track
android {
    def versionCode = System.env.GIT_COMMIT_COUNT ?: "1"
    def versionName = "1.0." + versionCode

    defaultConfig {
        versionCode versionCode.toInteger()
        versionName versionName
    }
}

// Deploy via Gradle Play Publisher plugin
plugins {
    id 'com.github.triplet.play' version '3.9.0'
}

play {
    track = "internal"
    serviceAccountCredentials = file("play-account.json")
}

Adding Testers to the Internal Track

Adding testers to the Internal Testing Track is possible in two ways: by email and via Google Groups. The email list is suitable for small teams with a fixed composition. Each tester is added manually in the console and receives an invitation at the specified address.

Google Groups are preferred for teams with a changing composition or automated access management. Simply add the group to the track, and all its members gain access to the builds. Changing the group composition happens without updating the settings in Play Console.

Testers install the app through Google Play on their device. After being added to the track, they see the app as available for update (if they previously installed it from another track) or as a new app for installation. Builds from the Internal track are not published publicly — only track participants can see them.

Collecting Metrics in the Internal Track

Google Play automatically collects Android Vitals for all builds in the Internal Testing Track: crash rate, ANR, and startup time. The developer sees the metrics in Play Console immediately after the first tester installs the build. Data is available in real time without aggregation delays.

Differences Between Internal Testing and Closed/Open Tracks

Internal Testing Track differs from Closed and Open tracks in access speed, review requirements, and audience scale. Internal does not require moderation, Closed requires Google Groups setup and review, Open goes through a full Google review.

The Internal track is the only one where a build is available without waiting. Closed and Open require Google review, which takes anywhere from several hours to 2 days. For new developer accounts, Open Testing Track is mandatory: the app must undergo 14 days of open testing before publication to production.

Automating Internal Testing via CI/CD

Automating uploads to the Internal Testing Track is a standard practice for CI/CD pipelines in Android projects. Gradle Play Publisher is the most popular plugin for automatic build publishing. It signs the AAB, uploads it to Google Play, and assigns the track.

Fastlane provides the supply action for uploading builds to Play Console. The track parameter specifies the target track: internal, closedalpha, openbeta, or production. Version management and service account are configured once in Fastfile.

# Fastfile - automated upload to Internal Testing Track
platform :android do
    desc "Build and deploy to Internal Testing"
    lane :internal do
        gradle(task: "bundleRelease")
        supply(
            track: "internal",
            aab: "app/build/outputs/bundle/release/app-release.aab",
            skip_upload_metadata: true,
            skip_upload_images: true
        )
    end
end

A Google Play service account is created in Google Cloud Console with the Publisher role and linked to the developer account in Play Console. The service account JSON key is stored in the CI/CD repository as a protected variable (GitHub Secrets, GitLab CI Variables, Jenkins Credentials).