Publish a Lovable App to Google Play: AAB and 12 Testers

Short answer: wrap it, sign it, then run the 14-day test

Lovable gives you a live web app; Google Play wants a signed Android App Bundle and, if your Play account is a personal one created after 13 November 2023, a closed test with 12 testers opted in continuously for 14 days before it will even let you apply for production access. So the path is: wrap the web build in a native shell, sign an .aab, put that bundle on the closed testing track, recruit a dozen people who will actually open the app for two weeks, then answer Google's three-section production access form. This article walks that path in order, from Lovable's Publish button to a live listing, with the exact commands, the build settings you can never change again, and the places where wrapped apps usually fail.

What does Lovable give you, and what does Google Play require?

Lovable's own documentation is blunt about the gap. Its publish FAQ states:

Google's side of the handshake is just as direct: "Starting August 2021, new apps are required to publish with the Android App Bundle on Google Play" (Play Console Help, inspect app versions). Not a URL, not a GitHub repo, not an HTML file — a signed .aab produced from a native Android project and uploaded through Play Console.

Lovable names two routes out of this. A Progressive Web App makes the app installable from a phone browser but does not create a Play listing. A Capacitor wrapper is the path Lovable points to for stores: "wrap your published URL in a native shell with Capacitor outside of Lovable, then submit that shell to the App Store or Play Store." A third option, a Trusted Web Activity packaged with Microsoft's PWABuilder, gets a web app onto Play with less native code — see Lovable's guide to building an Android app. Whatever you pick, Play only ever sees the bundle.

If your builder handed you an Expo or React Native repository instead of a web page, you can skip the wrapper and build the bundle in the cloud; closed testing for Flutter and React Native apps covers that track's own quirks. For everything Lovable, Bolt and v0 produce, the wrap is step one — and after the upload, the testing rules are identical for every builder, because Play only ever sees the bundle.

How do you turn a Lovable project into a signed AAB?

The Capacitor path assumes your Lovable project is synced to GitHub, GitLab or Bitbucket and that you have Node.js and Android Studio installed. From a local clone of the repo:

1. npm install && npm run build — produce the production web bundle. Capacitor's webDir must point at that folder; Lovable projects typically output to dist.
2. npm install @capacitor/core @capacitor/cli @capacitor/android, then npx cap init and npx cap add android. The appId you set here becomes your Play package name.
3. npx cap sync copies the web assets into the Android project; npx cap open android opens it in Android Studio.
4. In Android Studio: Build → Generate Signed Bundle / APK → Android App Bundle, create a new keystore when prompted, and let it write app-release.aab.
5. In Play Console: create the app, then upload that .aab as a release on the closed testing track — not internal testing. The next section explains why that distinction decides whether your 14 days count.

The commands are Capacitor's own: its development workflow documentation covers npx cap sync and npx cap open android, and its Google Play deployment page puts it plainly: "the way they are deployed to the Google Play Store is just like any other native Android app." The signed-bundle step is the standard Android Studio flow, not a Lovable-specific trick. The wrap is an afternoon's work when the build is clean — it is the settings you choose during it that come back later.

Which build settings can you never change again?

Three decisions made during that afternoon are permanent, and AI-built projects hit all three because the builder never had Play Console in mind:

• The package name. Google's own wording: "Once you upload an artifact, the package name for that app is fixed and cannot be changed" (Set up an open, closed, or internal test). Choose a reverse-domain appId you will still accept in three years, and set it before the first upload, not after.
• The signing key. Play requires new apps to use Play App Signing: "Play App Signing is required for new apps so that they can use AABs" (Android App Bundle FAQ). What you keep locally is the upload key — the keystore you just created. Back it up somewhere that is not only your laptop; it signs every future release.
• The target API level. "Starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play" (Target API level requirements). In a Capacitor project that value lives in android/variables.gradle, and Capacitor's own target SDK matrix shows the trap: Android 8.x targets 36, 7.x targets 35, 6.x targets 34 (Setting Android Target SDK). A wrapper generated on an older Capacitor major ships below Play's floor, and Capacitor states it "does not support custom target SDK versions" — upgrade the Capacitor major rather than editing the number by hand.

Does the 12-testers rule apply to a wrapped web app?

Yes. Google states the rule in one sentence: "Developers with personal accounts created after November 13, 2023, must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" (App testing requirements for new personal developer accounts). Nothing in that sentence — or anywhere else on the page — asks how the app was built. A Capacitor shell around a Lovable project faces the same gate as a hand-written Kotlin app, because the requirement is attached to your developer account. Personal accounts created on or before 13 November 2023 and organization accounts sit outside it; everyone else spends the 14 days.

The practical consequence: the clock cannot start until the .aab is on the closed track with 12 testers opted in. Every day spent wrestling with Gradle, signing and store-listing assets is a day the test has not begun — which is why packaging and tester recruitment are worth running in parallel rather than one after the other.

Which testing track should your first upload use?

Closed testing. Google's requirement is a closed test: "Run a closed test with at least 12 opted-in testers continuously for 14 days. Once criteria are met, apply for production access" (Play Console Help). Play offers three pre-production tracks and only closed satisfies this one. Internal testing distributes to up to 100 testers and is meant for exactly the pre-flight checks you should finish before the real test begins (track setup documentation).

