Skip to main content

Android dependencies

Abstract

If you have your Android dependencies defined in your build.gradle file, the dedicated Android Steps on Bitrise can handle installing and even caching them.

The Gradle build system handles dependencies for Android apps. If you have your dependencies defined in your build.gradle file, the dedicated Android Steps on Bitrise can handle installing and even caching them.

Installing dependencies for Android apps

Building an Android app with Gradle dependencies is straighforward on Bitrise. When you first add the app, our project scanner determines that it's an Android app by locating the build.gradle file. Our official Android Steps can handle installing dependencies during the build process, and can build different modules and variants easily.

To make sure all your dependencies will be installed during the build:

  1. Define dependencies in your Android project.

  2. Use one of our Android Steps to build your app. The following Steps can install dependencies and build the app:

    • Android Build

    • Android Build for UI Testing

    • Gradle Runner

    Each of these Steps run a Gradle task the same way you would run it on your own device. They can build specific modules and install the relevant dependencies for those modules in the process.

Installing missing Android SDK components

Our build machines come with all the most commonly used Android tools pre-installed. However, if you need additional components of the Android SDK installed, we have a dedicated Step that handles the job for you.

This Step requires you to have the Gradle Wrapper in your project, as it looks for the `gradlew file. It runs the gradlew dependencies --stacktrace command to list and install the missing dependencies.

To install missing Android SDK components in a Bitrise build:

  1. Define the Android SDK components you need in the top level build.gradle file of your project.

  2. Make sure you have a gradlew file in your project's repository.

  3. On Bitrise, add the Install missing Android SDK components Step to your Workflow. It should be before any Step that requires Android SDK components.

  4. In the gradlew file path input, set the path to your gradlew file, relative to the root of the repository.

    install-sdk.png

  5. If you use the Native Development Kit in your project, set the required version in the NDK version input.

    If you don't use NDK, leave the input empty.

  6. In the Additional options for the gradlew dependencies command input, you can set flags in addition to the default command call.

Caching Gradle dependencies

There are two ways to cache Gradle dependencies in a build, depending on whether you use key-based caching or branch-based caching.

Key-based caching

Key-based caching is only available for credit-based accounts!

Key-based caching

Branch-based caching

With key-based caching, you only need the Restore Gradle cache and the Save Gradle cache Steps to cache your Gradle dependencies. These Steps require no configuration as they automatically set up the cache keys needed for your dependencies.

Setting specific cache paths

You don't have to use the default cache paths that the dedicated key-based caching Steps use. If you need to set a specific cache path, you can do so by configuring the Save Cache and the Restore Cache Steps: Using key-based caching in your builds.

  1. Add the Restore Gradle cache Step to your Workflow

    restore-gradle.png

    It should come before any Step that handles dependencies in any way, such as Android Build.

  2. Add the Save Gradle Cache Step to the end of your Workflow.

Branch-based caching relies on the built-in feature of all our Android Steps to collect cache content. The Android Build, Android Build for UI Testing, and the Gradle Runner Steps can all collect Gradle cache content.

Setting specific cache paths

You don't have to use the default cache paths that the built-in caching options use. If you need to set a specific cache path, you can do so in the Bitrise.io Cache:Pull and the Bitrise.io Cache:Push Steps: Including files and folders in the build cache.

  1. Add the Bitrise.io Cache:Pull Step to your Workflow.

    It should come before any Step that handles dependencies in any way, such as Android Build. The Step requires no extra configuration if you use our Android Steps.

  2. In the Options input group of the Android Build or the Android Build for UI Testing Step, set the Set the level of cache input either to deps_only or all.

    level-of-cache-android.png

  3. Add the Bitrise.io Cache:Push Step to the end of your Workflow.

    The Step requires no extra configuration if you use our Xcode Steps.

In this section:

An app on Bitrise represents a Git repository that stores source code and has been connected to Bitrise to be able to run builds on it. As such, a Bitrise app isn't necessarily an actual application: it's just the code on which you run builds with Bitrise.

A Step is a block of script execution that encapsulates a build task on Bitrise: the code to perform that task, the inputs and parameters you can define for the task, and the outputs the task generates.

The project scanner is a tool that identifies the given project’s type and generates a basic Bitrise configuration. Each supported project type has its own scanner: these scanners are stored as separate packages.

A Workflow is a collection of Steps, Environment Variables, and other configurations. When Bitrise starts a build, it runs one or more Workflows according to the configuration defined in the bitrise.yml file.