The tracks work as Play Console Tracks described: internal (up to 100 testers, within minutes), closed (email lists or Google Groups, up to 2,000 users a list), open (anyone who joins, with an optional cap of at least 1,000), then production. A new personal account also needs a closed test with at least 12 testers opted in continuously for 14 days before it can apply for production access (Play Console Submission).
What is specific to a native app is what you test on each track. The internal track is the first place where Play itself serves your bundle, so it is where you check the things this chapter could only fake: that bookclub really downloads on demand, that Play's re-signed APKs still pass Credential Manager's and App Links' certificate checks (Play App Signing), and that an in-app update offers itself. For updates, use internal app sharing, which gives each uploaded build its own install link: install one version, upload a higher versionCode, open the new link without installing, and start the app. Google's test guide adds that the account must own the app, and that the build must share its application ID and signing key with the Play version.
A native project can also upload from Gradle 19,597 . The open-source Gradle Play Publisher 4,319 (github.com/Triple-T/gradle-play-publisher (https://github.com/Triple-T/gradle-play-publisher 4,319 ), MIT, 4.1.1, plugin com.github.triplet.play) talks to the Google Play 1 Developer API with a service-account key: a play { } block sets serviceAccountCredentials, track.set("internal") and defaultToAppBundles.set(true), then ./gradlew publishBundle builds, signs and uploads in one step, and promoteArtifact moves a tested release to the next track without rebuilding it (not run here). Play Console Submission names fastlane 249,704 's supply as the alternative, which suits teams that also ship iOS.