Android Deploy Configuration | Qt Creator Documentation
Description: Create packages to deploy to devices or to submit to the Google Play store, or create libraries for Android app modules.

- Qt Creator Documentation
- Android Deploy Configuration
- Qt Creator 18.0.2

Developing for iOS ◦ Boot to Qt Deploy Configuration

# Android Deploy Configuration

Android applications are packaged as ZIP files called Application Packages (APK), Android App Bundles (AAB), or Android Archives (AAR). You can install and run APK files on a device. You can upload AAB files to the Google Play Store.

Qt for Android has binaries for armv7a, arm64-v8a, x86, and x86-64. To support several different ABIs in your application, build an AAB that has binaries for each of the ABIs. The Google Play Store uses the AAB to generate optimized APK packages for the devices that request downloads and automatically signs them with your publisher key.

Qt Creator supports the following methods of deployment for Android applications:

- As a stand-alone, distributable application package (APK).
- As an app bundle (AAB) for distribution in the Google Play store.
- As an AAR, which fundamentally differs from the APK and AAB formats in that it is an Android library. You can use it as a dependency for an Android app module, but you cannot run it alone.

  All Qt versions do not support AABs. Qt 6.3.0 and later support multi-abi builds for applications when you build with CMake. AARs are supported from Qt 6.8.0 onwards. For more information, see Deploying an Application on Android.

To specify settings for application packages, go to Projects > Build Settings > Build Android APK and select Details.

For more information about the options that you have for running applications, see Android Run Settings.

## Packaging Applications

Because bundling applications as APK packages is not simple, Qt has the androiddeployqt tool. When you deploy an application using a Qt for Android kit, Qt Creator runs the tool to create the necessary files and to bundle them into an APK. For more information, see Android Package Templates.

To view the packages that the `androiddeployqt` tool created, select Open package location after build.

### Specifying Deployment Settings

To specify settings for deploying applications, go to Projects > Deploy Settings and select a deploy configuration in Active deployment configuration.

To add deploy configurations for a project, select Add.

To rename the current deployment method, select Rename.

To remove the current deployment method, select Remove.

Qt Creator deploys the packages on the Android device that you select in the kit selector. To add devices, select Manage.

For more information about specifying additional start options for applications, see Android Run Settings.

To remove previously installed files from the device, select Uninstall the existing app before deployment.

To install a pre-built APK, such as a 3rd-party application, on a device, select Install an APK File.

### Specifying Settings for Packages

To specify settings for the `androiddeployqt` tool, go to Projects > Build Settings > Build Android APK and select Details.

The `androiddeployqt` tool creates APKs based on the settings. For more information about the available options, see androiddeployqt.

You can view information about what the `androiddeployqt` tool is doing in Compile Output. To view more information, select Verbose output.

Select Add debug server to include the debug server binary into a package.

#### Selecting API Level

In the Android build platform SDK field, select the API level to use for building the application. Usually, you should select the highest API level available.

Usually, you should use the highest version of the Android SDK build tools for building. If necessary, select another version in the Android build-tools version field.

#### Building AABs

For testing the application locally, use the APK format because Qt Creator can install and run the package on the device. For distribution to the Google Play store, create an AAB by selecting Build Android App Bundle (*.aab).

When building with CMake, you can view the selected ABIs in Initial Configuration in the CMake section. You can set additional ABIs as values of the `ANDROID_ABI` key:

When building with Qbs or qmake, you can select the ABIs in the ABIs field in the Build Steps:

#### Building AARs

Select the AAR target in the Build Steps section.

#### Signing Android Packages

To publish your application, you must sign it by using a public-private key pair that consists of a certificate and a corresponding private key and is identified by an alias. The key pair is used to verify that the future versions of your application are actually created by you.

Warning: Keep the key pair in a safe place and take backup copies because you cannot update the application if you lose the key pair.

You can use Qt Creator to generate a keystore and a self-signed certificate. The generated certificate has the structure of an X.509 v3 digital certificate. It has information about the version, serial number, and validity period of the certificate, the ID of the algorithm that is used to encrypt the data, the organization that issued the certificate, and the subject (owner) of the certificate. In case of a self-signed certificate, the issuer and owner of the certificate are the same. In addition, the certificate has information about the algorithm that is used to sign the certificate, as well as the signature of the certificate.

