How to Export and Publish Your GDevelop Game to Android Without Writing a Single Line of Code

You will learn a practical way to move from editor to device with minimal fuss. This guide shows the exact steps for using the cloud build flow, what to freeze before sharing, and which file types to choose for testing versus store release.

Decide up front: an APK for quick installs or an Android App Bundle for store uploads. Freeze your package name in reverse-domain style before any public test. Changing it later breaks updates and causes confused testers.

Implementation detail you can paste into your exported AndroidManifest.xml to avoid rotation crashes:

android:screenOrientation="portrait" android:configChanges="keyboard|keyboardHidden|orientation|screenSize"

Treat every build as a release candidate: keep the exact APK or AAB you tested, plus notes and the account you used for cloud builds. Free tiers limit daily automated exports, so plan builds around deadlines.

Watch these common mistakes: switching package names, exporting the wrong format for Play Store, and discarding build artifacts. The shipping habits you build here transfer smoothly if you later move to Unity or other platforms.

Build-ready Android setup in GDevelop without code

Get the project ready with stable package identifiers, icons, and manifest tweaks so the exported application installs and updates predictably.

Use the manifest override field or the exported AndroidManifest.xml to lock orientation and prevent restarts on rotate. Paste this line into your activity definition and adjust portrait/landscape as needed:

<activity android:name="org.apache.cordova.CordovaActivity" android:screenOrientation="portrait" android:configChanges="keyboard|keyboardHidden|orientation|screenSize" />

Verify your package string in Project Manager before exporting. It must be a reverse-domain ID like com.yourname.gamename, contain only letters, numbers, and dots, avoid double or trailing dots, and stay unique across the Play Console.

Include all required icons and re-check sizes after art changes. Pick a versioning rule now: a human-friendly versionName (1.2.0) and a monotonic integer versionCode that always increases.

• Avoid swapping package IDs between tests — updates will fail in place.
• Confirm icons and version numbers on every release candidate.

Common mistake	Cause	Fix	Impact
Invalid package string	Wrong format or dots	Use com.company.appname format	New app ID; users can’t update
Missing icons	Art changed, assets not updated	Replace all required icon sizes in Project Manager	Broken install thumbnail; store rejection
VersionCode drift	Using non-incremental numbers	Use a single increasing integer each build	Play Console rejects updates
Rotation restarts	No configChanges handling	Add manifest snippet to activity	App restarts on rotate; bad UX

gdevelop publish android game beginner: one-click export to APK or AAB

Use the Share menu in the toolbar to open Android one-click packaging. Click the Share button → Android → One-click packaging. That single button sends your project to the cloud build service and returns a downloadable file.

Where to find One-click packaging

Open the toolbar and choose Share, then Android. Select One-click packaging and follow the prompts. This route avoids a local desktop toolchain and keeps things simple for fast iteration.

APK vs AAB: when to choose each

1. Choose APK for quick installs and smoke tests on your phone.
2. Choose an AAB file when you intend to upload to Google Play / Play Store for distribution.
3. Treat APK for iteration and AAB for release candidates to avoid wasted exports.

Cloud build limits and artifact discipline

The cloud build process exports, compresses, uploads, and builds remotely. Free accounts have limited daily runs (Free: 2/day; Indie: 10/day; Pro: 70/day). Plan builds and avoid trivial re-exports.

Item	When to use	Risk if misused
APK	Local installs, fast tests	Not accepted by Play Store for store release
AAB file	Store submission to Google Play	Slower to test on device; requires Play Console
Cloud build	Remote packaging and compilation	Daily limits; wasted builds can block release

Download and archive each artifact immediately. Use clear names like MyApp_1.2.0_120_release.aab. Saving exact builds lets you reproduce releases and debug install issues later.

Install and test the APK on your Android phone or tablet

Install a test APK on a real device to confirm core features behave as expected. Testing on hardware exposes memory, input, and performance issues that emulators miss.

Allow per-app installs on Android 8+ without weakening security

When you open the APK on Android 8 or later, the system prompts you to allow the source to install unknown apps. Tap Settings, enable “Allow from this source” for your browser or file manager, then return to complete the install. This grants permission only to that app and keeps the device secure.

Move the APK and install from a file manager or cloud drive

