{"id":434,"date":"2017-11-27T20:52:06","date_gmt":"2017-11-28T01:52:06","guid":{"rendered":"http:\/\/jebware.com\/blog\/?p=434"},"modified":"2020-06-05T11:11:31","modified_gmt":"2020-06-05T16:11:31","slug":"proguard-pro-tip-dont-use-proguards-include-with-gradle-builds","status":"publish","type":"post","link":"https:\/\/jebware.com\/blog\/?p=434","title":{"rendered":"ProGuard pro-tip: Don’t use ProGuard\u2019s \u201c-include\u201d with Gradle builds"},"content":{"rendered":"

I like to organize my ProGuard rules by breaking them up into separate files, grouped by what they’re acting on — my data model, third-party libs, etc.<\/span><\/p>\n

\"\"<\/a><\/p>\n

It’s tempting to reference one main ProGuard file from your build.gradle, and then put ‘-include\u2019 entries in the main file to point to the rest, but there’s a problem with this. If you make a change in one of the included files, it won’t be picked up until you do a clean build.<\/span><\/p>\n

The reason for this is Gradle\u2019s model of inputs and outputs for tasks.  Gradle is really smart about avoiding unnecessary work, so if none of the inputs for a task have changed, then Gradle won’t rerun the task.  If you list one main ProGuard file in your build.gradle and include the rest from there, Gradle only sees the main file as an input.  So if you make changes in an included file, Gradle doesn’t think anything changed.<\/span><\/p>\n

The easy way I’ve found to work around this is to put all of my ProGuard rules into a directory, and include them all in your build.gradle with this snippet:<\/span><\/p>\n