Too many method references; max is 65536

Hi,

After adding yet another fat Android plugin the build got broken:

Code (csharp):

1.     Error building Player: CommandInvokationFailure:
2.         Unable to convert classes into dex format...
3.     stderr[    
4.     trouble writing output: Too many method references: 68573; max is 65536.

I know about Dalvik limitations and have read related topics.

How can I solve the problem?

I need to build the game on continuous integration server, so manual exporting and editing Eclipse project does not suit me.

There are suggestions over the internet to modify ProGuard build step but I haven't succeeded with this optimization.

Probably I should strip large jars somehow, but I don't know how. The most fat are (with size in bytes):

Code (csharp):

1.     4599100  google-play-services.jar
2.      995624  android-support-v4.jar
3.      925432  everyplay.jar
4.      852733  FlurryAds.jar
5.      687508  vunglePub.jar
6.      552394  facebooksdk.jar
7.      504254  gamecirclesdk.jar
8.      246509  login-with-amazon-sdk.jar
9.      215040  AmazonInsights-android-sdk-2.1.26.jar
10.      147242  unity-ads.jar

Any concrete suggestions would be very much appreciated. Thanks!

----
Unity 4.6.5p1
Windows 8.1 Pro

 

Do you know if ProGuard is supported straight out of Unity ?

If not, i think a Google Android project is the way to go. If you're building from a CI server, it should be fairly easy to get an APK from an Android project.

 

> Do you know if ProGuard is supported straight out of Unity ?

I don't know the details of build process neither in Unity, nor in Google Android project. I see a lot of `project.properties` files with contradictory lines:

Code (csharp):

1. # This file is automatically generated by Android Tools.
2. # Do not modify this file -- YOUR CHANGES WILL BE ERASED!
3. ...
4. # To enable ProGuard to shrink and obfuscate your code, uncomment this (available properties: sdk.dir, user.home):
5. #proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt

Uncommenting the last line produced no effect (still 68573 method references).

>it should be fairly easy to get an APK from an Android project.

Well, I'm neither aware of build bot settings It has been already set up to build working directory with Unity; some custom steps were defined, though. But automatic on-commit exporting to Google Android project, applying custom changes (patches?) to `proguard.config` and compiling .apk — it seems to be far away harder to set up and maintain.

 

Exporting to Google Android Project also fails with the same error.

 

Does the Unity build process for Android generate an intermediate project structure and then proceed to build it automatically? (when building an APK)

Or do the 2 build processes differ entirely?

 

What i was getting at, is whether the "Google Project" build is guaranteed to succeed, if the APK build succeeds?

Or, in this particular case - since the dex tool fails to complete, does it mean that the Google Project build is expected to complete successfully ? (since it does not invoke dex)

 

Export fails for exactly the same reason: “Unable to convert classes into dex format... Too many method references: 68573; max is 65536.”

I can try manual temporary removing some fat jar to prevent 65K limit overflow, exporting and adding it back to generated project. Where should I add this jar? To some libs/ folder? Is it enough or I need to edit some build scripts? How can I automate this actions for letting them be performed on build server?

Is the way to go where? Should I try Android Studio or out-of-dated Eclipse plugin? What should I do next — edit ProGuard settings? How? To be honest, I even cannot figure out how to compile apk — “Build” menu in Android Studio does not help.

 

When Unity builds an APK it runs tools from the Android toolchain to produce the APK for you.
One of these tools (Dex) fails due to a limitation in the dex format (limit on the number of methods).

In this case, it was suggested that "the way to go" (e.g: how you should solve this) is by exporting a "Google Android" project. In this process, Unity only builds a project template for you and you could then customize this before building an APK from it.

This "customization" could allow you to run tools such as ProGuard that will strip off unused code, reducing the number of methods from your final APK, for example.

I think you could use either Eclipse or Android Studio, it doesn't matter much.
Android Studio is the newer one and is the suggested approach to use nowadays (even though i personally still keep Eclipse around as well).

One you export an android project from Unity i could help you move on with ProGuard and getting an APK.

 

It's strange that the same error appears when I try exporting, not building. I expect that all the toolchain should not be invoked, just prepared with generated intermediate project. But it looks like Unity actually runs Dex packing anyway.

Thanks for clarification! I'm already using similar workflow for building WP8 edition of our game; and my colleagues do the same for iOS via intermediate XCode project. I'm just wondering if there are any ways to keep at least Android simple

The main problem is that I don't have any experience in Android or Java programming (I'm .NET developer), so I'm facing with avalanche of beginner questions about toolchain and basic pipeline, not mentioning specific details like ProGuard settings.

I'd prefer using the up-to-date tools; just wondering if Unity supports recommended approach.

 

When I choose “Import project (Eclipse ADT, Gradle, etc.)” opening Android Studio, it gives the following options:

Code (csharp):

1. (•) Create project from existing source
2. ( ) Import project from external model
3.     (•) Gradle
4.     ( ) Maven

Which one should I prefer?

(One more “thanks” for all participants of the discussion!)

 

I think you should choose the first option.
*If i remember correctly, Unity's project template is pretty dated (i am not using it, but i did try it in the past), so it's not using Gradle or any of the newer project structures that android uses.

 

Has anyone faced this kind of error error?

Code (csharp):

