{"action":"created","issue":{"url":"https://api.github.com/repos/facebook/buck/issues/828","repository_url":"https://api.github.com/repos/facebook/buck","labels_url":"https://api.github.com/repos/facebook/buck/issues/828/labels{/name}","comments_url":"https://api.github.com/repos/facebook/buck/issues/828/comments","events_url":"https://api.github.com/repos/facebook/buck/issues/828/events","html_url":"https://github.com/facebook/buck/issues/828","id":169198338,"number":828,"title":"Too many field references in Uber R.java jar to fit in a single dex","user":{"login":"kageiit","id":291148,"avatar_url":"https://avatars.githubusercontent.com/u/291148?v=3","gravatar_id":"","url":"https://api.github.com/users/kageiit","html_url":"https://github.com/kageiit","followers_url":"https://api.github.com/users/kageiit/followers","following_url":"https://api.github.com/users/kageiit/following{/other_user}","gists_url":"https://api.github.com/users/kageiit/gists{/gist_id}","starred_url":"https://api.github.com/users/kageiit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kageiit/subscriptions","organizations_url":"https://api.github.com/users/kageiit/orgs","repos_url":"https://api.github.com/users/kageiit/repos","events_url":"https://api.github.com/users/kageiit/events{/privacy}","received_events_url":"https://api.github.com/users/kageiit/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-08-03T18:19:07Z","updated_at":"2016-08-03T18:59:06Z","closed_at":null,"body":"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.\r\n\r\nThis 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.\r\n\r\nFor example, if gms had a color resource \r\n```\r\npublic static class color {\r\n    public static final int common_google_signin_btn_text_dark=0x7f0700b0;\r\n}\r\n```\r\nreferenced 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. \r\n\r\nThis 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.\r\n\r\n```\r\ncom.facebook.buck.step.StepFailedException: Failed on step dx_&&_write_file with an exception:\r\nfield ID not in [0, 0xffff]: 65536\r\ncom.android.dex.DexIndexOverflowException: field ID not in [0, 0xffff]: 65536\r\n```\r\n\r\n`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.\r\n\r\nHad a long conversation regarding this with @dreiss yesterday. I seem to see two possible solutions to this\r\n\r\n- Make the referenced resource calculation in dx more fine grained (but comes at the cost of performance)\r\n- 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.\r\n\r\nIf there are any other workarounds or other solutions, would love to know so we can try the best alternative"},"comment":{"url":"https://api.github.com/repos/facebook/buck/issues/comments/237336855","html_url":"https://github.com/facebook/buck/issues/828#issuecomment-237336855","issue_url":"https://api.github.com/repos/facebook/buck/issues/828","id":237336855,"user":{"login":"dreiss","id":4121,"avatar_url":"https://avatars.githubusercontent.com/u/4121?v=3","gravatar_id":"","url":"https://api.github.com/users/dreiss","html_url":"https://github.com/dreiss","followers_url":"https://api.github.com/users/dreiss/followers","following_url":"https://api.github.com/users/dreiss/following{/other_user}","gists_url":"https://api.github.com/users/dreiss/gists{/gist_id}","starred_url":"https://api.github.com/users/dreiss/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dreiss/subscriptions","organizations_url":"https://api.github.com/users/dreiss/orgs","repos_url":"https://api.github.com/users/dreiss/repos","events_url":"https://api.github.com/users/dreiss/events{/privacy}","received_events_url":"https://api.github.com/users/dreiss/received_events","type":"User","site_admin":false},"created_at":"2016-08-03T18:59:06Z","updated_at":"2016-08-03T18:59:06Z","body":"I have a feeling that undoing 4cf0eb7 could open up edge cases that would be a pain to deal with.  I'm now thinking that doing the fully-qualified name tracking is the best way to go.  Want to give it a shot and see whether the perf impact is measurable?"}}
{"actor":{"display_login":"dreiss"}}