Too many method references; max is 65536

A suggestion from a particular analytics middleware was that there is a bug in Unity which inflates number of methods. It's not that Unity added additional methods but that it "mishandles" other ( plug-in ) methods by duplicating them. The claim, which they made, is that they reduced methods by 5,000 in the latest version of their plugin. Yet, our build, which used to build previously, fails. Their engineer is firmly suggesting a Unity issue.

There is a second thread, this one from the rumor-mill, that unity 5.5 is going to handle DEX differently and resolve current issues we are experiencing with the 5.3. I don't have the specifics. What is it that 5.5 is doing that 5.3 isn't doing? I am very reluctant to move to 5.5 at this time since it is just in early beta.

Is there any other solution to your issue ? For example - are there any plugins that are not used?
Can you list what kinds of plugins you are using (or even better - the .aar and .jar files you have in your project) ?

I know, for example, that Google play services are now delivered as a set of .aar libraries. Including some of these (that are unneeded) will inflate the number of methods and can fail the build. Just a suggestion to check

A suggestion from a particular analytics middleware was that there is a bug in Unity which inflates number of methods. It's not that Unity added additional methods but that it "mishandles" other ( plug-in ) methods by duplicating them.

Unity Technologies

@babaroga there is an issue with plugin resources that make the reference number grow exponentially. I'm looking into fixing that (no luck yet). We are also planning to add gradle build support that will be free of the issue.

there is an issue with plugin resources that make the reference number grow exponentially. I'm looking into fixing that (no luck yet). We are also planning to add gradle build support that will be free of the issue.

Click to expand...

Please let us know when you succeed! It would be nice if this nasty issue could be solved within Unity build workflow, not requiring project export. We are using continuous integration server, and build scripts are not accustomed to complicated export-then-build pipeline.

I have also run into the issue once. The problem appears to be, that for all Android libraries (library folders or .aar files), Unity will bloat the number of resources (R.java), and since that class contains many generated fields, it will eventually exceed the number of allowed methods / fields inside the DEX, and will fail to build an .apk.

As a workaround, if you can use .jar libraries instead of .aar files, try to use them. JARs do not have any resources and so they will not bloat the number of methods.

This is not always applicable (e.g: when using 3rd party plugins, for example), but may be possible in certain cases and can allow you to work around the issue.

Did you have a look at my suggestion above? it can help you out (but may not always be possible to implement).
Also - Unity 5.5 beta 4 is now available and allows to build using Gradle, this can help with this error as well.

I changed every package name in every AndroidManifest in the game to the main package name and the app was building again. If it is still not working for you try also to change the package name in every AndroidManifest that can be found inside any aar-file of the game.

The only thing that sucks, is that every time we update a plugin we have to make sure to change the manifest again, since it is surely overwritten.

Hi everyone.
We have the same problem, and we have no solutions.
We can't compile anymore. I tried to compile with Android Studio but when using the same keystore file and same passwords and same aliases, it says that the license is not the same when I try to update the app on my device.
Moreover we can't afford crash because of splitted dex file because with target all devices from Android 4.0.3.

We are trying to reduce the size of the SDK to pass the dex limit, do you know if some lite facebook sdk exists? (It's using android compat v7 that is declaring a lot of functions. Google should also work to reduce their amount of references in Google Play Services, google play games is using way too much of google play services)

I was wrong in the end. Just renaming the package in the manifests is not solving the problem. The plugin resources are not found anymore and therefore the app crashes when using any functionality of the plugin.

I've found this has something to do with some "dumbness" in the build process, and the package names in the AndroidManifest.xml files:

If package names are different but reference the same classes the system will count them twice. I've been trying to narrow down exactly what package names are unnecessarily causing overlaps but it hasn't been straight forward. Some are easy my like I found the SDK above but other's I'm less confident about.

Anyone have anymore detail about how to treat all these different package names exactly?

We have also encountered this problem, after updating Facebook Plugin from a pre-7 to 7.4. Build was failing with 78K methods but before the update the count was at 63K. We're using Unity 5.4.2 and we observe that, during build, the R.java files behave similarly to this reported active issue . Our R.java files were 27 in number.. all duplicates, of course.

Our temporary solution is the same as suggested by MrPhil.

1) Find all plugin libraries that DO NOT have resource dependencies in a /res folder.
2) If you have .aar packages, you might need to explode them.
3) Find each plugin's AndroidManifest.xml and change the package name to eg your app's package id.
4) The above step should ONLY cause side-issues if there are resource dependencies. If the plugin does not have any, it should be safe to do.

