Codex + Kotlin: Releasing an Agent-Built Android App

Kotlin and Jetpack Compose suit coding agents: the build runs in a terminal, unit tests run on the JVM, and Compose screens are plain Kotlin functions. That makes Android one of the friendlier targets for Codex. The release, however, involves keys, consoles and policies the agent cannot see. This runbook walks through it in the order you will actually do it.

Step 1: Make the release build real

Many agent-built projects have only ever been run as debug builds. The release variant behaves differently, mainly because code shrinking is enabled. Check build.gradle.kts for the app module:

• isMinifyEnabled = true for release, so R8 shrinks and optimizes the code.
• Keep rules for libraries that rely on reflection or generated code (serialization, some networking and DI libraries). Missing rules are the most common reason a release build crashes while the debug build works.
• versionCode increases with every upload; versionName is what users see. Let CI set versionCode.
• targetSdk meets Google Play's current requirement, which tracks roughly one year behind the newest Android release. Check the official requirement before each release.
• No hardcoded secrets in BuildConfig fields or resources. Anything in the APK can be extracted.

Ask Codex to "build the release variant and run the app's instrumented smoke tests" only if your environment supports it; otherwise run ./gradlew assembleRelease or bundleRelease locally and install the result on a device.

Step 2: Prepare the Codex environment for Gradle

The Codex cloud agent works in a Linux container. Gradle builds can run there, but only if the environment's setup provides a JDK and the Android SDK command-line tools with accepted licenses. Practical tips:

1. Install the SDK components your compileSdk needs in the setup script, not at task time.
2. Document the commands in AGENTS.md: ./gradlew lint, ./gradlew testDebugUnitTest, ./gradlew bundleRelease.
3. Expect emulator-based UI tests to run locally or in CI rather than in the agent's sandbox.
4. Never place the upload keystore or its passwords in the agent environment.

For comparison with the Claude Code workflow, see building an Android app with Claude Code.

Step 3: Signing with Play App Signing

New apps on Google Play use Play App Signing: Google holds the key that signs what users install, and you sign uploads with a separate upload key. This separation protects you if the upload key is lost or compromised, because it can be reset.

Store the upload keystore in a password manager or CI secret store, and keep the signing configuration reading from environment variables. If Codex suggests committing a keystore "for convenience", decline.

Step 4: Android-specific behavior to verify on a device

• Edge-to-edge: apps targeting Android 15 (API 35) and above are displayed edge-to-edge by default. Check that Compose layouts handle window insets so content is not hidden behind system bars.
• Runtime permissions: notifications need a runtime permission on Android 13 and later; request it in context, not at launch.
• Back navigation: predictive back and the system back gesture should behave consistently.
• Process death: rotate the device, switch apps and return; state should survive.
• Small screens and large fonts: agents rarely test these.

Step 5: Testing tracks and the closed-testing rule

Upload the first AAB to the internal testing track to confirm signing, install and startup. Then:

1. If you use a personal developer account created after November 13, 2023, run a closed test with at least 12 opted-in testers for 14 consecutive days before you can apply for production access.
2. Collect tester feedback through the Play Console or a simple form, and ship at least one update during the test to show active development.
3. Organization accounts are not subject to that rule but still benefit from a closed test.

Details and common pitfalls are in the 12-tester rule explained.

Step 6: Policy declarations

Before production, the Play Console asks for several declarations. Each must match what the app does:

• Data safety form: every data type collected or shared, including by SDKs. Ask Codex to list all network calls and third-party libraries as input, then fill the form yourself. See privacy labels and the data safety form.
• Content rating questionnaire, target audience and ads declaration.
• Account deletion: if users can create an account, provide a way to request deletion in the app and via a web link.
• Sensitive permissions such as background location or SMS require extra justification; remove any the agent added without a clear need.

Step 7: Staged rollout and the first week

Release to a small percentage of users first and watch Android vitals and crash reports. R8-related crashes, missing insets and permission edge cases tend to show up here. Increase the rollout once crash rates are stable, and keep the agent busy fixing reported issues in small pull requests.

If you want this pipeline set up properly once, appsubmitter.io configures CI/CD, signs and submits your Android builds in your own Play Console account and helps when a review or policy issue comes up. The companion guide From ChatGPT Codex to Google Play covers the steps before the release build.