Confirm your project and build workflow
First identify how the project was created. A Community CLI project generally includes native Android files that you can build with Gradle. An Expo project may use EAS Build, particularly when native configuration is managed remotely. Check the project documentation and package scripts instead of assuming one workflow fits both. Follow the current official instructions for the versions of React Native, Android Gradle Plugin, and Java in use.
Run the app in a development environment and resolve existing build or runtime errors before making a release build. Confirm the application name, package identifier, app icon, version name, and version code. The package identifier should be stable once users have installed the application, because changing it can make Android treat an update as a different app.
Prepare Android release settings
A release build should use production settings rather than development conveniences. Review permissions and remove any your app does not need. Check network endpoints, API configuration, and error handling; a development URL on your computer will not be reachable by a user’s phone. If your app uses a backend, configure its production address and verify that it uses HTTPS.
For a Community CLI project, review the Android Gradle configuration and choose a release build variant. For Expo, configure the Android build profile and credentials using the supported EAS workflow. Build configuration keys vary between project versions, so use the project’s generated files and current official docs as the source of truth rather than copying a random snippet.
- Before a release build, check for a unique, final application identifier and incremented version code.
- Review the app icon, display name, permissions, and production API settings.
- Remove development-only endpoints, sample credentials, or debug menus.
- Confirm a clean build on the toolchain version required by the project.
Create and protect the signing key
Android release packages must be signed. In a native Gradle workflow, generate or configure a keystore and signing credentials according to the Android and React Native documentation. EAS can manage signing credentials through its supported credential flow. In either case, understand which account or person controls the key and how it is backed up before the app is distributed.
Treat the keystore, passwords, and access tokens as secrets. Do not commit them to Git, include them in a public archive, or paste them into chat. Store them in an appropriately protected secret manager or secure backup, and limit access to people who need it. Losing the signing credentials can complicate publishing updates under the same application identity.
Build the APK and verify the artifact
In a Community CLI project, use the documented Gradle release task for an APK, commonly invoked from the android directory with the project’s Gradle wrapper. In an Expo project, configure a build profile that produces an APK and start the corresponding EAS build. The exact command and output path can change with project configuration; check the build result rather than assuming a preset path.
Watch for build failures and read the first relevant error, not only the final summary. Confirm that the output is a release APK and that the build completed successfully. Keep the artifact associated with its version and source commit. Do not distribute an APK from an untrusted build machine or one whose signing identity you cannot explain.
Install and test before sharing
Install the APK on a physical Android device or emulator that was not used only for development. Android may require the user to approve installation from that source; explain this clearly and distribute files only through a channel users trust. Launch the app, test its important flows, and verify that permissions appear when expected. Check behavior on a smaller screen and with a slow or unavailable network.
Test updates as well as first-time installation if you already have a prior build. Confirm that app data behaves as intended and that the version code increases. Review crash logs and fix release-only issues such as missing configuration or disabled network access. An APK that installs is not necessarily an app that works correctly.
Choose the right distribution route
An APK can be useful for internal testing, a controlled pilot, or direct distribution when the audience understands how to install it. For broader public distribution through Google Play, check the store’s current requirements. Play commonly expects an Android App Bundle for new app releases, so verify the required format and policies in Play Console instead of assuming an APK is sufficient.
Keep a record of the version, release notes, signing identity, and where the file was shared. Provide users with a clear source and a support contact, and do not ask them to disable device protections. Store the source and signing backup securely so you can fix issues and publish later updates. If you are learning the broader app-development workflow, see /course or explore the /demo page.