Gradle Runner vs Android Build ⚓
We’d like to shed light on the major differences between our two Android build steps: Gradle Runner
and Android Build
Steps. They are both build steps but they are slightly different in their functions. Let’s jump right in!
Our Gradle Runner
Step is the headquarter for all your gradle tasks
. It runs a single or multiple Gradle task(s) you specify and then copies the generated APK(s) into the Bitrise Deploy Directory ($BITRISE_DEPLOY_DIR
). This step runs ANY Gradle task (not just building task) that is available in your project’s task list. You can run multiple tasks at the same time if you insert the tasks separated with spaces in the Gradle task to run
input field of the Step.
For example: assembleDebug
assembleDebugAndroidTest
where Gradle Runner step will output as many APK paths as many assemble tasks you have set.
Our Android Build
Step is different from Gradle Runner
in the sense that it provides a simplified user experience of Android Studio’s developing functions: it reflects how you would configure your project in Android Studio. This step is geared towards ONLY building your project, therefore, it cannot perform any othergradle task
(as opposed to Gradle Runner
). As a result, you can use assemble
- related task with this Step.
About Gradle tasks ⚓
Gradle tasks are an integral part of Gradle build script. You can use any task that is defined in gradle build files where tasks are either specified by you or available by default based on your project. You can run these available tasks with the gradlew TASK-TO-RUN
command in your Command Line / Terminal.
Here is a list of the most common default tasks of an Android Gradle project:
androidDependencies
- displays the Android dependencies of the project.assemble
- assembles all variants of all applications and secondary packages.assembleAndroidTest
- assembles all the Test applications.clean
- deletes the build directory.
Getting the list of available Gradlew tasks in your project ⚓
To get the basic task list, call gradlew tasks
in your Android app’s directory. When running gradlew tasks
, you’ll get a list of available and most frequently used gradle tasks
in this format:
$ ./gradlew tasks
:tasks
------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------
Android tasks
-------------
androidDependencies - Displays the Android dependencies of the project.
signingReport - Displays the signing info for each variant.
sourceSets - Prints out all the source sets defined in this project.
Build tasks
-----------
assemble - Assembles all variants of all applications and secondary packages.
assembleAndroidTest - Assembles all the Test applications.
assembleDebug - Assembles all Debug builds.
assembleRelease - Assembles all Release builds.
...
To see all the available tasks listed in your task list, call ./gradlew tasks --all
.
Running Gradle task with our Steps ⚓
You can run gradle tasks
on Bitrise using Do anything with our Script
Step, Gradle Runner
and Android Build
Steps.
Do anything with Script step ⚓
- Insert the Step anywhere in your workflow.
- Run any task by calling
./gradlew task-name-to-run
in the Script input field (for example:./gradlew assemble
). - Make sure the right executor type is selected to run your script in the
Execution with / runner binary
input field of theConfig
section.
Gradle Runner Step ⚓
As a minimum input, make sure you fill out the following two input fields:
- Specify the task that is available in your task list as the value of the
Gradle task to run
step input. - If you use our scanner to upload your project to bitrise.io, the
gradlew file path
input field gets automatically filled out with the respective path in the Step. Otherwise make sure you fill it out manually and make sure to add a relative path to the repository root, for example:./gradlew
or./sub/dir/gradlew
(if it is a subdirectory).
Android Build Step ⚓
This Step can only perform building-related gradle tasks
. If you wish to run other type of gradle tasks
, please use our Gradle Runner
Step.
- Add the Step after the testing steps but before the code signing Step in your deploy workflow.
- Set the required
Project Location
input field to reflect the root directory of your project.
How to install an additional Android SDK package ⚓
You can update your Android SDK package or install missing dependencies either using our Install missing Android SDK components
Step or Do anything with Script step
where installing the respective package requires a little manual coding.
Automatic installation of Android SDKs and dependencies ⚓
We suggest using our Install missing Android SDK components
Step to install dependencies and missing Android SDK components for your Android project:
-
Provide the required NDK version in the
NDK Revision
input field. Leave this input empty if you are not using NDK in your project.
The Step runs the gradlew dependencies
command and prints out a list of dependencies and SDK components that are relevant to your project. Then the Step takes care of installing them.
Manual installation of Android SDKs ⚓
As an alternative to the Install missing Android SDK components
Step you can manually install the missing Android SDKs as well.
Before you start:
- Make sure you have the Android
sdkmanager
installed to your local computer. For more information onsdkmanager
, check out this guide.
- Add
Do anything with Script step
(can be the very first step) to your workflow. -
Add the required platform and build-tools version to the
Script content
. In this example, we’re installing the Android SDK v18 and the relatedbuild-tools
with v18.0.1.#!/bin/bash #fail if any commands fails set -e #debug log_ set -x #write your script here sdkmanager "platforms;android-18" sdkmanager "build-tools;18.0.1"
You can check the full list of available packages (including obsolete packages) that you have already installed by running an sdk
task:
- Run
sdkmanager --list --include_obsolete --verbose
command. You can run this command on your own machine if you have$ANDROID_HOME/tools/bin
in your$PATH
. If not, then you can run it with/PATH/TO/ANDROID-SDK-HOME/tools/bin/sdkmanager ...
.
Enabling Gradle debug options ⚓
If your Gradle build fails, we recommend you to first check your build’s log in the APPS & ARTIFACTS
tab.
If you’re still lost, you can call --stacktrace --debug
flags (for example, gradle ... --stacktrace --debug
) to get more detailed logs.
In most cases --stacktrace
should be enough, and the Gradle Runner
Step includes this flag by default.
Running a bitrise Android build on your Mac/PC with Docker ⚓
You can run your build on your Mac/PC inside the same docker
container you use on bitrise.io to fully test your build in an identical environment! You can find the detailed guide here: How to run your build locally in Docker
Heap size ⚓
There are several options to adjust the heap size for the Java Virtual Machine (JVM). One option is adding Environment Variables (Env Vars) to your workflow where you specify the -Xms
and -Xmx
parameters. These determine heap size: the -Xms
parameter sets the initial Java heap size and the -Xmx
parameter sets the maximum Java heap size.
For example, you can use the GRADLE_OPTS
and JAVA_OPTS
Env Vars by setting them in the Env Vars tab.
GRADLE_OPTS: '-Dorg.gradle.jvmargs="-Xmx2048m -XX:+HeapDumpOnOutOfMemoryError"'
JAVA_OPTS: "-Xms512m -Xmx1024m"
You can use use both, only one of them or neither if your project’s default configuration meets your heap capacity needs. Please note that these Env Vars with the -Xms
and -Xmx
parameters might get overridden based on your configuration.
Emulators ⚓
You can use our Android emulator Steps such as AVD Manager
and Wait for Emulator
to create and boot Android emulators. Let’s see how!
- Add
AVD manager
Step to your workflow. It can be one of the first steps in your workflow. -
Set the following required input fields in the step:
Device Profile
,Android API level
, andOS Tag
.The Emulator needs some time to boot up. The earlier you place the Step in your workflow, the more tasks (cloning or caching) you can complete in your workflow before the emulator starts working.
-
Add the
Wait for Emulator
Step to your workflow. This step acts a shield preventing theAVD Manager
to kick in. Make sure you add it BEFORE the step with which you want to use theAVD Manager
. In our example, we are usingWait for Android emulator
Step to only start the Android Virtual Device FROM theGradle Runner - UI test
Step onwards.