Transfer the APK by USB to Downloads or upload it to Google Drive and download it on the device. Open a file manager, locate the file, and tap it to install. Check the application name and icon at install time to catch packaging errors early.

Run a short smoke-test checklist on real hardware

1. Cold launch and resume from background.
2. Audio on/off, touch at edges, and UI responsiveness.
3. Orientation behavior—confirm no restart on rotate.
4. First-time asset load and a 5–10 minute play session watching for stutter.
5. Test on at least one low-end device in addition to your fast phone or tablet.

Method	How	Pros	Cons
USB transfer	Copy APK to Downloads via cable	Fast, repeatable	Requires cable and drivers
Cloud drive	Upload to Drive, then download	No cable; easy for testers	Depends on network speed
Direct download	Host APK and open link on device	Simple for remote testers	Must secure the download link
Emulator install	Load APK into emulator	Quick smoke test	Misses low-end and hardware issues

Publish your AAB to the Google Play Store

Get your AAB ready and the Play Console set up so the final release isn’t held up by account or listing delays.

Create your Google Play Developer account and app entry

Open a developer account early; verification can take time. Complete basic console details so you can create the app entry well before release day.

Upload the AAB and verify package continuity

Upload the aab file (required for the google play store). Confirm the package shown in Play Console matches your build. A mismatch prevents updates to the same listing.

Store listing basics that affect approval and search visibility

• Use a clear title and short description that match your app’s content.
• Provide accurate screenshots and truthful content ratings to reduce review back-and-forth.
• Fill technical and privacy fields fully—omissions cause delays.

Release management: immutable artifacts and common traps

Treat each build as immutable: archive the exact AAB, changelog, and notes. Upload release exports only from a dedicated release build to avoid shipping debug settings.

Trap	Fix	Impact
Changing package name	Lock package before first upload	You can’t update the original listing
Missing listing details	Prepare title, screenshots, and declarations	Store review delays; lower visibility
Mixing test and release builds	Use separate release exports and versioning	Accidental shipping of unfinished content

Mobile performance checks before you ship

Run focused performance checks on actual phones before you send the final build to testers or the store. Small hardware catches issues that a desktop window will hide.

Texture and memory pressure on low-end devices

Budget memory first. Check texture sizes and compress large images. Keep only what you need resident—one oversized background per level can cause crashes.

Draw calls and overdraw in 2D

Watch stacked transparent sprites and heavy particle layers. Reduce alpha blending and combine sprites into atlases to cut draw calls and GPU work.

Battery, thermals, and frame caps

Cap the frame rate if 60 fps is unnecessary. Disable always-on full-screen effects and massive particle emits to avoid heat throttling and battery drain.

Screen sizes and aspect ratios

Test at least one small phone and one large tablet. Verify safe areas, UI scaling, and touch targets so the application feels correct across devices.

Later port to Unity — official reference

If you later move to a different engine, bookmark the Unity Manual → Android guidance: https://docs.unity3d.com/Manual/android.html. It maps many build concepts you’ll reuse.

• Common mistakes: uncapped FPS, huge textures, too many layers/particles, and testing only on desktop.
• Store note: google play reviewers flag crashes, poor performance, and broken layouts regardless of engine.

Check	Concrete test	Fix	Impact
Memory	Monitor resident textures during level load	Compress or stream large assets	Reduces OOM crashes on low-end phones
Overdraw	Profile transparent layers during gameplay	Flatten UI and reduce alpha layers	Improves frame pacing and battery life
Thermals	Play continuous 10-minute session	Cap fps, remove heavy effects	Prevents heat throttling and slowdowns
Layout	Check UI on multiple aspect ratios	Adjust anchors and safe area margins	Ensures readable UI on phones and tablets

Conclusion

Close the loop: verify identifiers, archive artifacts, and reserve your final store export.

.

Keep one clear path: set stable IDs and icons, export an APK for device testing, then create an AAB for the store upload. Test core features on phone and tablet—real hardware reveals issues desktop testing misses.

Archive each build with a versioned name and brief notes so you can reproduce fixes. Lock package names and increment version codes to avoid the common “can’t update” problem.

Use your account and cloud quota wisely: batch changes and save the final AAB for the Google Play submission. If you later move this flow to Unity, the same rules apply: stable IDs, reproducible builds, device-first testing, and performance budgets.