This documentation is for a prerelease version of O3DE. Click here to switch to the latest release, or select a version from the dropdown.

Version:

Android Support for Open 3D Engine (O3DE)

Open 3D Engine (O3DE) projects for Android rely on the Gradle build system to build the final APK that launches and runs O3DE projects. O3DE provides the Android Project Generation script, which generates the Gradle build scripts that you need to build your O3DE projects for Android. The Gradle build scripts use CMake to compile the native C++ code, Java to compile and build the Android application, and will construct and package the final APK and project assets.

Prerequisite software and packages

Android SDK

The Android SDK contains Android libraries, packages, NDKs, and other tools needed to build the Android application for an O3DE project.

You can set up and configure the Android SDK by using Android Studio , an IDE commonly used with Gradle to develop and build Android applications. When you launch Android Studio for the first time, follow the steps to download and install at least one SDK platform. You can also set up and configure additional SDKs from within Android Studio. Once Android Studio is set up, you can locate the Android SDK Home by selecting Tools > SDK Manager or selecting the SDK Manager icon in the toolbar. You will find the location under Android SDK Location.

Alternatively, you can download the Android SDK command line tools only package without the need to install Android Studio. The location where the command line tools package is installed to will determine the location of the Android SDK Home. Refer to the SDK Manager instructions for details on where to install the package.

Once the Android SDK location is determined, it needs to be set in the Android configuration setting ‘sdk.root’

Note:
In order for the generation script to automatically download the required packages, you must accept the license agreements that represent those packages. This can be done either through Android Studio, or through the sdkmanager command line tool with the --licenses argument.

Java Development Kit (JDK)

The Android SDK command line tool needs the Java Development Kit (JDK) to compile the Android Java source for the project and create a Java Key Storage (JKS) files used to sign the APK. The version of the JDK required for Android depends on the requirements for the Android SDK . The location of the JDK installation must be set in the JAVA_HOME environment variable, or the location of the JDK executable must be in the PATH environment.

Note:
The version of the Java Development Kit must be compatible with the SDK Manager . However, if you wish to specify older versions of the Android Gradle Plugin, the version of the JDK that is used to run the Gradle build may be different, and may require setting the JAVA_HOME environment to match an older versions of SDK in order to build the APK successfully.

Gradle and the Android Gradle Plugin

Gradle is the build system designed to build and create Android applications. The Android Gradle Plugin adds features to the Gradle build system to support Android builds. The current Android Project Generation script supports version 8.1 or newer of the Android Gradle Plugin, which in turn requires Gradle version 8.1 or newer. The location of the Gradle installation must be set in at least one of the three ways in order for it to be discoverable:

Note:
Older versions (4.2.0 or newer) of the Android Gradle Plugin are support, but not recommended.
  1. Android configuration setting gradle.home
  2. Set in the GRADLE_HOME environment variable.
  3. The location of the gradle executable script is in the PATH environment.

CMake

CMake (version 3.22.0 or newer) is a project generator that O3DE uses for all native C++ builds, regardless of the platform. As with the discoverability requirements for Gradle, the location of the CMake installation must be set in at least one of the three ways:

  1. Android configuration setting cmake.home
  2. Set in the CMAKE_HOME environment variable.
  3. The location of the cmake executable script is in the PATH environment.

Ninja Build System

CMake uses the Ninja build system to build the underlying native C++ code for an O3DE project. Ninja must be set in the PATH environment.

Configuring the environment

The Android Project Generation script needs to be configured with the user specified settings and the locations of the prerequisite software in order for it to generate O3DE Android Gradle scripts. The android settings are managed with the android-configure command from the O3DE Command Line.

Below is the list of configurable android settings.

