Android builds will soon require to be run on JDK 17. At the moment, the minimum required Java version is JDK 11, but this is soon changing with the release of Android Studio Flamingo (2022.2.1) and Android Gradle Plugin version 8.0.
Once you upgrade a project to Android Gradle Plugin 8.0, Gradle builds need to be run on JDK 17.
This means that in CI environments, you need to pay attention to the preinstalled JDK version and the value of
$JAVA_HOME. On Bitrise macOS and Linux stacks, both JDK 11 and JDK 17 are preinstalled, and even though JDK 11 is the current default, a workflow can switch to JDK17 without long install times with the Set Java version Step.
Once the project is upgraded to Android Gradle Plugin 8.0, Bitrise workflows need to activate JDK 17 before any Gradle or Android build Steps:
workflows: - build: steps: - set-java-version@1: inputs: - set_java_version: 17 - android-build@1: inputs: - variant: debug - module: app
Is the default JDK install changing on Bitrise stacks?
No, JDK 11 remains the default for now. Earlier versions of Gradle and the Android Gradle Plugin do support JDK 17, but a project might contain incompatible Gradle plugins or custom tooling that would break with the change.
Will JDK 17 become the default on Bitrise stacks?
JDK 17 will become the default eventually on Bitrise stacks, once most projects are migrated to JDK 17.
We will announce this change and give time for migration.
What is the best way to handle JDK versions in Bitrise workflows?
We recommend using the Set Java version Step in every workflow that runs Gradle builds.
Does this affect my app’s target JDK level?
No, this only affects what JDK version Gradle, the build tool is using for build tasks.
Your app’s Java language level is controlled by the
compileOptions.targetCompatibility build config (learn more).
Does this also affect local builds?
Yes, but Android Studio ships with a bundled JDK. Starting with Android Studio Flamingo, this bundled JDK is upgraded to version 17.