{"id":553,"date":"2018-10-22T20:29:47","date_gmt":"2018-10-23T01:29:47","guid":{"rendered":"http:\/\/jebware.com\/blog\/?p=553"},"modified":"2020-06-05T11:10:22","modified_gmt":"2020-06-05T16:10:22","slug":"yes-you-should-run-proguard-r8-on-open-source-libraries","status":"publish","type":"post","link":"https:\/\/jebware.com\/blog\/?p=553","title":{"rendered":"Yes, you should run ProGuard \/ R8 on open-source library dependencies"},"content":{"rendered":"

I have seen a few people argue that there\u2019s no reason to let ProGuard run on the open-source libraries that they include in their app, because if the source is publicly available, there\u2019s no point of obfuscating, right? Who are you fooling? Here’s an example from one library’s README file:<\/span><\/p>\n

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

Their ProGuard rules file is just a big wildcard keep:<\/p>\n

\"\"<\/a>
\nI think that\u2019s exactly wrong, for two reasons — shrinking, and obfuscation.<\/span><\/p>\n

Shrinking<\/span><\/h1>\n

The majority of the shrinking that ProGuard performs is by removing unused code from third-party libraries. You\u2019re not writing a lot of code that you don\u2019t use, but you\u2019re probably not using all of the features in the third-party libraries that you include. If you use a<\/span><\/p>\n

-keep com.example.** { *; }<\/span><\/pre>\n
-type rule on open source libraries, you won\u2019t get the benefits from ProGuard\u2019s shrinking. None of that unused code will be removed.<\/span><\/p>\n
Obfuscation<\/span><\/h1>\n
I\u2019m going to show this with an illustration. What does this class do?<\/span>
\n