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

Created by: kageiit

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