Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Too many field references in Uber R.java jar to fit in a single dex #828
In 4cf0eb7 , the list of fields to be included in R.java was changed from computing from the resource xml references and just using the R.txt from prebuilt aars instead. This means whatever is in R.txt gets treated as if it was declared in the package that is in the aar's manifest.
This becomes a problem in large apps that consume many prebuilt aars. If these aars depend on libraries like the android support library, gms etc, the field references of used resources coming from such dependencies will be counted against each prebuilt aar.
For example, if gms had a color resource
referenced in an app and aarX and aarY (both depended on by app) depend on gms, the Uber R.java jar will contain both
This leads to a situation where all the R.java files cannot fit in a single jar to be dexed/predex because the number of filed references is > 65535.
Had a long conversation regarding this with @dreiss yesterday. I seem to see two possible solutions to this
If there are any other workarounds or other solutions, would love to know so we can try the best alternative
referenced this issue
Aug 3, 2016
I opened a PR for the fully-qualified name approach. Ran a clean build on our codebase
I also profiled the two most expensive dx steps from our build trace
With fully qualified names:
I think the overall performance impact during build is not significant using this approach.
It is probably because we do some extra work for supporting robolectric tests in the MergeResourcesStep. I will profile the time taken to compute the referenced fields by getting the time in Millis before and after the computation for the change to see the impact more isolated
I got the time before and after https://github.com/facebook/buck/blob/master/src/com/facebook/buck/android/TrimUberRDotJava.java#L119
and here are the results
I think it is because the time gained back by not writing back more entries to the file is more than the time lost comparing with the FQ names
@kageiit I encountered this problem too.
I solve this problem in this way: