Confirm the account and track
Check that the requirement applies to the account. Internal testing is useful for early builds, but it does not replace the required closed-test workflow. Complete the app setup needed to start the closed test and distribute a functioning candidate through the correct track.
Give testers the right opt-in link and installation instructions. A tester using another Google account may not be enrolled even if that person received the invitation.
The current numeric rule. Personal developer accounts created after 13 November 2023 must complete a closed-track test with at least 12 testers who have been continuously opted in for the last 14 days before the account can apply for production access. Google reduced the threshold from 20 testers in December 2024. An accepted invitation alone does not count: each tester must opt in with the intended Google account and stay enrolled for the full window. Meeting the minimum lets the account request production access; it does not guarantee approval.
Make the test useful
Assign representative tasks: onboarding, the main feature, permission denial, offline behavior and an upgrade. Ask for device/OS details, reproduction steps and expected versus actual results.
Keep a feedback log with severity, fix version and retest outcome. Do not fabricate engagement or describe automated installs as genuine user testing.
| Record | Why it matters |
|---|---|
| Continuous opt-in | Establishes the published eligibility condition |
| Task feedback | Shows what users actually exercised |
| Fix and retest | Connects feedback to improved readiness |
| Remaining limitations | Prevents unsupported claims of full coverage |
Apply after the conditions are met
The current path is the app's Dashboard → Apply for production. Google's form asks about the closed test, the app/game and production readiness. Answer from the actual test record, not a generic paragraph copied from another app.
Meeting the numerical minimum allows an application; it does not guarantee approval. Google may require additional testing. A tester who opts out and later returns does not preserve an uninterrupted opt-in period.
Continue testing after access
Production access is not evidence that every feature is stable or every policy requirement has been checked. Preserve the release candidate and monitor the initial production rollout.
APKLint's release checklist can help organize readiness evidence, but it cannot see tester enrollment or alter Console eligibility. Use the official personal-account testing requirements and the status shown in your own Dashboard before scheduling a public launch.
Separate enrollment continuity from feedback quality
For an illustrative test, maintain two linked records: enrollment status from the authorized Console view and a feedback log describing what testers attempted. A person can provide a useful bug report while failing the required continuous opt-in condition, or remain enrolled without having exercised the new feature. These records answer different readiness questions.
Use the personal-account testing guidance and the actual Dashboard status to assess eligibility. Do not calculate production access solely from the day invitations were emailed. The invitation, correct-account opt-in and the continuous enrolled period are distinct events.
Show how a tester's report changed the candidate
Suppose a tester reports that an imported note disappears after restarting the app. Ask for the tested version and a synthetic input that reproduces the issue. Reproduce it, identify the storage failure and distribute a corrected candidate through the same intended testing path.
Ask the tester to repeat the import and restart sequence after updating, while preserving a separate record of the original failure. This provides a concrete account of how feedback informed production readiness. Replacing the report with a generic statement that the app was tested loses the evidence needed to explain the correction.
Include varied supported devices and meaningful tasks without presenting a small group as exhaustive coverage. A team that tested only recent phones should not claim to have verified every older device merely because the app's minimum SDK permits installation there.
Before applying, reconcile outstanding defects with the actual candidate selected for release. Document any limitation that remains and the reason the release owner accepts it. If a critical flow still fails, completing the numerical enrollment condition does not make that flow ready for users.
Continue keeping the feedback and retest process after access is granted. Production introduces a broader audience and new operating conditions; the closed-test record is a useful starting point for diagnosis, not a certificate that future releases require no further testing.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
