Skip to content
Back to journal
FlutterAndroidCloud BuildGuide

Build Flutter APK Online: Upload a Project or Use the CLI

CCode2Native EngineeringEngineering team
Published
Updated

To build a Flutter APK, run flutter build apk --release in a configured Flutter project, or send the complete project to an Android cloud build service. Code2Native accepts supported Flutter ZIP or Git projects on Builder or Pro. Its free Preview is an Android website wrap, not a source compile.

If you only needed the command, start below. If you have a ZIP and do not want to maintain the toolchain locally, skip to the cloud workflow. The same project and signing requirements matter in either case.

The local Flutter build command

Android Studio is a convenient way to install and manage Android tools, but the IDE is not strictly required to run a command-line build. You still need Flutter, an appropriate JDK, the Android SDK, and the tools your project uses. See the Flutter CLI reference and Android's SDK command-line tools.

Example commands from the Flutter project directory — not a live build log

flutter doctor -v
flutter pub get
flutter build apk --release

For a standard project, look for build/app/outputs/flutter-apk/app-release.apk. Flavors and split-ABI builds can produce different filenames. A release-mode command does not by itself prove that your production signing identity was used.

APK or AAB?

  • APK: an installable Android file for device tests and direct distribution. Device compatibility depends on the app's configuration.
  • AAB: a publishing bundle, not a file you install directly like an APK. Use flutter build appbundle --release when preparing this output.

Flutter's Android release guide explains signing and release outputs. Google Play submission also involves account, policy, testing, and listing requirements; building an AAB does not guarantee acceptance.

Build a Flutter ZIP online with Code2Native

The cloud workflow is for a Flutter application, not a screenshot, a lone Dart file, or a ZIP containing only an existing APK. Check the supported source builds and current Builder / Pro limits before buying. An App license for one website does not unlock source compiles.

  1. Package the project root. Include pubspec.yaml, Dart source, referenced assets, local packages, and the lockfile when present. Put the project at the ZIP root or inside one top-level folder, not deep inside a monorepo export.
  2. Keep required native work. Include your existing android/ directory if it contains custom plugins, manifests, flavors, or native code. Do not remove it simply to make the upload smaller.
  3. Exclude generated caches and secrets. Leave out build/ and .dart_tool/. Do not put private signing keys or production server credentials in a public repository.
  4. Choose Source Code and Android. Upload the ZIP or use an accessible Git clone URL and the intended branch or tag. Confirm the distribution choice and displayed credit cost before submitting.
  5. Follow the result. Wait for completion and inspect the logs and artifact metadata. Queue load, dependency downloads, and project complexity affect duration; there is no fixed completion time.

Missing files or incompatible dependencies can still prevent compilation. The builder may apply logged compatibility adjustments; it does not implement missing application features or guarantee that every old project will compile. The source build guide covers accepted layouts, custom commands, and output directories.

Check the signing identity before sharing

A debug-signed APK and a production release are not equivalent. Inspect the artifact's signer and package identity, and preserve the signing relationship needed for later updates. If you are updating an existing Play app, confirm its upload-key requirements before choosing a different key. Code2Native's Android build documentation describes the workflow; an installable file is not a promise of store approval.

When the build fails

Start with the first actionable dependency or compiler error, not just the last Gradle exit code. Check missing assets, version constraints, native plugin requirements, and the selected toolchain. Do not upgrade Gradle, Kotlin, and the JDK independently based on a single generic version recommendation.

For a specific error, use the Gradle failure triage or compileSdk mismatch guide. Platform faults refund build credits; customer compile errors do not. Keep the relevant logs and change the identified cause before spending another build.

When a full CI workflow is a better fit

If you need repository-triggered tests and a broader release pipeline, evaluate a configurable CI service. Codemagic documents a Flutter workflow editor as well as YAML workflows; it is not accurate to describe it as YAML-only. Compare the same build volume, signing responsibilities, testing, and support scope instead of assuming one service is fastest or cheapest.

Ready to compile your project?

Check the supported inputs and paid source-build scope first. Keep the local CLI route if it already meets your needs.

Check source-build requirements
C

Code2Native Engineering

Engineering team

Written by the Code2Native engineering team — the people who build and operate the cloud build pipeline.