Instrumentation run failed due to 'Process crashed.'

I use this workflow below, however, sometime I got this error:

Tests on Android_Emulator(AVD) - 5.1.1 failed: Instrumentation run failed due to 'Process crashed.' > No tests found.[Android_Emulator(AVD) - 5.1.1] FAILED 
No tests found. This usually means that your test classes are not in the form that your test runner expects (e.g. don't inherit from TestCase or lack @Test annotations).
:my-app:connectedAndroidTest FAILED

FAILURE: Build failed with an exception.

Sometime, everything works fine.
My instrument test is very simple and I only do one test. Do you have any idea for that issue?

Here is my workflow:

    - activate-ssh-key@3.1.1:
        title: Activate App SSH key
        - ssh_key_save_path: "$HOME/.ssh/steplib_ssh_step_id_rsa"
    - git-clone@3.4.1: {}
    - script@1.1.3:
        title: Copy Android Licenses
        - content: |-
            # fail if any commands fails
            set -e
            # debug log
            set -x

            echo y | android update sdk --no-ui --all --filter build-tools-23.0.2 | grep 'package installed'
            echo y | android update sdk --no-ui --all --filter addon-google_apis-google-22
            echo y | android update sdk --no-ui --all --filter sys-img-armeabi-v7a-google_apis-22 | grep 'package installed'
            if [ -d "./android-licenses/" ]; then
              rsync -avhP ./android-licenses/ "$ANDROID_HOME/licenses/"
    - create-android-emulator@1.0.0:
        - name: "$BITRISE_EMULATOR_NAME"
        - platform: android-22
        - custom_hardware_profile_content: ''
    - start-android-emulator@1.1.1: {}
    - gradle-runner@1.5.4:
        - gradle_file: "$BITRISE_PROJECT_PATH"
        - gradle_task: connectedAndroidTest
            is_expand: false
    - script@1.1.3:
        title: Kill all emulators
        is_always_run: true
        - content: |-
            # fail if any commands fails
            set -e
            # debug log
            set -x
            ls -l /opt/android-sdk-linux/tools/
            adb devices | grep emulator | cut -f1 | while read line; do adb -s $line emu kill; done
    - deploy-to-bitrise-io@1.2.7:
        - deploy_path: "$BITRISE_SOURCE_DIR/my-app/build/reports/androidTests/connected/flavors/"
        - notify_user_groups: none
        - notify_email_list: ''

I’d suggest you to Google for:

There can be quite a few reasons for this.

Another thing worth to try is to run the build locally, on your Mac/PC:

I think this can also mean that your app crashes during launching / before the test would start, but of course without the code it’s quite hard to debug or advise something better than to follow the local debugging guide (above).

Hi @viktorbenei, Thank you very much for you quick reply.
I also google a lot for the issue, but I can not find any answer so I posted my question here.
For run my build locally on Mac, I try and it always run successfully.
I also try with docker (your article you sent) and it also run successfully every time.
I believe the app doesn’t crash because the test only run fail in Bitrise. Can you help me?
Thank you very much.

If it runs good locally using docker then it’s not Bitrise, it’s more likely something like the amount of RAM.

How much RAM do you have on your Mac?

My Mac Ram is 16 GB, 1600 MHZ (DDR3)
My Mac Proccessor is: 2.5 GHz Intel Core i7.

My docker setting up is:
8GB Memory

Hi @viktorbenei,
I think you are right, seem like the issue cause by the memory of Ram we use.
When I share docker with only 2G memory, I can not run successfully,
However, when I change to 3G, every build is success.
Do you know how much memory of Ram we use in Bitrise?

1 Like

On Linux/Android you have 7.5GB RAM, and on the Mac stacks you have 4GB RAM.

If RAM is the issue, you can try to limit RAM usage of JVM for example, see:

Another option can be that we now have more powerful configurations (with double RAM, 15 GB and 8 GB). If you’re interested we can invite you to the private beta, but these configs will cost more once publicly available (in the next couple of weeks).