Android – Bitrise

Screen recording your UI tests with Appium
Appium is a popular testing framework to catch defects in native, hybrid, and web apps. You can easily integrate your Appium UI tests into your own Bitrise workflow using our Script Step. This way you can have the whole testing screen recorded and can visually verify if your app is doing what it’s supposed to do.

In this guide we’ll show how to kickstart Appium and run your UI test specified in the test.js file, then retrieve the test results and view them on bitrise.io.

ADB workaround for Javascript

Javascript does not support the in-built screen recording and screen capturing commands so we’re using ADB shell commands as a workaround. For all the other languages, check out Appium’s Start Recording Screen guide.

We will use our Script and Deploy to Bitrise.io Steps. Here is why:
- The Script Step executes what you insert in its input field.
- The Deploy to Bitrise.io Step delivers your test result to the Artifacts tab of your Build’s page.
Let’s put this all together!
1. Insert the Script Step as the first Step in your Workflow.
2. Insert the following command to the Script content input field.
  
  appium &> $BITRISE_DEPLOY_DIR/logs.txt & disown npm test
  
  You will find the above mentioned logs.txt file in the Bitrise deploy directory (BITRISE_DEPLOY_DIR). This logs.txt file contains the outputs of the Appium server. With the help of the Deploy to Bitrise.io Step, you will be able to download this file from the Artifacts tab.
3. Since screen recoding is not supported through Javascript, we advise you to add the screen recording / screen capturing and the file retrieving shell commands to your own test.js file.
4. Once you have pulled the test results (which in this case can be videos and screenshots) from the emulator, make sure you move them to the Bitrise deploy directory (BITRISE_DEPLOY_DIR).
5. Insert the Deploy to Bitrise.io Step to your workflow so that it can export your test results to the Artifacts tab on your Build’s page.
6. Start a build!
If all went well, you should be able to view the generated test results on the Artifacts tab of your Build’s page.
Screen recording of Android UI tests with Script Steps
Issue

You want to run your UI test specific to your Android app and have the whole process screen recorded using one Bitrise Workflow.
Possible solutions

Here is an example workflow containing the steps we will use in this guide:
Add the AVD Manager Step at the beginning of your Workflow to create and run an Android Virtual Device.

Add the Wait for Android Emulator Step after the AVD Manager Step. This Step makes sure that the Android emulator has finished booting before the screen recording would start.

Add a Script Step after the Wait for Android Emulator Step. (We’re renaming this Script Step as Start screen recording Step.)

Insert the following commands to the Script content input field:

$ANDROID_HOME/platform-tools/adb shell "screenrecord /sdcard/video.mp4 --verbose" &> $BITRISE_DEPLOY_DIR/logs.txt & disown $ANDROID_HOME/platform-tools/adb shell "screencap -p /sdcard/screen.png" &> $BITRISE_DEPLOY_DIR/logs.txt & disown

The Start screen recording Step:

Starts screen recording before UI testing.

Captures a screenshot of the emulator screen BEFORE the UI test would start.

Add another Script Step after the Start screen recording Step. (We will call it Run UI test Step.)

Add your script (for example, Maven, npm or Appium tests) in the Script content input field to call and run your UI test.

Insert the third Script Step (Stop Screen recording & get file from emulator) after the Run UI tests Step.

Add the following script to the Script content input field.

$ANDROID_HOME/platform-tools/adb shell "killall -INT screenrecord" sleep 10 $ANDROID_HOME/platform-tools/adb pull /sdcard/video.mp4 $BITRISE_DEPLOY_DIR/video.mp4 adb pull /sdcard/screen.png $BITRISE_DEPLOY_DIR/ $ANDROID_HOME/platform-tools/adb shell "screencap -p /sdcard/screen2.png" &> $BITRISE_DEPLOY_DIR/logs.txt & disown adb pull /sdcard/screen2.png $BITRISE_DEPLOY_DIR/

Stop Screen recording & get file from emulator Step does the following:

Stops the screen recording.

Gets the screen recording.

Gets those Emulator screenshots that had been taken before UI tests started.