Setting KeyDescription
sdk.rootThe root path of the Android SDK on the build system.
platform.sdk.apiThe Android Platform SDK API level .
ndk.versionThe version of the Android NDK . File matching patterns can be used (i.e. 25.* will search for the most update to date major version 25).
android.gradle.pluginThe version of the Android Gradle Plugin to use for Gradle.
gradle.homeThe root path of the locally installed version of Gradle. If not set, the Gradle that is in the PATH environment will be used.
gradle.jvmargsCustomized jvm arguments to set when invoking gradle.
cmake.homeThe root path of the locally installed version of cmake. If not set, the Cmake that is in the PATH environment will be used.
signconfig.store.fileThe key store file to use for creating a [signing config](ref https://developer.android.com/studio/publish/app-signing) .
signconfig.key.aliasThe key alias withing the key store that idfentifies the signing key.
asset.modeThe asset mode to determine how the assets are stored in the target APK. Valid values are LOOSE and PAK.
strip.debugOption to strip the debug symbols of the built native libs before deployment to the APK.
oculus.projectOption to set oculus-specific build options when building the APK.
asset.bundle.subpathThe sub-path from the project root to specify where the bundled assets will be generated to.
extra.cmake.argsOptional string to set additional cmake arguments during the native project generation within the android gradle build process.

APK Signing

All APKs must be digitally signed before they can be installed onto an Android device. This is done by providing a signing configuration in the Android Project Gradle script. This signing configuration is meant for a debug development environment and is insecure by design. You can generate the signing configuration key store, signing key, and certificate through Android Studio . You can also create a key store from the command line using the JDK keytool command.

(More details of APK signing and how to create the keystore, keys, and certificates can be found here . )

During the creation of the Android Project Gradle script, if any of the signconfig.* values are set, the generation process will attempt to embed the signing configuration information with the following values:

  • Key Store File

    The key store file that contains the signing key and certificate. ( --signconfig-store-file/signconfig.store.file)

  • Signing Key Alias

    The alias of the signing key inside the key store file.( --signconfig-key-alias/signconfig.key.alias)

  • Key Store Password

    The password for the key store file.(signconfig.store.password)

  • Signing Key Password

    The password for the signing key needed to perform the signing operation.(signconfig.key.password)

Note:
You cannot pass in any of the two passwords through the android-configure or android-generate commands. When you run android-generate but are missing any of the signing passwords, the command will present a standard password set and confirm prompt to enter to embed in the generated project. If you want to set the passwords that will be used for the signing configs without prompting for them, you will need to call android-configure with the argument --set-password SETTING where SETTING is either signconfig.store.password or signconfig.key.password. This will present the same standard password set and confirm prompt, but will store it in the android settings for future calls to android-generate.

Android assets

Before you can generate an O3DE Android project, you must process the assets for Android. You can do this by using the O3DE Editor and the Asset Processor (or Asset Processor Batch) on your project.

Specifically for Android, you must configure the registry settings value so that the Asset Processor can process Android platform assets. To do this, update the <engine-root>\Registry\AssetProcessorPlatformConfig.setreg file.

In the Amazon/AssetProcessor/Platforms section of the file, set the "android" flag to "enabled". For example:

"Amazon": {
    "AssetProcessor": {
        ...
        "Platforms": {
            //"pc": "enabled",
            "android": "enabled"
            //"ios": "enabled",
            //"mac": "enabled",
            //"server": "enabled"
         }
    ...
}

You must pass in the --platforms=android argument when launching the Asset Processor Batch. Refer to step 3 in Generating Android Projects on Windows.

After you’ve processed the assets for Android, you can proceed to generate the Android project.

Legacy Android Project Generation Script

The original android generation script can still be found at <engine-root>/cmake/Tools/Platform/Android/generate_android_project.py, but only supports the Android Gradle Plugn version 4.x.

The generate_android_project.py script contains the following arguments:

Argument                                      DescriptionDefaultNotes
--engine-rootThe path to the root of the engine folder.<required>
--build-dirThe path to create the project’s build folder at.<required>This path can be relative to the engine root or absolute.
--third-party-pathThe path to O3DE’s designated third party folder.<required>This correlates to O3DE’s LY_3RDPARTY_PATH CMake variable.
--android-sdk-pathThe path to the Android SDK folder.<required>This path is normally set when you configure Android Studio.
-g, --project-pathThe path to the O3DE project to generate an Android project for.<required>
--android-sdk-platformThe Android API level to base the build on.The latest installed API level in the --android-sdk-path valueThe API level needs to match the version of the target Android device. (For a description of API levels, refer to https://source.android.com/setup/start/build-numbers ).

Currently, the minimum API level that’s supported is 28.
--android-sdk-build-tool-versionOverride the Android build tools version.The latest Android build tools installed in the --android-sdk-path value
--gradle-plugin-versionThe version of the Android Gradle plugin to specify for the build.4.2.0The minimum supported version is 4.2.0 (default). For details, refer to https://developer.android.com/studio/releases/gradle-plugin?buildsystem=ndk-build .

Currently, only 4.2.0 is supported. This script can be updated to support future versions.
--android-ndk-versionThe specific NDK value to base the build on.21.4.7075529The values are based on the NDK’s full revision number:
- 16.1.4479499
- 17.2.4988734
- 18.1.5063045
- 19.2.5345600
- 20.0.5594570
- 20.1.5948944
- 21.0.6113669
- 21.1.6352462
- 21.2.6472646
- 21.3.6528147
- 21.4.7075529
- 22.0.7026061
- 22.1.7171670

You can also use the * wildcard to select the most recent version. For example, 21.* selects the most recent version of NDK21.
--android-native-api-levelThe API level that the NDK supports, for native CMake Android support.The API Level set by the --android-sdk-platform parameter- The minimum API Level for the NDK is 24.
--enable-unity-build(Optional) Compiles source code with unity build.Unity build disabled.
--include-apk-assets(Optional) Includes the game assets in the APK.Assets not included in the APK.
--asset-modeConfigures how to include assets in the APK. Asset Mode values can be VFS, PAK, or LOOSE.LOOSE- LOOSE (default): Unpacks and stores assets as individual files that are contained within the asset cache.
- PAK: Packs the assets into PAK files.
- VFS: References assets remotely from the target device through the Virtual File System.
--asset-typeThe type of assets to include in the APKandroidIn the future, this argument will be deprecated and will only support android type assets.
--gradle-install-pathIf the Gradle command is not in the PATH environment, or if you want to specify an alternate Gradle folder, this argument allows you to override the installed version of Gradle to use for the project generation.The path to Gradle that’s installed in the PATH environment.- The minimum version of Gradle is 6.7.1, which is compatible with the minimum version of the Android Gradle plugin, 4.2.0.
- If you don’t specify this argument and Gradle is not installed in the PATH environment, an error will occur.
--cmake-install-pathIf the CMake command is not in the PATH environment, or you want to specify an alternate CMake installation, this argument allows you to override the installed version of CMake to use for the project generation.The CMake installation that’s part of the PATH environment.- The minimum version of CMake is 3.21, which supports Android Gradle plugin version 4.2.0..
- If you don’t specify this argument and CMake is not installed in the PATH environment, an error will occur.
--ninja-install-pathIf the Ninja command is not in the PATH environment, or you want to specify an alternate Ninja installation, this argument allows you to override the installed version of Ninja to use for the project generation.The Ninja build tool installation that’s part of the PATH environment.- If you don’t specify this argument and Ninja is not installed in the PATH environment, an error will occur.
--signconfig-store-file(Optional) An Android JKS KeyStore that is used for APK signing when the project needs to be built and deployed to an Android device. If this option is omitted, then it must be set up later in Android Studio in order to deploy to Android. Otherwise, the project can only generate unsigned APKs. (Refer to the Android Key Store section for more information.)None- If not specified, the generated Android project will not include any signing information. You can still build the Android project, but you cannot deploy to any device.
- You can add the signing key information after project generation through Android Studio.
--signconfig-store-passwordA required password for the Android JKS KeyStore file, if specified by --signconfig-store-file.None- Required if you specify a JKS using --signconfig-store-file.
--signconfig-key-aliasA required alias of the signing key in an Android JKS KeyStore file, if specified by --signconfig-store-file.None- Required if you specify a JKS using --signconfig-store-file.
--signconfig-key-passwordA required password to use the signing key in an Android JKS KeyStore file, if specified by --signconfig-store-file.None- Required if you specify a JKS using --signconfig-store-file.
--overwrite-existing(Optional) Overwrites existing scripts in the target build folder if they already exist.Does not overwrite.

Android Deployment Script

Find the script to deploy the Android project at <engine-root>/cmake/Tools/Platform/Android/deploy_android.py.

The deploy_android.py script contains the following arguments:

Argument                     DescriptionDefaultNotes
-h, --helpShows the help message and exits.
-b, --build-dirThe build directory of the project to deploy from.
-c, --configurationThe build configuration of the built binaries to deploy from.
--device-id-filterA comma separated list of connected Android device IDs to filter the deployment to.All connected Android devices.Only used when multiple devices are connected and you want to filter which devices will be the target for the deployment.
-t, --deployment-typeThe type (APK, ASSETS, or BOTH) to deploy:

APK
Deploys only the APK without any external assets (refer to the --include-apk-assets option in generate_android_project.py). Any assets that’re already included in the APK will be deployed as well.

ASSETS
Deploys only the assets for the APK. This option is only valid if you didn’t set --include-apk-assets during the project generation.

BOTH
Deploys both the APK and assets, regardless of the --include-apk-assets option.
BOTHDeploying the APK and assets separately can optimize different workflows. For example, developers who update only the code should use APK to make their deployments more efficient (provided that the assets are deployed at least initially). In another example, technical artists who only update the assets should use ASSETS (provided that --include-apk-assets was not set during project generation).
--cleanCleans the target Android device by uninstalling any pre-existing projects before deploying.Uninstalling the project also deletes all the assets deployed as well.
--kill-adb-serverOption to kill adb server at the end of deployment.
--debugOption to enable debug messages.

Additional Topics