In bug 1285511, we implemented a quick fix for exceeding the method limit since these builds are only run in automation. Before we run with gradle for our production builds, we should re-evaluate this decision and its trade-offs.

fwiw, I believe multidex can cause performance issues so we want to fix this if we also ever use gradle for performance-oriented tests.

Note that I don't intend to optimize the multidex solution for local builds (as per [1]) in bug 1285511. [1]: https://developer.android.com/studio/build/multidex.html#dev-build

(In reply to Michael Comella (:mcomella) from comment #2) > Note that I don't intend to optimize the multidex solution for local builds > (as per [1]) in bug 1285511. It looks like Nick may have already done this, but it'd be worth double-checking his solution.

I've compiled some data from TreeHereder to see how close are we to the 64K limit and a glimpse to the trend, seems like we'll run into that limit at any time. link: https://docs.google.com/spreadsheets/d/1Gzn89BGXkgikcihODEy1XUWzEYf8CGU2gi7-S-zJNuo/edit?usp=sharing excerpt: Method Field 2017.06.01 60704 35864 2017.05.15 48491 27332 2017.05.01 48255 27254 2017.04.22 54632 28050 2017.04.16 54655 28066 2017.04.01 54615 28043 2017.03.15 54415 27938 2017.03.01 54147 27857 Another big code landing would probably make us exceed the limit, given that we could have as much as 12,000 more methods in just half a month. I'll take a look at what I can do to help.

Will need to unassign myself because of shifting to some other items.