Gets the final screenshot of the Emulator screen.

Places these files in the BITRISE_DEPLOY_DIR path.

Add the Deploy to Bitrise.io - Apps, Logs, Artifacts Step to your workflow to export all files stored in the BITRISE_DEPLOY_DIR directory to Artifacts. You can check these files at the Artifacts tab of your Build’s page. (Note that if you did not place the files in this directory, they will not be deployed to the Artifacts tab of your Build’s page.)
If your build fails due to No such process (error message below) or an Enemphasisr failed (err=-38) error in your build log, most likely the screen resolution of the screen recording and the device does not match.
```
/opt/android-sdk-linux/platform-tools/adb shell 'killall -INT screenrecord' killall: screenrecord: No such process
```
Here is what to check:
Check if you have the right resolution set in the Resolution field of the AVD Manager Step.

If you’re NOT using the AVD Manager Step to start the emulator (and use Script Step instead), then you can fix the screen size in the Script content field of the Start screen recording Step by specifying the width and height of the screen: --size <WIDTHxHEIGHT>.
Could not find an Android package/license agreements not accepted
Issue:

Could not find an Android package or you have not accepted the license agreements.
```
> A problem occurred configuring project ':lib'. 
   > You have not accepted the license agreements of the following SDK components:
   [Google Repository]. 
   Before building your project, you need to accept the license agreements and complete the installation of the missing components using the Android Studio SDK Manager. 
   Alternatively, to learn how to transfer the license agreements from one workstation to another, go to http://d.android.com/r/studio-ui/export-licenses.html
```
or
```
Could not find com.android.support:appcompat-v7:24.2.0.
```
Possible solutions:

In general, we recommend you use the Install missing Android SDK components Step.

The above error means that your build requires an Android package which is either not (yet) preinstalled. You can see which packages are preinstalled on GitHub or which are the outdated ones.

The solution is to install/update the related package(s). To do that, add a Script Step to your Workflow. The Script Step should be added before the Step where you get the error or it can be the very first Step in the Workflow - with the following content:
```
#!/bin/bash
# fail if any commands fails
set -e
# debug log
 set -x 

# For newer Android SDK:
sdkmanager "extras;android;m2repository" 
sdkmanager "extras;google;m2repository" 
# For older Android SDK: 
echo y | android update sdk --no-ui --all --filter extra-android-m2repository | grep 'package installed'
echo y | android update sdk --no-ui --all --filter extra-google-m2repository | grep 'package installed'
```
In most cases you don’t need both packages to be updated, so you can try to remove them one by one, but having all three in the script covers most of the cases related to this error.

If the error is related to an outdated package, the workaround we describe here can be removed from your build after the weekend update is completed.
Alternative solution: Locating the licenses on your Mac/PC

If you have accepted the license agreements on one workstation, but wish to build your projects on a different one, you can export your licenses:

Copy the accepted licenses folder from the Android Sdk Home folder (this should be located at <android sdk home path>/licenses) of your current workstation) to the Android Sdk Home directory of the machine where you now want to build your projects.

Create an android-licenses directory in the root directory of your git repository, and copy the license files into this directory, then in your Workflow copy the licenses to the right location using a Script Step.

Add the Script Step right after the Git Clone Step (that’s when your code is available on the build virtual machine), with the content:

#!/bin/bash # fail if any commands fails set -e # debug log set -x rsync -avhP ./android-licenses/ "$ANDROID_HOME/licenses/"
Bitrise can't build applications with BuildSrc Kotlin DSL configuration

Issue:

Trying to build applications with a BuildSrc Kotlin DSL configuration always fails.

Possible solutions:

Convert all build.gradle files from Groovy to Kotlin, and convert them to build.gradle.kts.

Additional information

Kotlin DSL scripts
Tips for flaky Android emulator tests
Issue:

Running builds takes longer in CI than on a powerful developer machine.
Possible solutions:

CI environments are performance constrained by nature, and the Android emulator is unfortunately very resource-intensive both in terms of CPU and memory. This slowdown can also surface race conditions and other strange bugs in the application and test code.

