This is part 3 in a series about different caches available to Android Gradle projects. In part 1 I wrote about the benefits provided by Gradle’s cache of incremental builds and the build cache directory. In part 2 I wrote about Android’s build cache, the Gradle daemon, and dependency caching. Here in part 3, I write about the deprecation and remove of Android’s build cache, and introduce Gradle’s configuration cache. Continue reading “Understanding Different Gradle Caches for Android Projects, part 3”
Tag: coding
Promoting Adaptability Over Estimation
I recently read Jacob Kaplan-Moss’ article Software Estimation Is Hard. Do It Anyway. His argument is that although estimation is hard, there are benefits to getting better at it and being able to provide accurate estimates. I disagree with his argument and propose a more helpful mindset.
Android Mapbox SDK: Hiding Labels As User Zooms Out
I’m using Mapbox Android SDK in a side project to show bike paths and points of interest (POI). The POIs are indicated with a marker icon and a text label. I only want to show the labels at certain zoom levels. Mapbox provides some label collision options but none of them work like I want. Here’s how I got this working.
Continue reading “Android Mapbox SDK: Hiding Labels As User Zooms Out”
R.I.P. Device Farm
I’ve been an Android developer at three different companies in my career. At each company I tried to set up a device farm and run instrumentation tests on that farm. After three attempts, I’m finally giving up.
Be Careful With Your Gradle Repository Declarations
Gradle has a sophisticated process for downloading, caching, and managing third-party dependencies. However Gradle first needs to find where these dependencies are hosted. It will try to resolve each dependency by checking repositories one-at-a-time in the order they are listed in build.gradle files. Out of the box, a new Android Studio project will add two Gradle repositories to the project:
allprojects {
repositories {
google()
jcenter()
}
}
For each dependency, Gradle will first check Google’s repository for a matching dependency. If a match is found, it will then move on to the next dependency. If not, Gradle will then check JCenter’s repository. This linear search is very inefficient and creates potential security issues during the build process.
The security flaws are well documented in other stories. Simply put, if a malicious person puts a compromised “fake” artifact on a repository that is listed before a repository containing the “real” artifact, then Gradle will use that fake artifact; this situation can be hard to detect if you’re not explicitly looking for it.
I want to focus on the second issue: the inefficiencies caused by Gradle checking repositories that do not have the requested artifact.
Continue reading “Be Careful With Your Gradle Repository Declarations”