Too many method references; max is 65536

Cant run the tool since i can't build the APK - catch-22

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.

 

I am not aware of any Unity bug that duplicates native methods.

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

 

There is a hacky way to overcome this issue: https://androidthoughts.wordpress.c...version-to-dalvik-format-failed-with-error-2/ (see list item 4).

 

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.

 

Bump

 

Bump

 

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.

 

Are there any news about this issue? We updated the Helpshift-Plugin recently and now we are not able to build the android-client anymore:

trouble writing output: Too many field references: 85684; max is 65536.
You may try using --multi-dex option.
References by package:
...
2823 android.support.design
2829 android.support.v4
2823 android.support.v7.appcompat
2829 android.support.v7.cardview
2823 android.support.v7.recyclerview
2861 com.chartboost.sdk.unity
2863 com.everyplay.Everyplay
...

It seems like it is the issue mentioned above, since the method count of the various plugins is very similar.

 

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.

 

Thanks for the response, but actually the link above was helping me in the end: https://androidthoughts.wordpress.c...version-to-dalvik-format-failed-with-error-2/

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.

 

Kind reminder that you can access my "fix build issues" service any time link is also in my signature.

 

Is this Gradle support is a part of a built-in build process? Or the project needs to be exported to build it with Gradle?

 

You get to choose whether to export as a gradle project or build using gradle (produce an .apk)

I think that any of these options should help eith this particular issue.

 

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?

 

There's a bug that causes Unity to "bloat" the number of references, so you may experience this issue even if you don't really have 65k method references.

 

I agree. I was able to reduce my count by changing package names when it seemed like they overlapped.

 

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.

We did the above with the following :

1) Google Play Services : drive,games,iid,nearby,tasks (warning: base, gcm, basement have dependencies)
2) Vungle
3) Chartboost
4) Prime 31 Flurry Analytics (Android)
5) Prime 31 Etcetera

Dex count is now reduced to 60K. R.Java files are now around 15.
Preliminary QA shows that everything critical runs OK, I will update when I have the full report.

EDIT: Updated post to REMOVE changes in cloud messaging as there were some dependencies. Everything else works fine.

 

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.

 

Does it allow easy scripting of automatic build process? Now we call Unity in command line passing bunch of parameters to Buildbot and Python scripts. Do not want to overcomplicate things :-`

 

Moreover these methods are unsupported with unity cloud build, which is really an issue.

 

There is already some threads, which are always concluded by something like neither supported nor planned.

https://forum.unity3d.com/threads/using-gradle-build-system-with-cloud-build.453952/

 

I can bump all day long !

 

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.

[EDIT] and a +1 for Cloud support!

 

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

 

Try using some another Flurry plugin, which relies on new style separate `play-services-*.aar`s, not on legacy monilithic `google-play-services.jar`.

P.S. @Yury-Habets when signing in to forum will be fixed? Now it's nearly impossible to preview, submit or edit replies; it may take dozen of attempts.

 

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.

 

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

 

Documentation states: „you may encounter build errors, especially if you are using additional Android libraries, or if you have added a custom AndroidManifest.xml“. https://docs.unity3d.com/Manual/android-gradle-troubleshooting.html

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.

 

I'm not blaming Unity for difficulties in Android development (at least for some of them). What I'm trying to say, is that advices like „just switch to Gradle/Proguard/Multidex“ are not so „just“.

(Alas, I have never seen properly written Android plugin, it has yet to be found. Even quite expensive like ones from ***31, if you see what I mean.)

 

The ability to launch gradle build from an editor script, and therefore by batch mode.

BuildPipeline.BuildPlayer(MainScene, args[0], BuildTarget.Android???, BuildOptions.???);

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)



And last but not least, cloud build support

 

@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

 

Just a quick update: I ended up using https://github.com/googlesamples/unity-jar-resolver

This tool lets you break google play services into smaller units as described here
https://developers.google.com/android/guides/setup

Managed to drop the methods count under the limit

 

Sorry, I meant final release at the end of the month, when everyone will update their plugins and make the changes to the API.

It just wasn't compiling, I had a few hundred errors all over the place within these plugins - stuff with player settings, audio sources etc. not sure what exactly, as I just rolled back.

I might take another look today - I was a bit rushed yesterday and gave up quickly

 

Right, I've had another look and it wasn't so bad to do the fixes, just a few changes here and there.

But in doing the build, I'm still getting failures:

Code (csharp):

1. FAILURE: Build failed with an exception.
2.  
3. * What went wrong:
4. Execution failed for task ':transformClassesWithDexForRelease'.
5. > com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: java.util.concurrent.ExecutionException: com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536

It doesn't seem that its running the minify, as when I run it through Android Studio's, it works. Is there anything else I can do?

Running Unity 5.6b11

 

I tried in batchmode, something happened, I guess it's the unity compilation step, and then it stop. No error, just no output.

 

Where is the main gradle template kept? Would like to be able to build straight out on Unity rather than messing with Android Studio all the time.

I'm guessing thats Unity 2017 alpha is it? Or will it be making an appearance in 5.6.x?