A password protects the keystore. In addition, you can protect each alias with its individual password.

When you sign an Android application, you must select a keystore that has certificates and a certificate alias from the keystore. The signing process embeds the public key (certificate) for the alias into the APK.

To create a keystore and a self-signed certificate:

1. In the Keystore field, select Create to create a new keystore that has one key pair in the Create a Keystore and a Certificate dialog:

2. In the Keystore group, enter a password to protect the keystore.
3. In the Certificate group, specify the key size and validity period of the certificate. You can specify a separate password to protect the key pair or use the keystore password.
4. In the Certificate Distinguished Names group, enter information about yourself and your company or organization that identifies the issuer and the owner of the key pair.
5. Select Save.
6. In the Keystore File Name dialog, enter a name for the keystore and select a location for it.
7. In the Keystore dialog, enter the keystore password to create the key pair in the keystore.

To sign an Android package by using a key pair, set the Sign package group settings described in Specifying Settings for Packages:

1. In the Keystore field, select Choose to select an existing keystore.
2. In the Certificate alias field, select an alias from the list of key pairs that the keystore has.
3. Select Sign package to use the alias to sign the Android package.

#### Adding External Libraries

Qt Creator automatically detects which Qt libraries the application uses and adds them as dependencies. If the application needs external libraries, go to Projects > Build Settings > Build Android APK and specify them in Additional Libraries. The libraries are copied into your application's library folder and loaded on startup.

To add OpenSSL libraries, select Include prebuilt OpenSSL libraries in the Additional Libraries group. This will add the OpenSSL include project defined in device settings in Android OpenSSL group. This can be used for qmake and CMake projects.

Otherwise, you can manually add the paths to the required `libssl.so` and `libcrypto.so` libraries to the Additional Libraries field.

## Editing Manifest Files

You can use the configuration options to specify all the settings you need for the `androiddeployqt` tool. You only need an Android manifest file to specify Android-specific settings, such as the application icon. However, you need the manifest file to publish the package in the Play Store. For more information about manifest files, see Qt for Android Manifest File Configuration.

If you use CMake as the build system, you must specify the Android package source directory, `QT_ANDROID_PACKAGE_SOURCE_DIR`, in the `CMakeList.txt` file, as instructed in the mobile device tutorial.

To use Qt Creator to create an Android manifest file and to open it in the Android Manifest Editor:

1. Go to Projects > Build Settings > Build Android APK, and select Create Templates.
2. Check the path in Android package source directory.

3. Select Copy the Gradle files to Android directory if you plan to extend the Java part of your Qt application.
4. Select Finish to copy the template files to the `android` directory and to open the manifest file for editing.

The following table summarizes the options you can set.

Option | Value
--- | ---
Package name | A valid package name for the application. For example, `org.example.myapplication`. An automatically generated Java launcher that is packaged with the application into an APK launches the application.
Version code | An internal version number for the package that determines whether one version of the application is more recent than another.
Version name | The version number that is visible to users.
Minimum required SDK | The minimum API level required to run the application if you set it manually in the manifest file.
Target SDK | The targeted API level of the application, if you set it manually in the manifest file.
Application name | The application's name.
Activity name | An activity name.
Style extraction | The method that Qt uses to determine which UI style to use. For more information about package names, see Style Extraction.
Screen orientation | How to determine screen orientation.
Application icon | Images to use as application icons depending on screen resolution.
Splash screen | Images to display as splash screens depending on the screen orientation and resolution.
Permissions | The permissions that the application needs.

On the top header, select the XML Source tab to edit the file in XML format.

### Package Names

Android application packages are usually named using a hierarchical pattern with the levels in the hierarchy separated by periods (.). In general, a package name begins with the top-level domain name of the organization, followed by the organization's domain name and any subdomain names listed in reverse order. The organization can then choose a specific name for its package. Package names should be written in all lowercase characters whenever possible. For example, `org.qtproject.example`.

