Gradle タスクとは何で、どうすれば自分のプロジェクトで利用可能なタスクの一覧を取得できますか?

gradle タスクとは、あなたが gradle で実行することのできる処理のことです。 コマンドラインやターミナルで gradle 実行するタスク を実行することでこれらのタスクを実行することができます。

標準的な Android の Gradle プロジェクトにはデフォルトでたくさんのタスクが含まれています。たとえば:

Android アプリのディレクトリで gradle tasks を実行することで基本タスクの一覧を取得することができ、 gradle tasks --all を呼び出すことで全ての利用可能なタスクを確認することができます。

gradle tasks を実行すると、利用可能な Gradle タスクの一覧を次のようなフォーマットで取得できます:

$ gradle task


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.

Script ステップで gradle 実行するタスク名 (例: gradle assemble) を呼び出すか、 Gradle Runner ステップ ( で gradle_task 入力値としてタスクを指定することで任意のタスクを bitrise 上で実行することができます。

**gradle** を直接実行する代わりに、 **gradlew** (Gradle ラッパー) を使用するべきです! Gradle Runner ステップはこれを行い、ステップの関連する入力説明でそれを見ることができます:

Using a Gradle Wrapper (gradlew) is strongly suggested, as the wrapper is what makes sure that the right Gradle version is installed and used for the build.

You can find more information about the Gradle Wrapper (gradlew), and about how you can generate one (if you would not have one already) in the official guide at:

How to install an additional Android SDK package

The preferred way to do this is to use the **Install missing Android tools**** step. Please only use a Script solution if you really have to, as you’ll have to update the Script if the Android tools change (which did happen).**

All you have to do is to add a Script step to your workflow, and use the Android sdkmanager tool to install the additional packages you want to.

As an example, to install the Android SDK v18 and the related build-tools v18.0.1, you can add a Script step (can be the very first step in the Workflow) with the following content:

# 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 get the full list of available packages by running: sdkmanager --list --include_obsolete --verbose. You can run this 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 ....

Enable Gradle debug options

If your Gradle build fails and you can’t find any information in the logs you can try to call it with --stacktrace --debug flags (ex: 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.

Run 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, 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.

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.


You can find and use our Android emulator steps to create & boot emulators:

First you have to create an emulator with a Create Android emulator step, where you can set the Android version and a couple of other parameters for the new emulator, then you can boot this emulator with the Start Android emulator step, which makes sure that the emulator is booted and ready for subsequent steps.

Emulator with Google APIs

Instead of using a Script step to create an android emulator please use the **Create Android emulator**** step! There are simply too many edge cases to cover here, as well as the commands and working configurations change quite frequently.**

The section below is kept here for referencing purposes, and might be outdated.

Note about Android SDK versions: at this time there are lots of known issues reported for Android Emulators with Android SDK version 22 & 23 when combined with Google Play services (see 1 and 2). The script above creates an emulator with SDK version 21, which should work properly with Google Play services.

There are possible workarounds for newer versions (see __1_ _and 2), but that requires some customization in your project.

Installing / Using Java version X

Java 8 is now pre-installed

Java 8 is now the pre-installed Java version on the Linux Stack. This section is kept here for future reference, in case you’d need another Java version.

If you’d need a Java / JDK version which is not preinstalled on the Android stacks, you can follow this guide to install it. This example will install Java/JDK 8, please adapt it to the version you need.

If your build requires JDK 8, you can install and activate it with a Script step:

set -ex

add-apt-repository -y ppa:openjdk-r/ppa
apt-get update -qq
apt-get install -y openjdk-8-jdk
update-java-alternatives -s /usr/lib/jvm/java-1.8.0-openjdk-amd64
echo "done"

That’s all, just add the Script step to the Workflow with the content above, and start a new build. This _Script__ step can be the very first step in the Workflow, as it does not depend on anything else._