Here are some general tips that can help to narrow down the problem:
Make sure individual test cases are isolated and don't depend on the state of a previous test case or test run. Cases are executed in random order, so sometimes a test only passes if a given test case was run before, setting up the app state in a certain way (database, SharedPreferences, caches).

Run your test suite multiple times and try to notice a pattern in the failing test cases. Is it always the same cases that fail, or the failure happens in a random way among cases?

Do you make real network calls in your tests, or you have mocked APIs? Real network calls can take longer (or fail for various reasons) in a CI environment, so these tests will always be flakier than mocked ones.
Tips specifically related to the [BETA] Android Virtual Device Testing step:
Set the Use Orchestrator input to true in the Step's Instrumentation Test section. This improves isolation between test cases, making your tests less likely to fail. You can see the benefits and drawbacks of Orchestrator here.

You can also set the Number of times a test execution is reattempted input in the Step's Debug section. If this value is higher than 0, then failed tests will be reattempted this many times before marked as failed.
Gradle build fails with exception: New files were found
Issue:

You get the following error message with your Gradle build:
```
Caused by: java.io.IOException: Unable to delete directory '/bitrise/src/app/build'
  New files were found. This might happen because a process is still writing to the target directory.
```
Possible solutions:

Make sure you don't run the :clean Gradle task during the build. There is no need to do a clean build, because each Bitrise build starts with an empty virtual machine state.
Generated APK has different version code after Xamarin build step

Issue:

The APK built by the Xamarin Archive Step has a different versionCode in AndroidManifest.xml than what is defined in the project.

Possible solutions:

Make sure it's not caused by your Xamarin project's version code pattern config.

Additional links:

Use MSBuild to Define Advanced Android VersionCode
Intermittent connection/timeout issues when downloading Android dependencies
Issue:

When Gradle attempts to download dependencies, you get intermittent timeout or connection errors.
Possible solutions:

There are numerous reasons why this can happen, and several potential solutions.
Limiting the Maximum Number of Gradle Workers

Connection issues might increase after upgrading to a more powerful machine. This is because Gradle uses the additional processor threads to download more dependencies simultaneously. This can result in rate limiting errors.

One workaround is to limit the number of threads Gradle can use by specifying the maximum number of workers.

If you are calling a Gradle task from a Script Step, add the following argument:

--max-workers=4

Alternatively, you can add the following to your gradle.properties file:

