- 08 Jun 2022
- 3 Minutes to read
- Updated on 08 Jun 2022
- 3 Minutes to read
Build configuration settings
The keystore file is used to securely and uniquely sign your app binary, so that e.g. other apps can't pretend to be an update for your app.
For example, submitting an update to Google Play requires that the new app binary has been signed with the same keystore file as the original build.
To generate a keystore file, the easiest way is to use the
Java keytool (you need install JDK for this).
Lowest supported SDK version is 26!
Run the following command in your Terminal or Command Prompt (replacing
my-app-name appropriately) .
keytool -genkey -v -keystore my-app-name.keystore -alias my-app-name -keyalg RSA -keysize 2048 -validity 10000
You then need to input a password required to use the keystore. The owner, city etc. data are not necessary, but you can fill them in if you want. You ca enter a separate password for the alias, but that's not necessary either.
In Composer on the Keystore tab, you have the following fields:
- Keystore file – your
my-app-name.keystorefile is uploaded here
- Keystore password – enter the password you gave when generating the keystore
- Keystore alias – enter the keystore alias (
my-app-namein the above example)
- Keystore alias password – unless you set a separate alias password, this is the same as Keystore password
This setting defines the unique package identifier for your binary APK package. It must be in reverse domain format, e.g.
This is the name for your app shown under the app icon in the device home screen, as well as in settings and other places.
A URL Scheme enables the user to launch your app via a hyperlink from an external app or website. For example, if you try to open Google Maps via your phone's browser, you will be presented with a prompt asking if you want to open the app instead.
Define the URL scheme via this universal format:
On the Build Settings page you can choose a runtime version and set the version properties for the build.
Build scheme (File Type)
APK - Android's installable, executable format for apps. It is used best for testing and P2P app sharing.
AAB - Android App Bundle is only for publishing and contains the entire program code of the Android app. It cannot be used to install apps on Android devices, but is used to optimize the size of a build.
Since August 2021, Google Play is requiring new apps to be published with the Android App Bundle (AAB).
Internal version code for the app, given as an integer, e.g.
10000. When you publish an update to your app in Google Play, its version code must be higher than previous version codes.
Semantic version name for the current build, e.g.
1.0.0. Shown in device settings and other places.
Why is the file size of Android builds so big?
Our Build Service produces what is called fat binaries. In short, the binary includes optimized support for several different processors. This makes the size of the build to be large even when the app is only a one page application.
If you have built an AAB and intend on uploading your app to Google Play, this fat binary will be processed by Google Play in such a way that the app your users download includes only the support for the device they are using. Thus the app size each user downloads and installs is smaller than the original AAB file. Please check out this guide by Google Play on how to see the actual download and install size of your application.
For APK, we aim to provide an option to build only a generalized apk to reduce the file size alongside the fat APK version available currently.
Image assets and permissions
Check out this guide.
The APK package generated by the Build Service is essentially the same as you would get building an app with Android Studio manually.
You can install it on your device with an USB cable, upload it somewhere and share it as a direct-download link, publish it via Google Play or use a mobile app management solution to manage distribution.