Open Bug 1286677 Opened 4 years ago Updated 1 year ago
Re-evaluate multidex method limit solution before using gradle for production builds
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 ) in bug 1285511. : https://developer.android.com/studio/build/multidex.html#dev-build
Summary: Re-evaluate method limit solution before using gradle for production builds → Re-evaluate multidex method limit solution before using gradle for production builds
(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 ) 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.
Assignee: nobody → osimpleo
Will need to unassign myself because of shifting to some other items.
Assignee: osimpleo → nobody
You need to log in before you can comment on or make changes to this bug.