Publishing an AI-built app on Google Play

An AI builder can take you from an idea to a working app in a weekend. Google Play doesn't care how the code was written. It sees a developer account and an Android App Bundle. If the account is personal and was created after November 13, 2023, you must run a closed test with at least 12 testers opted in for 14 continuous days before you can apply for production access (Play Console Help).

What an AI tool doesn't decide for you is everything after the code: the signing key, the target SDK, the Play Console declarations, and two weeks of real people using the app. This page helps you find what your tool produced, then lists eight checks worth running on any generated app. The rule itself is in the closed testing guide.

Step 1: Find out what your builder produced

Export or download the project and look at the files. You'll find one of these.

Google Play has required new apps to publish as Android App Bundles since August 2021 (Android Developers). An APK alone won't do.

Some tools are explicit about their output. FlutterFlow's CLI, for example, lets AI coding agents such as Claude Code, Gemini CLI or Codex create and edit a FlutterFlow Studio project through an MCP server, and the result is a Flutter app (FlutterFlow docs). If you're unsure, the files above tell you.

Then follow the page for your stack: Flutter, React Native and Expo or FlutterFlow. For web apps, read on.

Web apps: two ways to wrap them

Capacitor turns a web app into a native Android project that you build in Android Studio. Add the platform with npx cap add android, open it with npx cap open android (Capacitor docs). Capacitor supports Android 7 (API 24) and later.

Capacitor ties the target SDK to its major version, set in android/variables.gradle. Its matrix lists 8.x → API 36 and 7.x → API 35, and the docs say custom target SDK versions aren't supported (Capacitor docs). So if your wrapper is on Capacitor 7, raising the number by hand isn't the fix. Upgrade to Capacitor 8.

Trusted Web Activity (TWA) shows your site full-screen inside an Android app. Google's quick start uses Bubblewrap: bubblewrap init --manifest=https://your-site/manifest.json, then bubblewrap build (Chrome for Developers). The build also writes a signed app-release-bundle.aab for Google Play (Bubblewrap).

Two TWA traps:

• Digital Asset Links. Your site must publish a file that points to your app's signing key. If verification fails, the app opens your site as a Custom Tab with browser UI at the top. Google's guide warns that when you publish on Google Play, another key may be used to sign the app than the one Bubblewrap set up. Add the Play signing key's fingerprint to the asset links file, or every tester sees a browser bar.
• Old project files. The target SDK lives in the generated Android project. bubblewrap update regenerates those files from twa-manifest.json (Bubblewrap). Check targetSdkVersion in app/build.gradle afterwards.

A wrapper that only shows a website also gives your testers little to try, and you'll have to describe their usage in the production form. Make sure the app does something useful on a phone.

Step 2: Check the target SDK

Since August 31, 2026, new apps and updates must target API level 36 or higher (Play Console Help). Where to look, with defaults verified on November 8, 2026:

• Flutter: targetSdk in android/app/build.gradle(.kts). If it says flutter.targetSdkVersion, Flutter 3.47 stable sets it to 36 (Flutter source). A hard-coded number stays what it is.
• Expo: the SDK version decides. SDK 56, 57 and 58 target 36 (Expo docs).
• Capacitor: version 8.x for 36.

Generated projects can start from an older template than the tool's current one. Check the number; don't assume it.

Step 3: Eight checks for a generated app

1. A placeholder package name. Templates start with placeholders; Flutter's ships com.example.[project] (Flutter docs). Google fixes the package name once you upload a bundle (Play Console Help), and creating the app in Play Console registers it to your account for developer verification (Android Developers). Rename before the first upload.

2. A signing key you've never seen. Some builders and cloud build services generate the keystore for you; EAS, for instance, can generate it and store it on Expo's servers (Expo docs). Download it and back it up. Google's developer verification FAQ says that if you lose your signing key, you won't be able to register your packages (Android Developers FAQ).

3. A store listing that promises more than the app does. If you let the AI write the description, read it against the real app. Google says that if a feature described in the listing isn't in the app, the app may be rejected (Play Console Help).

4. Dead buttons and empty screens. A generated app can look finished before every path works. Google asks you to make sure the app is free of "broken functionality, crashes, or missing screens" before applying, and reminds you that review "is not a troubleshooting step" (Play Console Help). Tap every screen on a real phone with a release build.

5. Permissions nobody needs. Read the final manifest and remove what the app doesn't use. High-risk permissions such as SMS or Call Log trigger a declaration form, and Google evaluates them on test tracks too (Play Console Help).

6. No privacy policy. Google says you must link to a privacy policy on your store listing and within your app, even if the app doesn't access personal or sensitive data. It must be a public web page with a valid SSL certificate, not a PDF (Play Console Help).

7. A login wall. If the app needs an account, give Google's reviewers working credentials in App access, and give your testers an account too (Play Console Help).

8. Secrets in the bundle. Anything inside an AAB can be extracted. Keep private API keys on a server, not in the app.

Step 4: Run the closed test like it matters

Upload the AAB to Test and release > Testing > Closed testing, add testers, publish, and share the opt-in link.

Then use the 14 days. Google's form asks whether testers used all features, what feedback you got, and what you changed because of it (Play Console Help). An AI tool can ship fixes fast. That's an advantage here: two or three real updates during the test give you concrete answers.

How long it takes

• Exporting, wrapping (for web apps), signing and fixing the target SDK: a day for a first-timer.
• Google's first review: up to seven days or longer in exceptional cases for some new accounts (Play Console Help). Then the opt-in link can take several hours.
• The test: 14 continuous days. Production access review: usually seven days or less (Play Console Help).

Plan for three to four weeks between your first closed upload and a public release.