Magic Deploy Setup — Google Play

What you're filling in

When you click Magic Deploy in LingCode and choose Google Play, you'll see up to seven fields. The first three are required; the four signing fields are only needed if your build.gradle doesn't already configure a release signing config.

Before you start — one-time Play Console setup

Three things have to exist in Google Play Console before a service account can upload anything. Skipping any of them will result in confusing errors later.

1. A Google Play developer account. Register at play.google.com/console/signup. There is a one-time $25 fee. Use the Google account you want to own the app long-term — transferring ownership later is possible but painful.
2. An app record in Play Console. In Play Console, click Create app, fill in the name, default language, app vs. game, and free vs. paid. The package name you enter here must match the applicationId in app/build.gradle exactly and can never be changed afterward.
3. At least one AAB uploaded by hand. Play refuses service-account uploads until a human has uploaded at least one signed build. Build a signed AAB locally (./gradlew bundleRelease) and drag-drop it into Play Console → Testing → Internal testing → Create new release, once. You don't have to release it — just uploading unlocks the API path.

Your Android project must have these settings

A correct Play Console side is useless if ./gradlew bundleRelease doesn't produce the AAB LingCode expects. Verify each of these before the first deploy.

applicationId in app/build.gradle

This is Android's equivalent of a bundle identifier, and it must match the package name you typed in Play Console exactly. Once the app is live, this value can never change — Google treats a different applicationId as a completely different app.

android {
    defaultConfig {
        applicationId "com.example.app"
        // …
    }
}

versionCode and versionName

Both live in defaultConfig. versionCode is an integer that Play uses to order uploads; versionName is the human-facing string.

defaultConfig {
    versionCode 42        // must be greater than every previous upload
    versionName "1.2.3"   // shown to users in the Play Store
}

Every upload must bump versionCode. Re-uploading the same versionCode is the single most common reason a second deploy fails silently — Play rejects it server-side with "Version code X has already been used."

minSdkVersion and compileSdkVersion

Play Console enforces a targetSdkVersion floor that rises yearly (typically API 33+ today). If your project's targetSdkVersion is below the current floor, the upload is accepted but the release is blocked from rollout. Check developer.android.com/google/play/requirements/target-sdk for the current minimum.

A bundleRelease gradle task

LingCode runs ./gradlew bundleRelease and expects the output at app/build/outputs/bundle/release/app-release.aab. This works out of the box for standard Android Studio projects. If you renamed the app module, if you use product flavors, or if you have a multi-module project where the uploadable AAB is produced elsewhere, you'll need to adjust:

• Renamed module: LingCode checks both app/build/outputs/bundle/release/app-release.aab and build/outputs/bundle/release/app-release.aab. Move your module back to the standard layout, or temporarily symlink the AAB into the expected path.
• Product flavors: bundleRelease builds every flavor. You want one specific AAB — either switch Magic Deploy off and run ./gradlew bundle<Flavor>Release yourself, or set a default flavor in gradle.

A Gradle wrapper (gradlew)

LingCode prefers ./gradlew over the system gradle. If your project doesn't have one, add one:

gradle wrapper --gradle-version 8.5

(Pick whatever version your project is known to build with.) Using the wrapper insulates you from whatever gradle happens to be on your PATH and matches what CI / teammates use.

Step 1 — Create a service account and JSON key

The service account is what LingCode authenticates as when it talks to Google Play. You create it inside Play Console — not inside the Google Cloud Console, even though service accounts are a Cloud concept.

1. Sign in at play.google.com/console.
2. In the left sidebar, click Setup → API access.
3. Under Service accounts, click Create new service account. Play Console opens a dialog linking to Google Cloud; follow it, create the service account (any name — "LingCode Magic Deploy" is fine), then come back to the Play Console tab and click Done.
4. Back on the API access page, find your new service account in the list and click Manage Play Console permissions (or Grant access).
5. On the App permissions tab, click Add app and pick the app you registered earlier.
6. On the Account permissions tab, enable at least Release apps to testing tracks and Release apps to production. Save.
7. Back in Google Cloud Console, open the service account's Keys tab, click Add key → Create new key → JSON, and download the file. Save it somewhere you back up.