Setting up the closed test: upload the .aab, create a release, then add testers from the Testers tab. Google lets you "manage testers by email address or Google Groups" (track setup documentation) — a plain email list works, a Google Group is optional. Being on the list is not enough: each tester must open the opt-in link and accept. If Play Console shows 0 opted in after you have shared links, that is the step that failed — our 0 testers currently opted in walkthrough covers the usual causes.

What Google checks is the state you are in when you click apply: "At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days" (Play Console Help). Two consequences. Recruit a buffer — we suggest 14 to 16 rather than exactly 12, since a single opt-out otherwise puts that slot two weeks behind (our recommendation, not a Google rule). And plan for attrition: what happens if a tester uninstalls your app during the 14 days and does dropping below 12 testers reset the clock cover both sides of it.

Why is engagement the part that sinks wrapped apps?

Because 12 opt-ins are only the entry ticket. Google lists the reasons it sends an application back: "Reasons for required continued testing include having fewer than 12 opted-in testers or insufficient tester engagement during the testing period" (Play Console Help). It publishes no session threshold — but engagement, not headcount, decides the second half of the review.

Wrapped web apps carry two specific weaknesses here:

• Login walls. Lovable projects commonly ship with authentication. Google tells applicants: "Test credentials: If your app requires user authentication, provide valid, working login credentials in Play Console so reviewers can fully test your app's features" (Play Console Help). Testers hit the same wall with less patience — if a fresh install ends at an empty login screen with no way in, that tester's two weeks are over on day one.
• An empty first session. The shell loads, the backend answers, and the app opens on a blank dashboard because it is a brand-new account. Nobody returns to a blank screen. Seed demo content, or make the first-run flow worth finishing.

Based on our analysis of 1,500+ closed-testing campaigns, the tests that stall are rarely stopped by the calendar; they stall because testers install once and never find a reason to open the app again. An app with no audience, gated behind an account, starting from zero data, produces exactly that pattern by default.

What to do during the fortnight:

• Give testers two or three concrete tasks — create an account, run the main flow, change a setting — instead of "try it out".
• Check the opted-in count in Play Console daily and replace dropouts immediately; a replacement must complete their own 14 continuous days (does dropping below 12 reset the clock).
• Ask testers to open the app every couple of days. Google has not published a daily-open rule; what we see across campaigns is in do testers need to open the app every day.
• Keep the backend alive for the whole window — auth provider, database, demo data. A dead free-tier backend in week two looks like a broken app to both testers and reviewers.
• If you cannot reach 12 people yourself, decide before the test starts: how to get 12 testers lays out the routes, and are paid tester services worth it covers what they do and do not buy you.

How long does Lovable to Google Play actually take?

Roughly three to four weeks from a finished Lovable project to a live listing, for an account the rule applies to (our estimate, not a Google figure):

1. Days 1–3: wrap, sign, package name, privacy policy, data safety form, content rating, store listing.
2. Days 4–17: the closed test — 14 continuous days with 12 or more testers opted in.
3. Then the application: "The application form contains three sections: 'About your closed test', 'About your app/game', 'About your production readiness'" (Play Console Help). Our production access form questions guide goes through what each section is checking.
4. Then review: "Review usually takes seven days or less, but can occasionally take longer" (same source).

Frequently asked questions

Can I publish my Lovable app to Google Play directly from Lovable? No. Lovable's publish flow deploys to a web URL, and its documentation says it "has no built-in flow that packages and submits your project to the App Store or Google Play." You leave Lovable with a git repository or a built dist folder, wrap it with Capacitor (or package a Trusted Web Activity with PWABuilder), and upload the resulting .aab yourself.

Is a website wrapped in an app shell allowed on Google Play? Play accepts the bundle and reviews the app. Google's pre-application checklist asks you to ensure the app "is stable and free from broken functionality, crashes, or missing screens" and to provide working test credentials when it is login-gated (Play Console Help). A shell that launches, loads its content and survives review is treated like any other submission — where the code came from is not part of that checklist.

Will Google reject my app because AI wrote it? Authorship is not a rejection reason; policy and functionality are. What does change for AI-heavy apps is the obligations around AI output. If your app generates AI content as a core feature, Play's Developer Program Policy requires that "Apps that generate content using AI must contain in-app user reporting or flagging features that allow users to report or flag offensive content to developers without needing to exit the app" (Developer Program Policy). Store-listing images and videos made with AI carry a separate obligation: Google Play "requires clear labelling of AI-generated content under certain circumstances" through a self-declaration in Console (declaring AI-generated content).

Do I need a Google Group to invite my testers? No. Google lets you manage closed-test testers "by email address or Google Groups," so a plain email list plus the opt-in link works (track setup documentation). What is mandatory is the opt-in itself: each tester must accept the invitation before their days start counting.

Can I skip the closed test by registering an organization account? Google scopes this requirement to "personal accounts created after November 13, 2023," so organization accounts are not covered by it. Registering an organization means business verification — typically a D-U-N-S number — which turns a two-week test into a paperwork project. Worth doing if you genuinely have a company; as a way around testing, it is our least appealing trade-off, and that part is our view, not Google guidance.