Complete conventions for disambiguating package names and rules for naming packages when the Internet domain name cannot be directly used as a package name are described in section 7.7 of the Java Language Specification.

For more information about package names, see Android Application Fundamentals.

### Screen Orientation

You can specify different options for determining screen orientation, depending on sensor readings or user preferences. The following table lists the options available.

Orientation | Description
--- | ---
Unspecified | The system chooses the orientation. The policy it uses, and therefore the choices made in specific contexts may differ from device to device.
Behind | Use the same orientation as the activity that's immediately beneath it in the activity stack.
Landscape | Landscape orientation, where the display width is larger than its height.
Portrait | Portrait orientation, where the display height is larger than its width.
Reverse landscape | Landscape orientation in the opposite direction of normal landscape.
Reverse portrait | Portrait orientation in the opposite direction of normal portrait.
Sensor landscape | Landscape orientation, but it can be either normal or reverse landscape based on the device sensor. The sensor is used even if the user has locked sensor-based rotation.
Sensor portrait | Portrait orientation, but it can be either normal or reverse portrait based on the device sensor. The sensor is used even if the user has locked sensor-based rotation.
User landscape | Landscape orientation, but it can be either normal or reverse landscape based on the device sensor and the user's preference.
User portrait | Portrait orientation, but it can be either normal or reverse portrait based on the device sensor and the user's preference.
Sensor | The orientation is determined by the device orientation sensor. The orientation of the display depends on how the user is holding the device. It changes when the user rotates the device. Some devices, however, will not rotate to all four possible orientations by default. To allow all four orientations, select the full sensor option. The sensor is used even if the user locked sensor-based rotation.
Full sensor | The orientation is determined by the device orientation sensor for any of the four orientations. This is similar to the sensor option, except it allows any of the four possible screen orientations, regardless of what the device usually does. For example, some devices won't normally use reverse portrait or reverse landscape, but this option enables them.
No sensor | The orientation is determined without reference to a physical orientation sensor. The sensor is ignored, so the display will not rotate based on how the user moves the device.
User | The user's current preferred orientation.
Full user | If the user has locked sensor-based rotation, this option behaves in the same way as the user option. Otherwise, it behaves the same as the full sensor option and allows any of the four possible screen orientations.
Locked | Locks the orientation to its current rotation, whatever that is.

### Icons

You can set different images to be shown as application icons and splash screens on low, medium, high, and extra high DPI displays. The following list summarizes the DPI values typically associated with each category:

- Low-density (LDPI): ~120dpi
- Medium-density (MDPI): ~160dpi
- High-density (HDPI): ~240dpi
- Extra-high-density (XHDPI): ~320dpi
- Extra-extra-high-density (XXHDPI): ~480dpi
- Extra-extra-extra-high-density (XXXHDPI): ~640dpi

Specify settings for icons in the Application icon tab. Select the image with the highest resolution as the Master icon. Qt Creator generates and sets resized versions for low, medium, high, and extra high-DPI displays, as needed. Alternatively, set the icons for each resolution separately.

### Splash Screens

Specify settings for splash screens in the Splash screen tab. Select images to display as splash screens depending on the device orientation and screen resolution.

By default, drawing an activity hides the splash screen. To keep it visible until QNativeInterface::QAndroidApplication::hideSplashScreen() is called, select Sticky splash screen.

In Image show mode, select whether to center the splash screen on the device display or scale it to fill the display.

Set a background color in Background color.

Select the images with the highest resolution as the Master image, Portrait master image, and Landscape master image.

Select Clear All to reset all settings or remove all images.

### Setting Permissions

Starting from Android 6.0 (API 23), applications have to request permissions at runtime (see QCoreApplication::requestPermission()). Users must grant these permissions when installing the application for lower Android API levels. The Android OS then grants the application access to the appropriate data and features.

Select Include default permissions for Qt modules and Include default features for Qt modules to add the permissions needed by Qt libraries, such as `android.permission.ACCESS_BACKGROUND_LOCATION` for Qt Positioning.

To add a permission, select it from the list, and then select Add.

See also How To: Build and Run, How To: Develop for Android, Android Run Settings, and Kits.

Developing for iOS ◦ Boot to Qt Deploy Configuration