You Built an App With AI. Here's How to Ship It to Android

You described an app to Lovable, Bolt, Cursor, or Claude, and it built one. It runs in the preview pane. It looks finished. Then you try to put it on your actual phone, and the first honest error of the project shows up before any code runs at all:

$ flutter build apk
zsh: command not found: flutter

Nothing is wrong with your app. The gap is simpler and more annoying than that: the AI handed you a project — a folder of source code — and a phone only installs a signed binary. Something has to compile one into the other, and that something is a toolchain nobody mentioned while you were prompting. This post covers both ways across: doing it yourself, honestly described, and skipping it.

What you have vs. what a phone accepts

The signature requirement is the part that surprises people, so here is keystores in one paragraph: a keystore is a password-protected file containing a private key, and every Android app must be signed with one before any device will install it. The key is your app's permanent identity — every future update must be signed with the same key, or phones and Google Play will reject the update as an impostor. Lose the keystore and you can never update the app again, only publish a new one. That is the entire concept. The ceremony around it (keytool, key.properties, signingConfigs) is just plumbing.

The honest local path (the 10GB wall)

There is no trick that avoids this if you build locally, so here it is straight. The Android Studio download is a couple of gigabytes, but after the SDK platforms, build tools, emulator images, and Gradle's caches settle in, expect 10GB+ of disk and an hour or two before your first successful build.

$ keytool -genkey -v -keystore upload-keystore.jks \
    -keyalg RSA -keysize 2048 -validity 10000 -alias upload

For a hand-written project by an experienced Flutter developer, step 5 usually works. For an AI-generated project, step 5 is where a second, distinct category of problem begins — and it is not your fault either.

The five build failures we actually see in AI-generated projects

We run a build service, so failed AI-generated uploads are our daily weather. The same five failures account for most of them. Each one below shows the real error text and what our preflight does about it automatically.

Error: Could not find or load main class org.gradle.wrapper.GradleWrapperMain
Caused by: java.lang.ClassNotFoundException: org.gradle.wrapper.GradleWrapperMain

FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred evaluating root project 'android'.
> Minimum supported Gradle version is 8.4. Current version is 6.7.

Build failed due to use of deleted Android v1 embedding.

Execution failed for task ':app:validateSigningRelease'.
> Keystore file '/Users/alex/upload-keystore.jks' not found for signing config 'release'.

A problem occurred configuring project ':device_info'.
> Namespace not specified. Specify a namespace in the module's build file.
...
> Could not GET 'https://jcenter.bintray.com/...'.

Every repair above is something a Flutter developer would eventually do by hand after an hour of searching the error text. The pipeline just does it before the build starts, and logs what it changed. If the project is simply from an older era, the toolchain adapts instead — we wrote up how the version matrix picked the right 2023 Flutter for Google's own archived gallery app.

Or skip all of it

The alternative path is one step: zip the project folder the AI gave you — the one containing pubspec.yaml — and upload it. The pipeline runs the preflight repairs above, builds, and signs the result with the managed per-project key. You get back an APK for direct install and an AAB for Google Play. No Android Studio, no PATH, no keytool.

Two honest caveats, because this is where build services usually oversell. First: some projects still fail — genuinely broken Dart code, for example, is your bug, not a toolchain problem. When a build fails you get the actual diagnosis from the log, not a shrug, and the build credit is refunded automatically. Second: iOS. We produce unsigned preview IPA builds on real Apple hardware, which is useful for testing — but App Store distribution requires your own Apple Developer account and your own signing. We don't claim otherwise, and you should be suspicious of anyone who does. If you just know Flutter and want the deeper Android build walkthrough, that guide is here.

FAQ

Do I ever need to install Android Studio?

Not for building. If you keep iterating on the app through your AI tool and only need installable builds out the other end, the upload path covers it entirely. You'd want Android Studio if you plan to hand-edit native Android code or debug on-device with breakpoints — most people shipping an AI-generated app never do either.

What exactly do I upload?

A zip of the project root — the folder containing pubspec.yaml. Include everything the tool exported, including pubspec.lock if present. You can leave out build/ and .dart_tool/; they're regenerated anyway.

Can you put my app on the Apple App Store?

No, and we won't pretend to. iOS builds come back as unsigned preview IPAs; App Store submission requires your own Apple Developer membership ($99/year) and signing with your own certificate. Android is the full story here: signed APK and AAB, ready for direct install or Google Play under your own developer account.

What happens if the build fails?

You see the real failure reason extracted from the build log — the same error text a developer would read — and the credit for that build is refunded automatically. A failed build costs you nothing, which also keeps us honest: we only get paid when a binary comes out.