Limit of active devices during Android device tests

Some time ago we decided to expand our pool of Android devices. These are used in our Continuous Integration (CI) pipeline. But running our tests we noticed a peculiar behaviour: Only 3 devices would execute the test suite while the rest would wait. As soon as a device finished one of the waiting devices would proceed.

As a result our device test would run roughly twice as long. We value fast build times and rapid feedback while still running large test suites. We had to fix this problem.

Investigating every sensible gradle switch or task configuration we still were unsuccessful. Then, frustrated, we decided to dig into the source code of the Google Android build tools project and understand just what was going on.

There, we realized that Google decided to use the Java Common Pool to trigger the device tests in parallel. This pool is  configured to use n = CoreCount – 1 threads per default. This observation fit perfectly, as we were currently running device tests on a Dual Core with Hyperthreading (4 “virtual” cores).

The default number of threads for the Common Pool can be configured with the JVM option java.util.concurrent.ForkJoinPool.common.parallelism

Gradle is triggered by our jenkins agent. We decided to “fix” our gradle installation by updating our installation-wide gradle-config:

/var/lib/jenkins/.gradle/gradle.properties:

#Allow more simultaneous device tests
systemProp.java.util.concurrent.ForkJoinPool.common.parallelism=10


Because the main load of the test execution should be carried by the devices itself we expected no negative consequences in this scenario. And indeed, setting this option to a higher value did allow all device to test in parallel, saving us valuable time.