Skip to content

Many of you have switched to Android Studio already or if not are at least planning to migrate into this new development environment at some point. Android Studio has advanced to version and everything seems to work smoother than ever before – and this also makes testing easier and access to real devices through plugins a great option.

Regardless if you are using Android Studio (where Gradle is the default build system) you may use Gradle also with other development tools as well. Here are the basic steps and instructions of how to use our Gradle plugin to build an instant and seamless bridge between your development environment and our devices at Bitbar Testing.


In case you are using Gradle Plugin with Android Studio (or some other development tool/environment), you can use our Gradle Plugin that takes care of automatically uploading your latest builds into Bitbar Testing.

However, it is worth mentioning that the Android Studio isn’t the only development environment where Gradle is used a lot and integrated as a default build system. For example, many of our users are also using continuous integration environments/tools (e.g. TeamCity) that integrate nicely with Gradle and naturally these instructions are very relevant for them as well.

Step #1: Install and Configure Bitbar Gradle Plugin

The installation of any Gradle compatible plugin is very easy and straightforward. In fact, all you need to do is to add few configuration lines in your file and the system will take care of the rest. When doing this, you typically have two different files – one specific for Project and one for Module. To make it easier to adopt these configurations for a variety of different projects, you should modify the Module specific file.

Screen Shot 2015-05-26 at 9.58.12 AM


This file can be further modified with different setups, but the basic three required configurations are as follows: First of all, you need to apply our plugin.

apply plugin: 'testdroid'

Applying a plugin to the project allows the plugin to extend the project’s capabilities. For example, this allows adding tasks to projects (compile and upload the latest APK to our platform).

Next one is to configure your credentials and setups for Bitbar Testing:

testdroid {
    username ''
    password 'password'
    deviceGroup 'MyTestDevices'
    mode "FULL_RUN"

Place your login credentials for username and password. Also, set up the device group that against you want to run your APK. For example, MyTestDevices is the demo user specific device group (not available as a default device group) and includes 8 pre-selected devices. We’ll take a look at this device group later in this post.

For the next thing, set dependency for classpath and in this case, it should be com.testdroid:gradle:1.3.0. Our Gradle plugin naturally evolves and develops over time, so please check the latest version from here. For the dependency configuration, please use the following line as part of the buildscript -> dependencies:

buildscript {
    repositories {
    dependencies {
        classpath 'com.testdroid:gradle:1.3.0'

Congratulations! You’ve now successfully configured Bitbar devices to your Gradle build environment and all your builds can be nicely pushed to our devices for testing.

Step #2: Running Tests on Bitbar Device Cloud

With the above configuration, your application and possible instrumentation package are uploaded automatically into Bitbar Testing and test run is launched using a device from group ‘MyTestDevices’. In case you want to add more advanced options for test run creation, execution and so on, please check the ‘Bonus’ chapter at the end of this post.

There are basically two quick ways to get your app (and instrumentation app) up and running on our cloud. You can either do it from the command line by going to a project-specific path (e.g. /Users/vvhelppi/AndroidStudioProjects/MyApplication2) and executing the following command:

./gradlew testdroidUpload

or using the Android Studio’s Gradle Projects view and double-clicking testdroidUpload under Tasks (app -> verification):

Screen Shot 2015-05-26 at 10.36.13 AM

Now, the project will be compiled, all dependencies will be fetched (done only once on the first time) and app + possible instrumentation package will be uploaded to the platform. The Run log should look something like this:

Screen Shot 2015-05-26 at 10.41.31 AM

Step #3: All Done – Let’s Review the Results!

After each test run, you’ll get all the details of your test run, such as logs, screenshots, performance stats and much more – and all this are conveniently shown in our easy-to-use UI.

Screen Shot 2015-05-26 at 11.39.47 AM

In example above, we ran empty Android Studio app project on 8 devices. The Test Execution time is minuscule as there isn’t much logic in an empty app. Also, the App Crawler run targeted for this sort of app basically checks whether the app can be appropriately launched and stopped – and use those as test cases.

More about results, reviewing test runs and efficient comparison of test runs in the following video:

Bonus! Advanced Configuration Parameters

To get all out of this awesome “development tool – real device” combination you might want to consider further modifying and configuring your test runs. We’ve done this easy as part of the configuration illustrated above, and the following additional parameters can be used:

testdroid {
    username  ""                       // Username
    password "password"                                 // Password
    deviceGroup "MyTestDevices"                         // Device group for execution
    cloudUrl = ''            // Optional - Used for PrivateCloud configs
    projectName "Project 1"                             // Optional - Default: create a new project
    mode "FULL_RUN"                                     // FULL_RUN / APP_CRAWLER / UI_AUTOMATOR
    testRunName "Custom test run name"                  // Optional - default: build variant name
    deviceLanguageCode "en-US"                // Optional - locale <ISO 63>_<ISO 3166> default: en-US
    hookUrl "http://localhost:9080"           // Optional - call back URL after test run has finished
    scheduler "PARALLEL"                      // Optional - PARALLEL or SERIAL default: PARALLEL
    testScreenshotDir = "/sdcard/abc"         // Optional - custom screenshot folder
    // AppCrawler configuration - set application credentials
        applicationPassword = "appPassword2"
        applicationUserName = "appUsername2"
    // Optional - Custom settings for test execution
    fullRunConfig {
        instrumentationRunner =  ""
        withAnnotation = ""
        withOutAnnotation = ""
        limitationType = "CLASS"
        limitationValue = ""
        instrumentationAPKPath = "/tmp/mytestapp.apk" // Optional - custom instrumentation apk path
    // Optional
    uiAutomatorTestConfig {
        uiAutomatorTestClasses = "foo.class"
        uiAutomatorJarPath = "tmp/uitests.jar"

Enjoy This Awesome and Handy Plugin – Happy Testing!

Ville-Veikko Helppi

Mobile Testing Product Expert