1. Error:ProGuard: [UnityOBBDownloader] java.io.IOException: Can't read [C:\Users\Viktor\.AndroidStudio1.2\system\compile-server\_temp_\proguard_input0.jar] (Can't process class [com/unity3d/plugin/downloader/BuildConfig.class] (Unsupported class version number [52.0] (maximum 51.0, Java 1.7)))

Looks like incompatible versions of some tool (probably ProGuard itself) between SDK used by Unity and SDK installed with Android Studio. Can't figure out which settings are to be fixed.

 

Still not convinced that this is Unity fault, more likely something is wrong with my environment settings. But, of course I can report an issue.

Plugin worked perfectly for a long time until we tried intermediate project exporting. This is official plugin, not something “home-made”: https://www.assetstore.unity3d.com/en/#!/content/3189

 

I cannot attach our main project because of NDA, but I succeeded reproducing an issue in separate project, attached to the ticket: http://fogbugz.unity3d.com/default.asp?699275_sc6a9suigrjnc5v8

 

The second exporting issue is filed: http://fogbugz.unity3d.com/default.asp?699280_s1b0urqq6pcr7o2t

 

Please let me know if there are some new info on these issues, “confirmed” or “wontfix”.

 

Did this never get fixed? I am running into the Too Many Method References, and assumed I could export to Google Android Project, but that still fails with the same error. Using 5.2.3f1. I am not sure what to do now, as I can't remove any of the jars from my project.

Edit: I was able to use a script to remove some pieces from an older google play services jar to barely get this under the 65K limit for now, but there needs to be a better solution. Link: https://medium.com/@rotxed/dex-skys-the-limit-no-65k-methods-is-28e6cb40cf71#.dsya048xb

 

Getting the same error.. I just imported everyplay and boom.. dexed.

 

Hi, Yury, when can we download the 4.7final or the 5.3.0p1 ?

 

Thanks ~

 

Yup.. it is fixed in the latest build.. however the build will not work with Amazon as they add more stuff to the apk file which will run into the dex problem.

Mine just got rejected today because of that.

 

I added a new library and the dex issue popped up again...

 

Hi guys,

Also running into the dex issue while exporting -- we're still on Unity 5.2. Yury, when can we expect to see a patch release fix for this issue on 5.2?

Thanks!

 

Any plans to have Unity strip out unused class files? Have been fighting with Android Studio for days just to successfully build an APK without any luck. Using Unity 5.3.1f1, Android Studio 1.5.1, JDK 1.8.0_66 (also tried JDK 7).

Here's my current errors if anyone has seen this before:

"
UNEXPECTED TOP-LEVEL EXCEPTION:
Error:com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000)
at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:472)
at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)
at com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)
at com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251)
at com.android.dx.command.dexer.Main.parseClass(Main.java:764)
at com.android.dx.command.dexer.Main.access$1500(Main.java:85)
at com.android.dx.command.dexer.Main$ClassParserTask.call(Main.java:1684)
at com.android.dx.command.dexer.Main.processClass(Main.java:749)
... 12 more
1 error; aborting
Error:Execution failed for task ':brainItOn:transformClassesWithDexForDebug'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command 'C:\Program Files\Java\jdk1.8.0_66\bin\java.exe'' finished with non-zero exit value 1
"

 

Hello Yuri, could you please detail your enviroment so we could get your results. I mean Android Studio version, JDK version, android sdk verion and if any of this are 32 bit or 64 bit, and also if you are using Mac or Windows. That could really help, because whatever i install i cannot see the "Project SDK" thing and i'm stuck in the "Unsupported class version number 52.0 maximum 51.0, Java 1.7" error. Thanks in advance.

 

Running 5.3.3p3 and just ran into this issue after importing an extra ad provider. Is this supposed to be fixed now?

 

(0034.0000) means your project should use java 7 but your android studio is using java 8 "Files\Java\jdk1.8.0_66\bin\java.exe". Download JDK 7 and set it as your java path.
In Android Studio goto File->Project Structure->SDK Location(select from the menu on left)->JDK Location.

This would solve it. It worked for me.

 

Hi there

I just updated to 5.3.4p6 and I seem to be getting the same error:

Is the issue only fixed when building a Google Android Project?

Cheers

 

Still getting the same error in 5.3.4p6.

I've parsed Editor log to group by references count. It looks like many entries are duplicates of each other, but sum up separately:

Code (csharp):

1. 2029 com.google.android.gms.nearby
2. 2025 android.support.v4
3. 2025 android.support.v7.appcompat
4. 2025 android.support.v7.cardview
5. 2025 com.facebook.android
6. 2025 net.prime31.plugins.googlecloudmessaging
7. 2019 com.everyplay.Everyplay

In some cases I can change `package` in third party `AndroidManifest`s to be the same, for example `com.unity3d.player`, as suggested here: https://goo.gl/vmDv8y
But this is not solution in general.

 

Are there any plans to fix this?? We are using several plugins and most of our Artists constantly create builds.

Having to open an Android Studio project, compile, load and launch would really kills us right now.

 

I am still facing this problem on Unity 4.6.9.

As we have read above that people are facing it on even Unity 5.3.x as well. What is the solution?

 

On 5.3.6 we are getting failure to compile an APK due to too many methods. The number of methods has increased (on it's own?) by migration from 5.3.3 to 5.3.6. We have spoken with middleware partners and they claim to have reduced number of methods, not increased them. Is this a known issue?