The Android SDK Plugin for SBT enables you to maintain a cache configuration for your app's dependencies. This configuration instructs the sbt plugin to bundle the specified libraries, optimize them via ProGuard and keep them around for future ProGuard executions.
Defining many cache rules will result in a higher cache-miss rate, but will dramatically speed up builds on cache-hits; choose libraries and caching rules carefully to balance the the cache-hit ratio. Large, multi-megabyte libraries should always be cached to avoid hitting the dex-file method-limit.
The bigger your cache, the higher the chance that a code change in your project now calls a method that has previously been removed by ProGuard and is therefore not included in the cache. That is a so called cache miss. If a change has no impact on the cached API you are calling, we can reuse the already optimized dependencies and improve build times dramatically; a cache hit!
The ProGuard cache is configured in the sbt build file via the
proguardCache in Android key. Directives added to the configuration simply contain the package identifiers that you want to add to the cache.
proguardCache in Android ++= // Cache everything in the android.support package "android.support" :: // Cache all play modules "play" :: Nil
You need to make sure to reference the actual package name (that you use with the
import statement), and not the dependency group id. The play-json module for instance is included via sbt as
"com.typesafe.play" %% "play-json" % "2.3.10", but the actual root package identifier is simply
Once in a while the mechanism that detects cache misses or hits does not work as expected. It is then usually sufficient to run
sbt clean to force an entire rebuild of the project.
The Android SDK Plugin for SBT does unfortunately not give you feedback on how your cache directives are working. For instance, if you make a mistake in one of your rules, there will be no error message. To validate your cache manually you may have a look into the
./target/streams/android/proguardInputs/$global/streams/proguard_cache/proguard-cache-xxx.jar file which does at least give you an idea of what is going on.