How to upload an .aab to Google Play without Android Studio in 2026

Version française →

Android Studio is the obvious way to build and upload a .aab — it's not the only one. If your workflow lives in a terminal, a CI pipeline, or a cross-platform framework, opening a full IDE just to push a release binary is friction you don't need. Shipping iOS too? Same story on the Xcode side — see how to upload an .ipa to App Store Connect without Xcode.

Why skip Android Studio for uploads?

Android Studio is a build tool first; the upload capability is a convenience for developers already inside it. The .aab format has no dependency on the IDE — Google Play accepts bundles through its web console, its Developer API, and any tool that wraps that API.

Method 1: Google Play Console (browser upload)

Go to play.google.com/console, select the app, Release > Production (or internal/alpha/beta), Create new release, upload the .aab under App bundles, fill in release notes, save and roll out. Works for any .aab regardless of how it was built. Manual — fine for occasional releases, tedious at scale.

Method 2: Bundletool (command line)

Google publishes bundletool as a standalone JAR — it inspects, validates, and tests a .aab locally, but doesn't upload it.

java -jar bundletool.jar validate --bundle=app-release.aab

For an actual upload from the CLI, you still need the Developer API or a tool that wraps it.

Method 3: Google Play Developer API (direct API call)

You need a Google service account with the Release Manager role, its JSON key, and an OAuth 2.0 access token. Three calls: create an edit (POST .../edits), upload the bundle (POST .../edits/{editId}/bundles), assign it to a track and commit (PUT track, POST commit). Fully automatable, but you write the integration yourself — google-api-python-client or google-api-nodejs-client are reasonable starting points.

Method 4: Fastlane supply

fastlane supply --aab app-release.aab --track production

Wraps the Developer API and handles the edit/upload/commit cycle. Free, open-source, a standard for years. The trade-off: it requires Ruby, a Gemfile, and some familiarity with Fastlane config.

Method 5: Expo EAS Submit

eas submit --platform android

Configure the service account JSON in eas.json, and EAS handles the API calls. The lowest-friction option for Expo-based projects — build and submit in the same toolchain.

Method 6: a unified dashboard (OneStore)

The other five methods solve the upload problem in isolation, not the work around it — listing metadata before release, tracking what's live versus draft, managing iOS alongside Android. OneStore connects the .aab upload to the rest of the release workflow: authenticate once with the service account JSON, uploads go through the Developer API, and staged rollout is controlled straight from the dashboard. Shipping iOS too? The .ipa goes out in the same session. For the full detail on how OneStore delivers binaries (.ipa and .aab), see how OneStore uploads your binaries.

Choosing the right method

A note on service account permissions

Whichever method you pick, the service account JSON needs the right Play Console permissions — the Release Manager role covers bundle uploads and track management; Admin works too but grants more than necessary, so assign the minimum scope. Don't commit the JSON to version control.

FAQs

Do I need Android Studio installed to build a .aab?

No — ./gradlew bundleRelease, Expo EAS Build, or Flutter's flutter build appbundle all work without it.

Can I upload directly to internal testing instead of production?

Yes — browser upload and the Developer API both let you target any track; Fastlane takes --track internal; EAS sets the track in eas.json.

What's the difference between .aab and .apk for uploads?

Google Play has required .aab for new apps since August 2021; existing apps can still update via .apk, but any new app needs .aab (or Play Asset Delivery).

How do I generate a service account JSON?

In Google Cloud Console, create a service account under your project, generate a JSON key, then grant it access in Play Console under Users and permissions with the Release Manager role at the app level.

Is it safe to give a third-party tool my service account JSON?

It depends on how the tool stores it. At OneStore, the service account JSON sits in a vault encrypted at rest with AES-256-GCM (authenticated encryption) at the application layer, and a Data Processing Agreement based on EU Standard Contractual Clauses is available on request at onestore.so/dpa. That's not a claim of EU-hosted servers or blanket GDPR compliance — always check a tool's actual security posture before handing it Release Manager access.

Can I automate .aab uploads in CI/CD without Fastlane?

Yes — the Developer API accepts direct HTTP calls and integrates into GitHub Actions, Bitrise, or CircleCI using the official client libraries; you need a valid service account JSON and the correct OAuth scope.

What happens if I upload with the wrong version code?

Google Play rejects the upload if the version code already exists or is lower than the current release — bump versionCode in build.gradle before rebuilding.

Want to check your listing before the next release? The Store Listing Audit does it free in a few seconds. OneStore handles the rest: upload, staged rollout, and both stores from one dashboard.