@babaroga there is an issue with plugin resources that make the reference number grow exponentially. I'm looking into fixing that (no luck yet). We are also planning to add gradle build support that will be free of the issue.

Click to expand...

Please let us know when you have a solution for this! It is very annoying defect. It would be nice if this nasty issue could be solved within Unity build workflow.

Hi @Yury-Habets - is it possible to enable ProGuard from the editor? Currently I have to export my project in Android Studio and set minifyEnabled manually to get us below the dreaded reference limit.

I'm not particularly up on native android stuff, so Gradle and ProGuard is pretty alien to me and I'd much rather be able to build out of the editor than have to deal with Android Studio's all the time.

I've encountered this problem as well. Trying to set up an automatic build system but failed with too many method references in the dex process.

My problem is using Flurry analytics, which requires me to add google-play-services.jar to my project - Along with a whooping ~36000 methods. Way over the method limit now.

As I understand it, currently in order to build large projects (over 65536 methods) you have to first export into Android Studio, then build there?
Any tips on automating the Android Studio build process?

With unity 5.5 you can use gradle export, so you are able to build multi dex apk

Click to expand...

There are a couple of issues with this approach.
1) It doesn't work. (It may occasionally work for some HelloWorld tiny pet project, but not for existing big project.) And even official documentation admits this problem.
2) It's hard to automate.

There are a couple of issues with this approach.
1) It doesn't work. (It may occasionally work for some HelloWorld tiny pet project, but not for existing big project.) And even official documentation admits this problem.
2) It's hard to automate.

Click to expand...

1) It does work, I use it since 5.5.1p3 is out (p3 add the abilty to customize the mainTemplate.gradle)
2) Unfortunately yes. I hope this will change soon.

Before 5.5.1p3, I made a toolchain to export
_Android project,
_inject a custom build.gradle
_build with gradle

This was hard to maintain and very uncomfortable to work with.
Every sdk update was a pain, mainly because we wanted to keep a "light" build setup to allow us to use cloudbuild for test build (which include less partners sdk, so less references).

I'm not the happiest man in the world with the current method, but I'm much more efficient. I just need to be able to use BuildPipeline.BuildPlayer with gradle export and/or can choose this export method in cloudbuild.

Moreover, use mainTemplate.gradle allow us to simply reference aar files without include them and their dependencies in Assets.

After that I hope that cloud build will support cocoapod, so I'll bump ios threads

I'm using additional libraries, I've added custom AndroidManifest.xml, and indeed I encounter build errors. I'm glad it works for you. But I'm sure it's highly probable for @nitaym to face similair problems too. And instead of solving „65K dex issue“ he will end up solving an unpredictable bunch of side issues.

@Qbit86 you are quoting this phrase quite often, but misinterpreting it.

What it means is that badly written plugins will likely cause the build to fail (like, depending on resources which are provided in another plugin). Gradle is more strict with regard to the plugins. The plugins need to be fixed once, and no further build errors should be there.

If you believe there is an issue with Unity - please report a bug report.

replace one of ??? by gradle, or maybe another argument. In our case, gradle doesn't seems to be neither a BuildTarget nor a BuildOptions. I don't know if there is another case like this in unity (2 build systems for one platform).

Or maybe method should be a player settings, I don't think you can have a complex project that builds properly with both systems (BTW build system is not saved and I often forget to change it before Build). Or dropping old building system, but it could be painful for many teams (they do not know what they are missing)

@Yury-Habets - Just tried downloading the latest beta, but unfortunately quite a lot of our plugins no long work, so I can't test if this works or not. I guess I'll just have to wait until this is made public and the plugins updated and build manually in the mean time

replace one of ??? by gradle, or maybe another argument. In our case, gradle doesn't seems to be neither a BuildTarget nor a BuildOptions. I don't know if there is another case like this in unity (2 build systems for one platform).

Unity Technologies

@Yury-Habets - Just tried downloading the latest beta, but unfortunately quite a lot of our plugins no long work, so I can't test if this works or not. I guess I'll just have to wait until this is made public and the plugins updated and build manually in the mean time

"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.