Skip to main content
Momentic offers two options for automating Android apps. Remote emulators are hosted through a third-party provider and offer a scalable fleet of instances that boot within seconds. Simply upload the APK you wish to test, and we’ll take care of the rest. Local emulators use your local Android Studio installation to create an emulator that runs on your own machine. In this setup, you’ll have to specify an Android Virtual Device (AVD) and APK file that already exist locally.

​
Choosing a platform

We recommend that teams use either remote or local emulators for all tests, and avoid mixing the two. The platform can be chosen when creating or editing a test through the Region dropdown menu. Choosing the Local region activates the local emulator mode; selecting any other region activates the remote emulator mode.

​
Remote emulators

When using remote emulators, Momentic provides fresh emulator instances on-demand when launching the local app or executing a mobile test. Average provisioning time is under 1 second.

​
APK and app management

App installation for remote emulators is managed through channels and tags. Build artifacts can be uploaded through the Momentic Mobile app in the Assets page, or via the momentic-mobile assets upload command. Channels are generally distinct release environments, such as dev, staging, and production. You can also use channels to separate different apps, such as production-trading and production-banking. Tags are versions within a particular channel. We recommend that teams use semver tags, such as 0.0.1 and 1.2.0, or some other identifier that can be easily tied to code changes. Each platform may have a build for each channel/tag combination. For example, the production channel may have a 1.2.0 build, with both an Android APK and iOS app. When creating or editing a test that uses remote emulators, you will be prompted to choose a channel and tag.

​
App requirements

For Android tests, Momentic requires an APK file.
If the uploaded APK contains WebView content that you want to automate, enable WebView debugging with WebView.setWebContentsDebuggingEnabled(true) so Momentic can attach to the WebView.

​
Region

The Region property on each test’s settings defines where your emulator will be created. If unset, the closest region to your IP address will be chosen. Currently, Momentic’s emulator provider supports two regions: US West and EU North. If you are located far away from both regions, we highly recommend using local emulators instead for improved latency.

​
Android versions

Currently, Android 14 and 15 are supported. This setting can be configured in each test’s options.

​
iOS versions

Currently, only iOS 26 is supported. If you would like to test on different iOS versions, please reach out to the Momentic team.

​
Local emulators

​
Android emulators

​
Configuration

When using local emulators, users are responsible for building, storing, and sharing AVDs that have the desired settings, including the Android version, Play Store version, and device size. Users then provide this AVD ID to Momentic. To install an APK, there are several options:
  1. Install APK step: Given an APK path that is accessible on disk, you can use a preset Install APK step at any point in a test.
  2. Test-level APK path setting: An APK path can be specified in each test’s settings. This APK will be automatically installed on emulator start.
  3. Inherit APK settings from the environment: see the section below on how to read configuration from environment variables.

​
Environment-based Android settings

Some teams may not share APKs or AVDs during development. In this case, it can be cumbersome to constantly change the AVD ID or APK path at the test level. Configuring these settings at the environment level instead solves this problem. Specifically, rather than setting AVD ID or APK path at the test level, users can define the LOCAL_AVD_ID and LOCAL_APK_PATH keys in an environment. Then, users can leverage Momentic’s ability to interpolate environment variables using the shell to achieve dynamic behavior on each developer’s machine. For example, the environment below will first read the LOCAL_AVD_ID from the MOMENTIC_AVD_ID env var from the surrounding shell, and default to Pixel_9_API_35 if this env var is unset. Similarly, the local APK path will first be read from the MOMENTIC_APK_PATH env var.
momentic.config.yaml
environments:
  - name: local
    envVariables:
      LOCAL_AVD_ID: ${MOMENTIC_AVD_ID:-Pixel_9_API_35}
      LOCAL_APK_PATH: ${MOMENTIC_APK_PATH:-../../data/android-test-apks/drag-drop-native/app-debug.apk}
Each developer then can set their own MOMENTIC_AVD_ID and MOMENTIC_APK_PATH in a .env file or in their ~/.zshrc, avoiding the need to commit these configuration changes to source control. Note that environment-based configuration is only active if the test is set to run in that environment. In addition, there cannot be any overrides at the test level.

​
Overrides in CI

When executing tests in CI, Momentic’s run command supports the --local-avd-id and --local-apk-path flags to make overriding local emulator configuration easy. These flags take precedence over all other configuration.

​
iOS simulators

​
Configuration

To install an app on a local iOS simulator, there are several options:
  1. Test-level app path setting: An app path can be specified in each test’s settings. This app will be automatically installed on simulator start.
  2. Inherit app settings from the environment: see the section below on how to read configuration from environment variables.
  3. CLI flag overrides: When executing tests or launching the local editor, use the --local-app-path and --local-ios-device-type flags to make overriding local simulator configuration easy. These flags take precedence over all other configuration.

​
Environment-based iOS settings

Some engineers may have different file system setups and may want to use different apps or simulators when running tests locally. In this case, it can be cumbersome to constantly change the device type or app path at the test level. Configuring these settings at the environment level instead solves this problem. Specifically, rather than setting device type or app path at the test level, users can define the LOCAL_IOS_DEVICE_TYPE and LOCAL_IOS_APP_PATH keys in an environment. Then, users can leverage Momentic’s ability to interpolate environment variables using the shell to achieve dynamic behavior on each developer’s machine. For example, the environment below will first read the LOCAL_IOS_DEVICE_TYPE from the MOMENTIC_IOS_DEVICE_TYPE env var from the surrounding shell, and default to iPhone 17 if this env var is unset. Similarly, the local app path will first be read from the MOMENTIC_IOS_APP_PATH env var.
momentic.config.yaml
environments:
  - name: local
    envVariables:
      LOCAL_IOS_DEVICE_TYPE: ${MOMENTIC_IOS_DEVICE_TYPE:-iPhone 17}
      LOCAL_IOS_APP_PATH: ${MOMENTIC_IOS_APP_PATH:-../../data/ios-test-apps/drag-drop-native/app-debug.app}
Each developer then can set their own MOMENTIC_IOS_DEVICE_TYPE and MOMENTIC_IOS_APP_PATH in a .env file or in their ~/.zshrc, avoiding the need to commit these configuration changes to source control. Note that environment-based configuration is only active if the test is set to run in that environment. In addition, there cannot be any overrides at the test level.

​
Overrides in CI

When executing tests in CI, Momentic’s run command supports the --local-ios-device-type and --local-app-path flags to make overriding local simulator configuration easy. These flags take precedence over all other configuration.