In LingCode, click Browse… next to Service account JSON and pick the downloaded file.

Step 2 — Pick a release track

The Track dropdown decides where Play puts the upload. LingCode defaults to internal, which is the fastest and safest choice while you're testing Magic Deploy itself.

• internal — up to 100 testers on an allowlist. No review, instant. Use this for your first few uploads.
• alpha — a closed testing track, typically larger. Still allowlisted.
• beta — open testing that anyone with the link can join.
• production — visible on the Play Store. Goes through Google's review (usually hours to a few days).

You can always promote a build from internal to a higher track later from inside Play Console without re-uploading.

Step 3 — Configure release signing

Google Play only accepts signed AABs. You have two ways to get there — pick whichever fits your existing workflow.

Option A — Sign inside build.gradle (recommended if you already have a keystore)

Add a signingConfigs.release block to your app/build.gradle:

android {
    signingConfigs {
        release {
            storeFile file("/absolute/path/to/release.keystore")
            storePassword "…"
            keyAlias "release"
            keyPassword "…"
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
            // …
        }
    }
}

If you go this route, leave the four keystore fields in LingCode blank. LingCode just runs ./gradlew bundleRelease and lets gradle read the signing config from the build file.

Option B — Let LingCode inject the keystore at build time

If you don't want to hard-code passwords into build.gradle, have your build file read them from gradle properties:

android {
    signingConfigs {
        release {
            storeFile file(project.findProperty("RELEASE_STORE_FILE") ?: "release.keystore")
            storePassword project.findProperty("RELEASE_STORE_PASSWORD") ?: ""
            keyAlias project.findProperty("RELEASE_KEY_ALIAS") ?: ""
            keyPassword project.findProperty("RELEASE_KEY_PASSWORD") ?: ""
        }
    }
    buildTypes {
        release { signingConfig signingConfigs.release }
    }
}

Then fill in all four keystore fields in LingCode. At build time LingCode passes them to gradle as -PRELEASE_STORE_FILE=…, -PRELEASE_STORE_PASSWORD=…, -PRELEASE_KEY_ALIAS=…, -PRELEASE_KEY_PASSWORD=…. The values never leave your Mac except as arguments to the local gradle process.

Don't have a keystore yet?

Generate one with the JDK's keytool:

keytool -genkeypair -v \
  -keystore release.keystore \
  -alias release \
  -keyalg RSA -keysize 2048 \
  -validity 10000

Save the file somewhere you back up. If you lose this keystore you can never update the app on Play again — Google uses its signature to prove new versions are really "from you." Back it up in at least two places.

Step 4 — Click Deploy

With the service account JSON, package name, and signing all in place, the Deploy to Google Play button activates. LingCode then:

