IssueTracker

There are reports that the latest version of the Gradle plugin does not shrink as much as it could (or in particular, as much as earlier versions of the plugin did -- 0.14.0-0.14.2.)

This issue will try to track down the various causes for this.

I suspect the *main* reason this happens is that the resource shrinker tries to err on the side of caution: If it is not *sure* if a resource is unused, it will keep it. The rationale for this is that it's better to have an unused resource than to have a runtime crash when a removed resource that turns out to be used after all cannot be found.

If the app does not look up resources by name (e.g. by calling Resources#getIdentifier(String)), then resource usage should be fairly accurate and most eligible resources should be removed.

However, if that method is called (and if you use appcompat, that method uses it, so your app is considered to b using it), then that means that your code could be constructing resource names dynamically, and looking those up. Therefore, the resource shrinker in that case will look at all the strings in your app (including those from your libraries), and try to figure out whether these are used to construct resource names.

For example, if it sees the string "cursor_%d", it guesses that this might be used to look up the resource icons cursor1.png, cursor2.png, cursor3.png via code like Resources.getIdentifier(String.format("cursor_%d", count) - so all resources that String#format match "cursor_%d" are kept. Similarly, you might be doing "cursor_" + count, so anything which starts with that string is kept as well.

(In 0.14.2 the mere presence of "%s" would be used by this code to mask absolutely everything; that has now been fixed.)

How do you know if this is what's happening to your app?

First build with the --debug flag such that the resource shrinking generates status information. This is going to dump out a lot of information (from all tasks) so you should dump it into a file:

$ ./gradlew --debug clean assembleRelease > /tmp/build-output.txt

Now let's see if the app contained a dynamic resource lookup:

 $ grep Resources#getIdentifier /tmp/build-output.txt
07:48:48.285 [QUIET] [system.out] android.content.res.Resources#getIdentifier present: true

Yes it did! If you open the build output file and look for "Referenced Strings:" you can see all the constants found in the app that it uses to look for possible matches (there are different heuristics applied; some for the file:///android_res syntax, some for the #getIdentifier call, etc.

This shows which drawable resources were kept because their names matched a string pool constant that the resource shrinker worried could be used to dynamically look up the resource:

$ cat /tmp/build-output.txt | grep "Marking drawable:"
13:15:34.543 [QUIET] [system.out] Marking drawable:powered_by_google_dark:2130837586 used because its prefix matches string pool constant power
13:15:34.543 [QUIET] [system.out] Marking drawable:powered_by_google_light:2130837587 used because its prefix matches string pool constant power

So the code included the string "power" somewhere, and this caused these two icons to be kept.

SOLUTIONS:
So what can we do about this? One possibility is for us to add a flag or option of some sort where Lint does *not* attempt to figure out possible uses, and simply force the user to *explicitly* keep all dynamically referenced resources. This is similar to how ProGuard already works; it doesn't try very hard to figure out reflective uses of calls, so you have to explicitly keep those via a proguard.pro file. We have the ability to keep resources via tools:keep attributes now, so for users who want to aggressively filter out everything and then explicitly keep missing resources, we could that as an option.

OTHER CAUSES:
If your resources are *not* kept because of a String pool constant, look at the debug output and grep for the "reachable" attribute; e.g. something like this:

$ cat /tmp/build-output.txt  | grep reachable= | awk '{print $4 $5 $6}' | grep drawable | sort
@drawable/abc_textfield_search_material:reachable=true
@drawable/common_full_open_on_phone:reachable=false
@drawable/common_ic_googleplayservices:reachable=false
@drawable/common_signin_btn_icon_dark:reachable=false

Make sure that your resource which you expected to be unused is not actually marked as reachable. If it is, you can try looking for it; the reference graph is also printed. For example, for the top reference above, we have

$ cat /tmp/build-output.txt | grep abc_textfield_search_material | grep '=>'
07:48:48.636 [QUIET] [system.out] drawable:abc_textfield_search_material:2130837554 => [drawable:abc_textfield_search_activated_mtrl_alpha:2130837552, drawable:abc_textfield_search_default_mtrl_alpha:2130837553]
07:48:48.648 [QUIET] [system.out] style:Base_Widget_AppCompat_SearchView:2131492957 => [layout:abc_search_view:2130903061, drawable:abc_textfield_search_material:2130837554, drawable:abc_ic_clear_mtrl_alpha:2130837519, drawable:abc_ic_search_api_mtrl_alpha:2130837528, drawable:abc_ic_go_search_api_mtrl_alpha:2130837521, drawable:abc_ic_voice_search_api_mtrl_alpha:2130837529, drawable:abc_ic_commit_search_api_mtrl_alpha:2130837520, layout:abc_search_dropdown_item_icons_2line:2130903060]
07:48:50.392 [DEBUG] [org.gradle.api.Project] => res/drawable/abc_textfield_search_material.xml
07:49:01.585 [QUIET] [system.out] drawable:abc_textfield_search_material:2130837554 => [drawable:abc_textfield_search_activated_mtrl_alpha:2130837552, drawable:abc_textfield_search_default_mtrl_alpha:2130837553]
07:49:01.596 [QUIET] [system.out] style:Base_Widget_AppCompat_SearchView:2131492957 => [layout:abc_search_view:2130903061, drawable:abc_textfield_search_material:2130837554, drawable:abc_ic_clear_mtrl_alpha:2130837519, drawable:abc_ic_search_api_mtrl_alpha:2130837528, drawable:abc_ic_go_search_api_mtrl_alpha:2130837521, drawable:abc_ic_voice_search_api_mtrl_alpha:2130837529, drawable:abc_ic_commit_search_api_mtrl_alpha:2130837520, layout:abc_search_dropdown_item_icons_2line:2130903060]
07:49:03.477 [DEBUG] [org.gradle.api.Project] => res/drawable/abc_textfield_search_material.xml

If you don't see an actual resource reference to your file, that means it must be referenced from the code instead.