I am running into the unable to merge dex problem that many posts seem to complain about. After doing some research, I think I have found the source of the problem, but I don't know how to proceed to fix it.
I am currently putting together various third-party components to create an Android application. It consists of the following parts:
app: The app itself, which is a minimal app with a Kotlin Activity created from Android Studio
libs: Two .aar files, A.aar and B.aar, where A.aar depends on B.aar
base: A third-party java module which provides some interfaces, helper functions and includes some dependencies for them. This module has its own build.gradle file.
I integrated them following these steps:
If I add base as a dependency of app, everything builds
When I add A.aar as a dependency in the app's build.gradle, it still builds
Then, when I add B.aar as a dependency for the app (implementation B.aar), the gradle build fails with the error: Unable to merge dex.
Looking at the Gradle stack trace, I found that it is complaining that multiple dex files define Lcom.google.common.io.ByteSink, which appears to be Google's Guava library.
Using the Project view in Android Studio, B.aar appears to actually contain version 18.0 of Guava inside it (under a 'classes.jar' section). I think this conflicts with base's implementation dependency line for guava 20.0 in its build.gradle.
Thus, I think I have found the source of the conflict (2 different versions of guava colliding), but I am not sure how to proceed. Was the third party wrong to have packaged guava into the .aar? If so, do I have any means of working around this problem other than asking the third party to remove it?
Things we have tried and did not work:
using exclude statements in the implementation statement that includes the AAR (I suspect it may only work with external dependencies, not with code that is built into the AAR)
using preDexLibraries (true worked for some of us, false worked for others -- it's not a solution!)
I'm more of a C++/C guy, so I may need a bit of hand holding with Java-specific concepts. I thank you in advance for any help.
The only solution we found was to do the following to the third party AAR:
Open the AAR file with a .zip file editor (ex: 7-zip)
Open classes.jar within the AAR
Navigate to the com directory
Delete the google subdirectory
We then added guava as a dependency in the gradle file
It works, it's the right thing to do, and we are pending an ok from our third-party provider.
Related
I downloaded this library and i extracted the rar into my app\libs folder.
Then I added compile 'com.github.lzyzsd:circleprogress:1.1.0#aar' to my build gradle as it says, and clicked on sync.
Then I noticed that the max is set to 100 (in file DonutProgress.java).
I changed it to 5, clicked on sync again but nothing changed.
After few hours of trying I decided to completely remove the extracted folder from my app\libs and sync again to see what happens.
Surprisingly, everything was still working like library was still there.
Can someone explain me what's happening here, I have to edit it but it seems whatever I do to the library doesn't affect the app.
It seems like it's using another library from totally different folder, I don't know, I tried searching for DonutProgress on my computer but didn't find anything that seems useful.
Please help.
When you add compile 'com.github.lzyzsd:circleprogress:1.1.0#aar' to your build.gradle dependencies, you are telling Gradle to go fetch this library from a repository when you build.
For most Android apps, this means that when you do a build, Gradle will go and download the library (in this case a .aar) from jCenter. This is good because it means you no longer need to manage the JARs (or other library files) yourself.
If you want to use a custom version of that library, then you should not add that dependency to your Gradle build script. Instead you should add it as either a module or a local dependency (e.g. compile files('libs/custom_library_name.aar')).
I'll try to explain as much as possible as this is more of a structural problem than code problem, ok, so i have project in which i am using android-support-library-v4, now in the same project i have now added three new libraries, these libraries also include android-support-library-v4, as they are part of their own code framework,
Now the problem is this is causing a jar mismatch in my project because i now have three same android-support-library-v4 in my project.
I tried the solution of removing the android-support-library-v4 jar file from my main project but this does not resolve the jar mismatch from the other libraries i have used in the project, and i cannot delete the android-support-library-v4 jars from the libraries as they would not work without them meaning they will stop functioning...
Simple solution for this problem , What i usually do is , steps are.
Just copy any android-support-library-v4 from any lib project
Then copy and replace this to all other libs projects.
This will remove your mismatch problem
I will suggest you to use Android Studio as Google official IDE.
Before you say that this question was asked. I want to say that I have read through most of the questions and they give just workarounds for this solution and other ones are out of date.
My question is, how create Android library in Android Studio, so I can export it to closed .jar with no sources and distribute it to other developers.
When I click New Module -> Android Library, it creates me folder under my current project. I don't want that.
I want to create library from the beggining (where is option for this in Android Studio?), so it is standalone project which later I can export to jar.
Android Studio doesn't have UI to allow you to create an Android Library as a new project. To do this, you'll have to one of a few different routes.
Before you start, I'd encourage you to think about packaging your library as an .aar instead of a .jar, since you say it will be calling Android APIs. The reason for this is that .aar is a richer format for Android projects and allows the archive to include manifest information, such as the minimum required SDK and such -- it will go farther to ensure that your library is compatible with the environment it's being included in. The disadvantage is that only the Gradle build system supports .aar files, so Eclipse users wouldn't be able to use the archive.
Though you're not using Android resources, if in the future you do need to include resources in your archive, you'll be set up.
There's more information on .aar here: http://tools.android.com/tech-docs/new-build-system/aar-format
If you want to package in .aar format, you could go a couple routes:
You could create a project with the New Project wizard. This will initially be set up to make a full-fledged Android app that compiles to an APK. You can go into the app module's build.gradle file and change this line:
apply plugin: 'com.android.application'
to:
apply plugin: 'com.android.library'
It will now build an .aar. However, this project will still have resources in it, and maybe layouts and activities depending on what options you chose in the wizard, so you may have to rip out what you don't want.
The alternative is you could start with a blank slate, crafting your own build.gradle file from scratch that uses the com.android.library plugin, and fleshing out the source directories. This will be more cumbersome, but as with all difficult activities, you'll learn a lot and it will build character, or you can at least tell yourself that as you're puzzling things out.
If you want to package as .jar instead of .aar, then again there are a couple routes you could go. For this type, if you want maximal assistance from the UI, you could start a new Android project and add a plain Java module to it. You can either remove the unwanted Android module from the project, or you could even leave it alone; the build process will output a .jar for your plain Java module in any event.
Your plain Java module will need to depend on the android.jar archive from the appropriate platform in your SDK.
Alternately, you could build this module up from scratch, authoring the build.gradle file and setting up the sources yourself, and then you could import that into Android Studio as a new project.
Actually it's a bad idea to use your IDE as project management/build system
Take a look on gradle or maven
also take a look to
http://tools.android.com/tech-docs/new-build-system/user-guide
however, if you want do this in ide:
File -> Project Structure. in opened window add jar in Artifacts tab
Build -> Build Artifact.
https://www.jetbrains.com/idea/webhelp/packaging-a-module-into-a-jar-file.html
it's shouldn't be specific for android lib
I have been successfully using android-support-v7-appcompat library for last few months in my app to support action bar in older devices. Recently I have downloaded the Android 4.4(kitkat) updates with system image and SDK platform from the SDK Manager. I also added targetSdkVersion to "19" in manifest file. But my project was showing error as 'android-support-v7-appcompat jar mismatch. Fix your dependaecies.' Then I added the jar from /extras/android/support/.... to the project as an external jar using build path menu > add external jar. Now there is no error in the project and android-support-v7-appcompat.jar & android-support0v4.jar file is showing twice under 'Referenced Libraries' folder and also once under 'libs' folder. The project is not showing error and running, but crashing in different activities.
Previously I imported the android-support-v7-appcombat library as an external project in the workplace. I can see error in that project. Please suggest what should I do now. Also, android-support-v7-appcompat.jar umder Android Dependencies in Java Build Path showing error.
The error I see is:
Found 2 versions of android-support-v7-appcompat.jar in the dependency list,
but not all the versions are identical (check is based on SHA-1 only at this time).
All versions of the libraries must be the same at this time.
Versions found are:
Path: C:\<project hierarchy>\libs\android-support-v7-appcompat.jar
Path: C:\Users\....\sdk\extras\android\support\v7\appcompat\libs\android-support-v7-appcompat.jar
Jar mismatch! Fix your dependencies
After getting idea from different forum, I removed all the android-support-v7-appcompat libraries from different places, and imported android-v7 support library again in the project. Still it's showing error. Should I also delete android-support-v4 libraries from buildpath and libs/private librariry/referenced library folders?
This error occurs when there are multiple and different instances of the same library are found in the same project, or libraries used by it. A very simple way to resolve this is use the common lib at both the places. To do so:
Just copy your C:\Users....\AppData\Local\Android\android-studio\sdk\extras\android\support\v7\appcompat\libs\android-support-v7-appcompat.jar
and paste it in your libs folder, replace the old one with this. Clean the project, and it shall compile now..
Edit 1:
Basically the idea is if you are using the same libraries, it shall be the common jar, or the same jar.
In your case if you are using the appv7 as an external project, please go to libs folder of your project copy android-support-v4.jar, and paste into the libs of android-support-v7-appcompat project.
Also, make sure if there are other external jars or support libraries used by you, they shall be the similar jars in all the projects you are using.
I hope it helps!
I had exactly the same problem after installing all the updates mentioned in the question. I am sure there are different ways to solve this problem. Here is the way I used:
Previously, when an activity was created, the following project was automatically generated by the wizard:
androi-support-v7-appcompat and this project was added to the build path.
After all the updates, the following equivalent is generated when an activity is created:
appcompat_v7 with the jars of the same names.
I deleted androi-support-v7-appcompat and made sure the projects use appcompat_v7 to replace androi-support-v7-appcompat in their build paths. This made hundreds of errors generated by the duplicates go away.
I am glad that i finally found the answer. I was encountering the same problem again and again and i was like fed up.
Here is the answer to your question.
whenever you get such an error just don't touch anything other than libs folder. Just go directly into the libs folder and right away delete the android-support-v4.jar. and clean build your project. You will be relieved to get rid of errors.
Hope its useful to you.
Keep coding..
I have actually figured out the solution by trying different options suggested from different forum. I had manually change the android-support-v7-appcompat project's(which was added as an external project) project.properties file and had to set 'target=android-19'.
I'm writing an eclipse plugin. This plugin uses a few local jar files, and additionally has a few dependencies on other plugins.
I'm using the Google Code Search API from jar files, and it works fine; but after I add the plugin dependency org.eclipse.zest.dot.ui to my project, the Google Code Search API does no longer work - on calling new CodeSearchService("my_ID"), I'm getting the following run-time error:
Analysis failed: java.lang.NoSuchMethodError exception raised.
com.google.common.collect.ImmutableSet.buider()Lcom/google/common/collect/ImmutableSet$Builder;
I have carefully checked and reproduced this: if the plugin appears in the dependency list, the CodeSearchService can no longer be used; if it doesn't, it works perfectly. The actual project code does not change, only a dependency is added.
This is very strange to me, as I don't see how adding a plugin dependency should suddenly make some methods disappear. Has anyone encountered anything similar, and can share any insights about this problem and a possible solution? I'm not even sure if this issue is specific to these two libraries or not.
The org.eclipse.zest.dot.ui bundle pulls in dependencies that depend on the Google Collections, so my guess is that the Google Code Search API requires a different version of these, and is now trying to use the other version. Not sure how to solve this, but you could try to update both to the latest version (see http://wiki.eclipse.org/Zest#Zest_2.x for the newest org.eclipse.zest.dot.ui bundle).