Exceeding the 64k method limit

[hypest]

The feature/gravatar-upload-okhttp branch (at 30fa971) manages to exceed the 64k method limit.

We need to decrease the app's current method count.

[maxme]

In current develop ede6a91, overall method count: 63910 (debug) / 63889 (release)- so that's definitely a problem we have to solve asap.

[maxme]

Most significant numbers:

android support 20573 + google libs: 6099
wpandroid itself + subprojects (editor, stats, etc.): 11877
kotlin runtime: 6603
helpshift: 4071
simperium: 955 + koushikdutta (async android): 2794
apache commons: 2396
crashlytics: 1013 + fabric: 1188
mixpanel: 1716

[maxme]

Adding proguard shrink mode helps to kill ~25K methods, but it adds ~15 seconds compile time. After proguard:

Overall method count: 38472

android support 12628 + google libs: 3043
wpandroid itself + subprojects (editor, stats, etc.): 11030
kotlin runtime: 139
helpshift: 3293
simperium: 762 + koushikdutta (async android): 1341
apache commons: 102
crashlytics: 699 + fabric: 797
mixpanel: 1273

Conclusions:

• WPandroid count before / after is almost the same (no room for improvement here),
• Stripping android support and google libs is the major win (13K).
• Helpshift count seems huge even after shrinking.
• We're using very few Kotlin runtime and Apache commons methods.
• We don't want to add 15 secs to each debug build 😢

I'll try to enable the new build tool chain (Jack and Jill) for debug builds, from the doc:

JACK has shrinking and obfuscation support and uses proguard configuration files to enable shrinking and obfuscation features.

Plus, it should make the whole build step faster.

[hypest]

Will close this since we got some headway by #3927

[hypest]

Reopening so to keep an eye on it.

[sendhil]

Man... Helpshift sure has a lot of methods ;).