• Finds your Android project (looks for build.gradle or build.gradle.kts at the project root).
• Runs ./gradlew bundleRelease (or gradle bundleRelease if there's no wrapper), with your signing credentials passed as -P properties if you chose Option B.
• Reads the AAB at app/build/outputs/bundle/release/app-release.aab.
• Signs a JWT with the service account's private key and exchanges it at Google's OAuth endpoint for an access token scoped to androidpublisher.
• Creates a new edit, uploads the AAB, and commits the edit on the track you picked.

On success the build shows up in Play Console → Testing → your track → Releases within a minute or two (Google's processing time, not LingCode's). From there you can roll it out, promote it to another track, or submit it for review.

Reading the progress log

While Magic Deploy runs, the right-hand panel streams the live output of gradlew and every HTTP call LingCode makes to Google's servers. Lines prefixed with [Google Play] are LingCode's own markers; everything else is verbatim tool output.

A successful run looks like this end-to-end:

[Google Play] Building signed AAB...
> Task :app:bundleRelease
BUILD SUCCESSFUL in 45s
[Google Play] Getting access token...
[Google Play] Creating edit...
[Google Play] Uploading AAB...
[Google Play] Committing edit...
[Google Play] Upload complete. Check Google Play Console for the new build.

When it fails, scroll to the bottom of the log. LingCode's short error messages ("Build failed. Check errors above.") are pointers; the real reason is in the last 20 lines of raw output — usually the line that starts with FAILURE: (gradle) or an HTTP status code (Google API).

Per-phase troubleshooting

Failures group cleanly by phase. Fixing each one looks different.

Build phase (gradlew bundleRelease)

OAuth phase (JWT → access token)

Create Edit phase

Upload AAB phase

Commit Edit phase

What happens after a successful upload

When Magic Deploy finishes, the build lands in Play Console → your app → Testing → <your track> → Releases. Unlike App Store Connect, there's usually no separate "processing" state for AABs — the build is available within a minute or two. From there:

• Internal testing — testers from your allowlist can download immediately via the opt-in URL. No review.
• Closed testing (alpha) — allowlist-based, but requires a first review (usually < 24h).
• Open testing (beta) — anyone with the link can join. Requires review for first release to this track.
• Production — visible on the Play Store. Reviewed by Google (hours to a few days). A rollout can be staged (e.g., 10% → 50% → 100%) from the same page.

You can promote any build from a lower track to a higher one from inside Play Console without re-uploading — go to the release page for the target track and click Create new release → Add from library.

Quick reference: where to go when something's wrong

Common mistakes (quick checklist)

• "No Android project found." The open project doesn't have a build.gradle or build.gradle.kts at its root. Open the Android project directly (the one that contains gradlew), not its parent.
• "AAB not found at app/build/outputs/bundle/release/app-release.aab." Your app module doesn't produce an AAB — usually because the project has multiple modules and bundleRelease built something else, or your module is named something other than app. Rename the module to app or add an app subproject that aggregates the release bundle.
• "Create edit failed … Check package name and API access." Either the package name you typed doesn't match the app's applicationId, or the service account isn't linked to that app yet in Play Console → Setup → API access → App permissions.
• Upload succeeds, build never appears. You skipped the first-manual-upload step. Upload any signed AAB by hand once, then retry.
• "Build failed" with a signing hint. Either Option A's build.gradle references a keystore path that doesn't exist on this machine, or Option B's -P properties don't match what your build.gradle expects. Run ./gradlew bundleRelease in a terminal with the same arguments LingCode used — the error from gradle is more specific.
• Wrong service account permissions. The default grant in the dialog is often read-only. Make sure you ticked at least Release apps to testing tracks on the Account permissions tab.

Security notes

Both the service account JSON and the keystore are credential material. LingCode never uploads either anywhere except to oauth2.googleapis.com and androidpublisher.googleapis.com — i.e. Google itself — and only as part of the deploy you trigger. Both files stay on your Mac otherwise.

If you lose a laptop or a teammate leaves, rotate the service account key (delete the old one in Cloud Console → IAM → Service accounts → Keys and generate a new one) and, if the keystore itself was in a compromised backup, stop using that app for new releases — Google does not allow rotating an app's signing key without their explicit involvement via Play App Signing.

Further reading

Primary sources for the concepts on this page, from Google and the IETF:

• LingCode deploy glossary — every term on this page, defined.
• Google Play Developer API — the REST API LingCode calls to create edits, upload AABs, and commit releases.
• OAuth 2.0 for Server-to-Server Applications — the JWT bearer flow the service account uses.
• Sign your app (Android Developers) — keystore generation, signing configs, and Play App Signing.
• About Android App Bundles — why AABs exist and how Play serves tailored APKs to each device.
• Manage your Play testing tracks — how internal / alpha / beta / production work in practice.