An application manifest defines the various attributes of an application.
The available attributes are listed in the following table:
||string||Verbose name of the application. The following special characters are not allowed:
||string||Version to encode with the application. Maximum length is 50 characters.|
||string||Container instance type that all containers created for the application will use.|
||array of strings||List of permissions to automatically grant to the application. See Android Permissions for a list of available permissions. If
||string||Name or ID of an image to be used for the application. The default image is used if empty.|
||array||List of addons to be installed during the application bootstrap process.|
||array||List of tags to be associated with the application.|
||string||Package to launch once the system has booted (default: package name retrieved from the APK if APK file is present).|
||string||Activity of boot package to launch once the system has booted (default: main activity as defined in the application manifest).|
||string||Video encoder to be used by a container launched from the application (default:
||map||Watchdog settings to be configured on application installation.|
||array||Services to be provided from the installed application.|
||map||Resources to be allocated on application installation.|
||array||List of additional data to be installed on application installation.|
||object||Hooks settings to be configured on application installation.|
||object||Application bootstrap settings to be configured on application installation.|
image attribute defines which image the application is based on. If left empty, your application is based on the default image. See How to manage images for more details on this. Available images on your installation can be listed with the following command:
amc image list
A video encoder type can be specified through the
video-encoder field in the manifest file when creating an application, so that a container launched from the application can use a GPU or software video encoder according to different scenarios.
||A GPU-based video encoder|
||A GPU-based video encoder if GPU slots are not used up, otherwise, fall back to use a software-based video encoder|
||A software-based video encoder|
gpu video encoder is specified in the manifest, AMS can fail to create an application if:
- All GPU slots are used up by running containers.
- There is no GPU support across the entire LXD cluster.
watchdog attribute includes the following field definitions:
||Boolean||Toggle application watchdog on or off (default: false)|
||array of strings||Besides the boot package, list of packages to be allowed to display in the foreground|
When a container is launched, Anbox enables an application watchdog by default for the installed package unless it’s disabled explicitly with:
name: candy instance-type: a2.3 image: default watchdog: disabled: true
If one of the following scenarios occurs, the watchdog will be triggered. The container will be terminated and ends up with
- The application crashes or an ANR is triggered.
- The application is not in the foreground when an application which is not listed in
allowed-packageswas brought to the foreground and gained the focus.
- The boot package or activity is invalid.
- One of the
The rules forbid launching another activity, not part of the installed package or listed allowed packages. Launching activities of the same package is allowed.
['*'] to the
allowed-packages when the watchdog is enabled allows any application to be displayed in the foreground without triggering a watchdog.
A container launched from the installed application can expose
services you want to make accessible from outside the container. You must define the following properties for each service:
||string||Name of service|
||integer||Port number to be exposed by the service|
||array of strings||Protocols to be used by the service (Possible values are:
||Boolean||Expose service to be accessible externally or internally|
instance-type that is provided by AMS doesn’t meet the criteria that the installed application requires to function, you can use the
resources directive to override the predefined resources.
|Name||Value type||Minimum value||Description|
||integer||1||Number of vCPU cores|
||string||3 GB||Memory to be assigned to the application|
||string||3 GB||Disk size to be assigned to the application|
||integer||0||Number of GPU slots to be assigned to the application|
In the following application manifest file, the application is created with
a2.3 instance type, which will be assigned 2 vCPU cores, 3 GB of memory and a disk size of 3 GB. With the following resources defined in the manifest file, the allocated memory and disk size will end up at 4 GB and 8 GB, respectively, on application installation, and the number of vCPU cores remains the same:
name: candy instance-type: a2.3 resources: memory: 4GB disk-size: 8GB
If all required fields (
resources are supplied in the application manifest, the
instance-type field is no longer needed. Even if the
instance-type field is provided, it will be overridden by the requirements in the
resources fields upon application installation.
Some Android applications which contain large program assets such as graphics or media files use so-called OBB files to store additional data. These data files are separated from the APK and saved onto the external or internal SD card of an Android device. The
extra-data field can be used in this case to install an APK with separated OBB files or any other additional data into the Android system.
Each item of
extra-data should be declared as follows:
<name>: target: <target-path> owner: <uid>:<gid> # optional permissions: <file-permission> # optional
The fields have the following purpose:
||string||Name of file or directory to be installed into the Android file system|
||string||Target location for the file or directory|
||string||Owner assigned to the target file or directory in the Android file system|
||string||Permissions assigned to the target file or directory in the Android file system|
permissions represents Linux file permissions in octal notation.
It’s recommended to let Anbox choose the right values for
permissions instead of manually providing them. If
permissions are not specified, the following default values will be used:
|Name||App data installation directory||Type||Value|
|system data||Dir||boot package folder -> 0700, nested folders of boot package folder -> 0770|
Each item (file or folder) declared in the
extra-data field of the manifest YAML file should be placed in a directory called
For security reasons, the target location of the files and directories listed in the
extra-data section is restricted to a few specific locations in the Android file system. These are:
The manifest and extra data in our example are placed next to the application package, which must be named
. ├── app.apk ├── extra-data │ ├── com.canonical.candy.obb │ └── game-data-folder │ └── data.bin └── manifest.yaml
Hooks allow you to run custom scripts when a certain event is triggered in a container life cycle. See Hooks for more details about the usage of hooks in an application.
An application bootstrap can be fine-tuned through the
bootstrap attribute includes the following field definitions:
||array||Contents under the APP_DIR directory to be preserved in the application image after the bootstrap is finished. Wildcard patterns are supported. See pattern syntax for more details.|
To minimise the application size, most contents under the
APP_DIR directory are removed when the application bootstrap is finished. By default, only the metadata content is preserved (the
manifest.yaml file and the
hooks directory, if present). If a hook requires any other files under the
APP_DIR directory during the regular container runtime, you must include them in the application image.
name: my-application instance-type: a4.3 bootstrap: keep: - 'apks/*.apk' - 'scripts'
This will include the
scripts folder and all APK files under the
apks folder in the application image when the bootstrap is done, so that they are available to use during the regular container runtime.
Because it contains metadata, the
manifest.yaml file and the
hooks directory (if present) are not removed when the application bootstrap is finished and are always kept in the application image even if they are not explicitly defined in the
keep list under the