org.gradle.workers.max=(max # of worker processes)
Retrying Failed Connections

Some dependencies from third parties may be using unstable hosting. In these instances, retrying a failed download can sometimes resolve the issue and keep the build from failing.

To have Maven retry connections, add the following to your gradle.properties file:

maven.wagon.http.retryHandler.count = 5
Committing Dependencies to Source Control

We highly recommend committing dependencies to your repository. Not only does this help with stability, but it dramatically decreases build times as well.
Additional information:
Limiting Gradle threads.

Retrying Maven connections.

Committing dependencies to source control.
Using Android SDK tools with Java 11
Issue:

After switching from Java 8 to Java 11 on the build machine, some Android SDK commands fail with this error:
```
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
at com.android.repository.api.SchemaModule$SchemaModuleVersion.<init>(SchemaModule.java:156)
at com.android.repository.api.SchemaModule.<init>(SchemaModule.java:75)
at com.android.sdklib.repository.AndroidSdkHandler.<clinit>(AndroidSdkHandler.java:81)
at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:73)
at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:48)
```
Commands that fail with this error include avdmanager and sdkmanager.
Possible solutions:

Android SDK tools are not yet compatible with Java 11 and need Java 8 (1.8) to run correctly. The Bitrise stacks provide both Java 8 and Java 11, with Java 8 being active by default.

If you need a Java 11 runtime for your project to compile, you can switch to Java 11 only before it's needed by the next Step. Any previous Steps will continue to use the Java 8 runtime.

Additional information:

Switching to Java 11 on Bitrise
Building Android apps with Flutter modules on Bitrise

Issue:

If a hybrid app contains both Android and Flutter code, for example, which type should be chosen when connecting the app to Bitrise?

Possible solutions:

We recommend following Flutter's Integrate a Flutter module into your Android project guide to integrate Flutter code into an Android project. When Flutter code is embedded as a module into the project, then Bitrise will recognize it as an Android project and set up your Workflows accordingly.
Deploy to Google Play fails with 403 error
Issue:

The Deploy to Google Play Step throws the following error:
```
 "error: Failed to perform edit insert call, error: googleapi: Error 403: The caller does not have permission, forbidden"
```
Possible solutions:

Set the value of the BITRISE_DEPLOYER_SERVICE_ACCT_KEY Env Var into a valid URL containing your json file.
Upload the account key into the Generic File Storage section of the Code Signing tab on Bitrise directly.

Reference the resulting URL in the Service Account JSON key file path of the Deploy to Google Play Step in your Workflow.
Additional information:
Google Play Deploy Step

Generic file storage on Bitrise
Install missing Android SDK components Step fails with exit status 127
Issue:

The Install missing Android SDK components Step throws the following error:
```
Failed to ensure android components, error: output: /usr/bin/env: ‘bash\r’: No such file or directory error: exit status 127
```
Possible solutions:

The error message suggests that your app's gradlew has Windows-style \r\n line endings instead of the \n-only line ending of Unix. You will need to replace the \r\n line endings with \n.

You have two options to fix the problem:

You can use a Script Step as a workaround. In the Script content input, add the following:
```
awk 'BEGIN{RS="^$";ORS="";getline;gsub("\r","");print>ARGV[1]}' ./gradlew
```
However, the optimal way is to make sure that Git uses a specific style of line endings in the working directory. To do so, put the following into a .gitattributes file inside your repo:
```
* text=auto
gradlew text eol=lf
*.sh text eol=lf
```
V2 code signing of an APK fails

Issue:

When using the Android Sign Step for V2 code signing of an APK, it fails.

Possible solutions:

If you have failures with the Android Sign Step, please make sure you are using the latest version of the Step. Also, make sure that you are using Java 11.

The Bitrise stacks have both Java 8 and Java 11 installed. However, Java 8 is active by default. You will need to include a script Step to switch to use Java 11.
Test failed with [BETA] Virtual Device Testing for Android step
Issue:

Running the [BETA] Virtual Device Testing for Android Step, you receive the following error:
```
Waiting for test results
- Validating
- (1/1) running
- (0/1) running
=> Test finished
Test results:
Model API Level Locale Orientation Outcome 
Pixel2 27 ja portrait failure(TimedOut) 
```
Possible solutions:

The following steps should provide a possible solution for this issue:
1. Add the Run yarn command Step after your Cache:Pull Step to install dependencies.
2. Add the Android SDK Update Step after your Run yarn command Step to update your Android SDK Tools.
3. Change the Number of times a test execution is reattempted input value to 5 In your [BETA] Virtual Device Testing for Android Step under the Debug section. Firebase test can be flaky and may need to be retried.
Google Deploy tracks
Issue:

The Deploy to Google Play Step fails with the following error:
```
Failed to update track, reason: could not find track with name alpha
```
Possible solution:

Google's deployment solution is organized into different channels which are called tracks. The submission API used for our Step is case sensitive. Check and verify that the name you specified is correct. For example, in the case of the error about you must specify the name as "Alpha" with a capital "A".
Google Play Deploy Step Fails: version code already used
Issue:

When trying to deploy your app using the Google Play Deploy Step, it fails with the following error:
```
Failed to upload APKs: failed to upload app bundle, error: googleapi: Error 403: APK specifies a version code that has already been used.
```
Possible solutions:

This error occurs because, as the error message suggests, you're trying to deploy an app with a versionCode that has already been used to deploy the same app. To fix this:
In your Android project's build.gradle file, remove the lines that set the versionCode and versionName located under the default config:

android { ... defaultConfig { ... versionCode 1 versionName "1.0" ... } }

In the AndroidManifest.xml file, add those definitions:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="YOUR_PACKAGE_NAME" android:versionCode="1" android:versionName="1.0">
Error: Missing cmdline-tools
Issue:

When building an Android app, you run into an error that looks similar to this:
```
Cannot run program "/usr/local/share/android-sdk/cmdline-tools/latest/bin/sdkmanager": error=2, No such file or directory
```
Based on the error it may seem like that cmdline-tools is missing from our stacks.
Possible Solutions:

You can confirm that cmdline-tools are installed on our stacks running a script like sdkmanager --list. If it exists, the command fails due to the path it is trying to use.

The command is trying to access this path: /usr/local/share/android-sdk/cmdline-tools/latest/bin/sdkmanager.

The path in our stacks for sdk manager is the following: /usr/local/share/android-sdk/cmdline-tools/cmdline-tools/bin/sdkmanager.

Based on this information, you can create a symlink with the following script:
```
mkdir /usr/local/share/android-sdk/cmdline-tools/latest/
mkdir /usr/local/share/android-sdk/cmdline-tools/latest/bin/
ln -s /usr/local/share/android-sdk/cmdline-tools/cmdline-tools/bin/sdkmanager
/usr/local/share/android-sdk/cmdline-tools/latest/bin/sdkmanager
/usr/local/share/android-sdk/cmdline-tools/latest/bin/sdkmanager --licenses
```
Your symlink should now allow for the program to run on the correct path.
The Install missing Android SDK components Step takes uncommonly long

Issue:

The Install missing Android SDK components Step in your Workflow takes 20-30 minutes instead of the normal amount of time.

Possible solutions:

This is most likely beause there is no SKD specified in the inputs of the Step, and without this, it evaluates Gradle and makes Gradle initialize the project and download the 3rd party dependencies, making it a much longer process.

Specifying the SDK should solve this issue.
Build Tools revision is corrupted
Issue:

You are running an Android Unit Test Step, on the Android & Docker, on Ubuntu 20.04 stack, and you encounter the following error:

Installed Build Tools revision 33.0.0 is corrupted. Remove and install again using the SDK Manager.
Possible solutions:

Try adding the following script before the Step that fails:
```
#!/usr/bin/env bash# fail if any commands failsset -e
# debug logset -x

# write your script here
sdkmanager --install "build-tools;33.0.0" &&

  cd /usr/local/share/android-sdk/build-tools/33.0.0 \
  && mv d8 dx \
  && cd lib  \
  && mv d8.jar dx.jar```
```
Managing multiple APKs in a single build
A common problem you may face when building multiple Android modules is managing all the Artifacts generated during your builds.

Public install pages

The Deploy to Bitrise.io Step generates a public install page for all Artifacts.

The default Environment Variables generated by Bitrise are:
- $BITRISE_APK_PATH: The relative path of the first generated APK of your build.
- $BITRISE_APK_PATH_LIST: A list of every APK in your build.
If you want to use all APKs, you can do so with the $BITRISE_APK_PATH_LIST.

If you would like to use a specific APK for a Step, like the Android Sign Step, you can:
- Rearrange the order of your Android modules so that the APK you want becomes the first module.
- Provide the absolute path to your APK. For example: /bitrise/deploy/app-module-variant-unsigned.apk
- Assign a custom Environment Variable to the absolute path of your APK.

ADB workaround for Javascript

Issue

Possible solutions

Issue:

Possible solutions:

Alternative solution: Locating the licenses on your Mac/PC

Issue:

Possible solutions:

Additional information

Issue:

Possible solutions:

Issue:

Issue:

Possible solutions:

Additional links:

Issue:

Possible solutions:

Limiting the Maximum Number of Gradle Workers

Retrying Failed Connections

Committing Dependencies to Source Control

Additional information:

Issue:

Possible solutions:

Additional information:

Issue:

Possible solutions:

Issue:

Possible solutions:

Additional information:

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible solution:

Issue:

Possible solutions:

Issue:

Possible Solutions:

Issue:

Possible solutions:

Issue:

Possible solutions:

Public install pages