Caring for your dependency garden: An approach to Android Dependency Management
Part 2: Replanting the annuals — Is it time to update that dependency?
Welcome, did you miss part 1? Check out why we need to be good gardeners and plant our dependencies in an orderly fashion. Some useful tips and tricks here in Part 1.
Depending on how you have organised your Android app dependencies and their versions (and whether you are using groovy or kotlin for your build scripts — more about different ways of organising your dependencies in part 1) you may not get the helpful warning from Android Studio that a dependency has a newer version available. You may not necessarily need the new version for the functionality of your app but it is useful to know about it and be able to check the release notes in case there are some bug fixes or new useful features.
There is a great plugin to help with this issue, Gradle Versions Plugin. This plugin will run through your dependencies and give you a list of which ones have newer milestone releases. It uses the Ivy resolution strategy to determine which types of revisions are available, by default a milestone or release revision.
To integrate this plugin it is as simple as adding the following your project level build.gradle file (where gradle_versions_version is the plugin version — 0.42.0 at time of writing):
And then running ./gradlew dependencyUpdate. This will produce a report listing all your dependencies that need updating and which version they can be updated to, no matter in which method you defined the dependency or the version. Handily as well, where possible a url to the dependency project is included which makes it easy to find the release notes and see what has changed. This report is also saved at build/dependencyUpdates/report.txt which can be changed to output to a CI server directory as needed.
An example of the output is as follows (truncated to save space):
If the revision method of determining updates is not granular enough for you, for example, you don’t want to be always upgrading to alpha revisions (looking at you Jetpack libraries) and only want to focus on full release you can add further logic to your script to filter out any type of version (this does rely on the dependencies following some version naming standard).
To do this, add the following to your root build.gradle:
This would filter out the alpha and RC versions from the above example output.
The full list of configuration and report type output can be found here.
CI Integration
You probably don’t want to run this plugin every time you build on your local machine or on your CI. Extra build steps take time (which adds up when you are working on a large app!) and if you have many dependencies you will frequently have to deal with the results which may involve migration work to any new major version (especially if you set up your CI to fail when there are items to update). It would be better to schedule this when it makes sense for your team, for example running weekly or monthly, less frequently would mean more work all at once.
There are also GitHub actions like Gradle Update Checker that can hook into these plugins to schedule the checks at a frequency that works for you outside of other CI systems and will integrate with Slack to let you know when a package needs to be updated so you can schedule in the work.
Another option is Dependabot which can even open PRs with the changes already made for you to review. A great article on Dependabot’s history, limitations and integration for Android can be found here.
Stay tuned for Part 3 next week and see how to make sure we prune the dependencies we don’t need and correctly including the ones we do.
