Private distribution means your app never appears in public Google Play search — only people you invite can install it. This guide walks you through creating the app in Google Play Console (Google's web dashboard for managing listings and releases), uploading a build, and giving a short list of testers a link that installs it on their phones. It works for a corporate tool, a client demo, or a closed beta, and suits any app that targets Android 8.0 (API 26) or newer, built in Android Studio and uploaded as an AAB (Android App Bundle — one file that Google splits into per-device APKs). If you later need a store alternative or a fully offline install path, keep the RuStore sideloading guide open next to this one.

Pre-flight checklist before you touch the Console:
Example:`applicationId "com.example.privateapp"`, `versionCode 1`, `versionName "1.0.0"`.

1. Create the app in the Console. Open Play Console, click **All apps > Create app**. Fill in the app name, default language, App or Game, Free or Paid, and tick the declaration checkboxes. Click **Create app**. Expected result: the app dashboard opens with a **Set up your app** task list. Why: an app record must exist before any build can be attached to it.
2. Complete the **App content** declarations. In the left menu go to **Policy and programs > App content** and finish every card: privacy policy, Data safety, ads, content rating questionnaire, target audience, news app. Expected result: every row shows a green checkmark. Why: Google will not let a release go live while declarations are unfinished — this is the most common reason a rollout stays stuck at "Pending".
3. Fill in the store listing. Go to **Grow > Store presence > Main store listing**. Add app name, short description, full description, icon, feature graphic, and screenshots. Click **Save**. Expected result: the page saves without the red "Missing" markers. Why: even private builds render a store card inside the Play app, so the assets are mandatory.
4. Create the internal release. Go to **Test and release > Testing > Internal testing** (older UI: **Release > Testing > Internal testing**) and click **Create new release**. Accept Play App Signing when prompted, upload your `.aab`, set the release name, for example `1.0 internal`, and add release notes. Click **Save**, then **Review release**, then **Start rollout to Internal testing**. Expected result: the release status changes to **Available to internal testers**, usually within minutes. Why: the internal track skips the full public review queue.
5. Create the tester list. On the same page open the **Testers** tab, click **Create email list**, name it `qa-team`, add the tester Gmail addresses, and **Save**. Then copy the **Join on Android** / **Join on the web** opt-in link. Expected result: a link shaped like `https://play.google.com/apps/internaltest/1234567890123456789`. Why: an app in a testing track is invisible in search — the opt-in link is the only door in.
6. Send the link and install from Google Play. Ask each tester to open the link while signed into the exact Gmail account from the list, tap **Become a tester**, then **Download it on Google Play**. Expected result: a normal Play install, and the app appears under **My apps**. Why: the Store checks the signed-in account against the tester list before showing the install button.
7. Install without Play, for local checks. Build a debug APK and sideload it over USB:
adb devices
# example output: 1d2f3a4b5c6d device
adb install -r app/build/outputs/apk/release/app-release.apk
# example output: Success
adb shell pm list packages com.example
# example output: package:com.example.privateapp
Expected result: `Success` and the icon appears in the launcher. Why: `adb` (Android Debug Bridge) pushes the APK straight to the device, bypassing the Store entirely — useful when the release is still in review.
8. Promote or keep it private. When testers are happy, promote the same AAB to **Closed testing** (bigger lists, Google Groups) or **Production**. If the app must stay visible to one company only, publish it as a private app through **Managed Google Play** after linking your organization. Expected result: the app is either limited to your list or distributed inside your company's managed store. If you want this publishing loop to run itself later, see how to automate app publishing with AI agents.

Problem 1: Testers see "We're sorry, the requested URL was not found" when opening the opt-in link.
Symptom: the browser opens `play.google.com/apps/internaltest/...` and shows a not-found page, while the Console shows the release as available.
Solution: check, in order:
1. The tester opened the link signed into the exact Gmail address that is in the **Testers** list — a different account always fails.
2. The release status is **Available to internal testers**, not **Draft** or **Halted**.
3. You waited a few minutes after rollout; propagation is not instant.
4. You copied the link from the **Testers** tab of the same track you rolled out to.
Problem 2: Upload rejected — "Your APK or Android App Bundle was signed in debug mode" or "signed with the wrong key".
Symptom: the bundle uploads to 100% and then fails with a signing error.
Solution: rebuild with your release keystore — in Android Studio use **Build > Generate Signed Bundle / APK > Android App Bundle** and pick your `.jks` file. If the upload key was lost, use the **Reset upload key** option in Play Console and upload the new certificate. Why: the Console only accepts bundles signed by your registered upload key — a debug-signed build is refused on purpose.
Problem 3: "Your app currently targets API level X and must target at least API level Y."
Symptom: the release is blocked at review with a target API level warning.
Solution: open `app/build.gradle`, raise the value, and rebuild:
android {
defaultConfig {
applicationId "com.example.privateapp"
versionCode 2
targetSdk 34
}
}
Then upload a new bundle with `versionCode 2`. Why: Google raises the minimum target API level every year, and an old bundle cannot be re-used — version codes must always increase.
What is the difference between internal testing and closed testing?
Internal testing is the fastest track: up to 100 testers, an email list, and rollout within minutes. Closed testing supports bigger lists, Google Groups, and multiple tracks (alpha/beta), but the release may go through review first. Start with internal, promote to closed later.
Will my app show up in Google Play search?
No. While the app lives only in a testing track, it is not searchable and not visible on your developer page. Only accounts on the tester list that opened the opt-in link can install it.
How long does review take?
Internal testing releases normally become available within minutes. Closed testing and production usually pass review in a few hours to a few days. There is no way to speed it up — but you can keep testing locally with `adb install` while you wait.
Can I install the app without Google Play at all?
Yes. Build an APK and sideload it with `adb install -r`, or use an alternative store — the steps are in our RuStore installation guide. This is handy for demos on devices without a Play account. For general Android app discovery in 2026, see the best AI apps for Android.