Too many field references in Uber R.java jar to fit in a single dex

In 4cf0eb7a744c9583cc3f45f7952ef3aa6ae8afae , 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

public static class color {
    public static final int common_google_signin_btn_text_dark=0x7f0700b0;
}

referenced in an app and aarX and aarY (both depended on by app) depend on gms, the Uber R.java jar will contain both com.aarX.R.color.common_google_signin_btn_text_dark and com.aarY.R.color.common_google_signin_btn_text_dark even if the app only refers to com.aarX.R.color.common_google_signin_btn_text_dark in its code.

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.

com.facebook.buck.step.StepFailedException: Failed on step dx_&&_write_file with an exception:
field ID not in [0, 0xffff]: 65536
com.android.dex.DexIndexOverflowException: field ID not in [0, 0xffff]: 65536

trim_resource_ids does not help much because the field reference count in the custom dx packaged with buck only looks at field names and not the fully qualified name of field references for simplicity.

Had a long conversation regarding this with @dreiss yesterday. I seem to see two possible solutions to this

• Make the referenced resource calculation in dx more fine grained by including the package name + resource name instead of just the resource name
• Provide an option to list a primary_dex_resource_patterns and split the Uber R.java jar into multiple jars if linear_alloc_splt_dex is enabled so resources needed in the primary dex can still be kept like today.

If there are any other workarounds or other solutions, would love to know so we can try the best alternative

[zongwu233]

I solve this problem in this way: split Uber R.java into two parts ,one is the ${packagename}.R.java and the rest R.java. ${packagename}.R.java as UberRDotJava is trimed, compiled and dexed as before, and the rest R.java is compiled, dexed and add into preDexedLibraries . then primer dex’s fields is much less than before .

[ChaitanyaPramod]

Hi, some us continue to see a similar issue over at #926 which appears to be strongly related to this issue. Can we get some help with #926?