This is part 2 in a series about different caches available to Android Gradle projects. In part 1 we walked about the benefits provided by Gradle’s cache of incremental builds and the build cache directory. In the second half here, we talk about Android’s build cache, the Gradle daemon, and dependency caching
There are several ways Gradle stores information between builds to drastically reduce subsequent build times. You may be familiar with some of these methods, but what’s important is that they build upon each other gradually improving build speed. If you are only benefiting from one, then you have something to gain by also looking into the others.
I want to get this out quick without a lot of polish because something is better than nothing.
We use Spoon to aggregate our end-to-end tests and capture screenshots of our Android app. In order to save these screenshots, our app’s
AndroidManifest.xml needs to declare the
However this is the only reason that our app needs this permission. We don’t write to external storage any other time in the actual app. So my goal was to remove this permission from our app manifest and see if I could instead declare it our test
Over a year ago the support library development team decided to split the monolithic
support-v4 library up into several sub-libraries. This update, in version 24.2.0, meant that an app no longer needed to depend on the entire
support-v4 library and could instead depend on only those sub libraries that it needed.
Until now I have yet to implement this update on any of my work or personal projects. This week as part of a general dependency audit, we decided to split up our