It’s a brave new world

After a long wait, Android Studio 3.0 has finally been released to the stable channel. This means everyone should be updating their IDE to the latest and greatest version. There are so many new features and improvements it is just a no brainer! I will go over the new features later on, but for now I will discuss the process of updating and cover the breaking changes in the new Gradle plugin.

How to update

Updating the IDE and plugin

Android Studio should have prompted you to update to 3.0, if not then go to ‘Check for updates’ in the menu to do so.

Once you launch your project in 3.0 for the first time, you will be told there is a new version of the plugin to update to. You can continue to use your project as it is, but you will miss out on many of the new features and improvements until you update. Simply, follow the prompts to have your project updated to version 3 of the Gradle plugin and to use the latest version of Gradle 4.

If for some reason you need to do this manually:

  1. Open gradle-wrapper.properties
  2. Enter the latest version of Gradle (above 4.1)
  3. Open build.gradle in the root of the project
  4. Ensure it contains the Google Maven repository and version 3 of the Gradle plugin. Note: there might be a version higher than 3.0.0 available, so use the latest one.
1
2
3
4
5
6
7
buildscript {
repositories {
google()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.0.0'
}}

Dependency configurations

Previously, when defining dependencies you would use compile.

compile 'com.android.support:support-compat:27.0.0'

This has now been deprecated in favour of implementation and api. In general, you can simply update all dependencies to use implementation. However, if your project is a library and it leaks one its module’s interfaces you may need to use api for that instead.

To understand the difference, please read this detailed guide.

Implementation vs API dependency
_Upgrading to Android studio 3.0 territory will make building multi-module projects a lot faster, but it also means a…_jeroenmols.com

Flavour dimensions

Variants are now automatically matched, which means an app’s debug variant will automatically use a library module debug variant. The same happens for product flavours as well, such as demo and trial.

To ensure this mechanism works correctly, it is now required that all product flavours are assigned to a particular flavour dimension. If you don’t need to use different dimensions, you can simply create one and assign all the flavours to it.

flavorDimensions "default"
productFlavors {  
  prod {  
    dimension "default"  
    ...  
  }
  dev {  
    dimension "default"  
    ...  
  }  
}

If you use a build type or flavour that doesn’t exist in one of your library modules, a fallback will need to be specified. This isn’t required for debug or release as they are present in all modules automatically. The plugin will select the first fallback from the list which is found.

debug { ... }  
release { ... }  
staging {  
  matchingFallbacks = ['debug', 'release']  
  ...  
}

3rd party plugins you no longer need

If you are still using the android-apt plugin for annotation processing support, you should remove that and use the built-in annotationProcessor. The third party plugin is no longer supported.

Similarly, many people have been using retrolambda for Java 8 features support. This is no longer required and will simply be provided automatically, so you should remove the retrolambda dependency.

Variant API changes

You may find that there are Gradle API changes that remove certain functionality. One area that has some differences is the variant API, which mean you will no longer be able to manipulate variant outputs. This is due to variant-specific tasks no longer being created at configuration time.

If you are using the following Gradle syntax, you should check it is still functioning correctly.

android.applicationVariants.all { variant ->  
  ...  
}

Firebase plugin Guava issue

There is a known issue with the Firebase plugin causing a Guava dependency mismatch. It can be easily fixed by excluding Guava from the Firebase plugin.

dependencies {  
  classpath ('com.google.firebase:firebase-plugins:1.1.0') {  
    exclude group: 'com.google.guava', module: 'guava-jdk5'  
  }  
  ...  
}

Robolectric resources issue

This won’t affect everyone, however, if you are using Robolectric you may find there is a problem with missing resources. To fix this simply add the following to the build.gradle for your module.

testOptions {  
  unitTests {  
    includeAndroidResources = true  
  }  
}

Find out more

There are many other smaller changes which will affect some projects. Full details, including other known issues and how to fix them can be found on the Android developers website.