On the other hand, your IdlingResource needs access to some intimate pieces of that library that ProGuard wants to throw away.On the one hand, you want to ProGuard away all of what’s not needed off of this (bloated?) library.It seems to work well, but in your instrumentation tests - you want to provide an IdlingResource that can intimately interrogate what the library is up to (namely, whether busy or idle). So far, so good! The custom test-rules config schemeĬonsider this common scenario: your app uses a 3rd-party library that does some background processing for you. So if your app wants to -keep class A, and you have a library that wants to -keep class L - you guessed it: ProGuard will merge all rules so as to have both classes A and L kept in the final apk. Namely:ĬonsumerProguardFiles is a library-scoped configuration, that tells Gradle the library has its own ProGuard rules to consider if integrated into an app that itself, uses ProGuard. Note: You can specify as many files as you like in this csv list, and even repeat proguardFiles multiple times.īe advised, however, that at this point, Gradle+ProGuard also consider your dependent libraries’ ProGuard files - should they have been declared using consumerProguardFiles in the library itself.
#PROGUARD ANDROID STUDIO TUTORIAL APK#
ProguardFiles (in the statement above) mainly tells Gradle to consider your custom rules (in the proguard-files.pro file) along with some standard android ones (hence the getDefaultProfileFile()), when running ProGuard prior to generating the app apk (i.e. Let’s just try, then, to unravel what goes on beneath the covers. In essence, in terms of build-scripts, indeed only the proguardFiles configuration is needed here, and nothing more. I’ll be doing it in a learn-by-example way, thus shedding light on the various configuration options and addressing the pitfalls, as I go along. I’ll be offering 3 configuration schemes I believe can cover what most Android projects, which incorporate instrumentation testing, require. To what extent do the rules apply, in each case? Pretty confusing! ? declared using implementation), or test-only dependencies (using androidTestImplementation). Library level (Gradle’s consumerProguardFiles configuration) Libraries can be used as either production dependencies (i.e.Test level (Gradle’s testProguardFiles configuration).App level (Gradle’s proguardFiles configuration).In addition, there are many levels where ProGuard rules can by applied:
#PROGUARD ANDROID STUDIO TUTORIAL CODE#
It can therefore carelessly omit production code required by the test suite during the minification phase, possibly causing tests to fail for the wrong reasons. ProGuard will not retain production code if only used by instrumentation-testing code. First and foremost, it’s due to this one pitfall: Having proper UI tests in your project brings ProGuard configuration complexity even higher, for several reasons.