Is it possible to use Multidex inside a library project? It's not so hard to hit the 65k limit when you have libraries like Dagger, RxJava and Databinding. I'm really stuck here, any help would be really appreciated.
I am trying to 100% validate that this is true but based on how the normal build process works my hypothesis is that because your AAR consists of .class files and the normal android build process includes dexing all project files including libraries (AARs, and JARs) that adding multidex to your library really will just help with making sure that when they library is built in its root project that it is able to multi-dex properly.
Let's say you you build an AAR (which needs Multi-Dex) and then you import that aar into another project. Chances are you are going to need multi-dex on the project consuming the library as well because though the compiler doesn't need to compile the java classes it will still need to dex and do resource compilation on the entirety of the AAR.
Related
I'm using many applications in one project like :
So i have some questions here, Application must implement iterated libraries ?
Assume i have com.android.support:appcompat in my "app" gradle and have the same one in my "opencv-java" gradle the apk will compiled with both libraries and double the size?
If no, then what happened in compiling process?
If yes, How i can avoid this, is there a way or some thing?
Update :
If i have libraries (e.g: "volley", "support" etc..) in my app "gradle" and also i used it in my open-cv "gradle", that's make me able to remove those libraries from app "gradle", it's seems that main app that used compile project(':another-app') in "gradle" can use another-app libraries, with codes and assets, every thing.
the apk will compiled with both libraries and double the size?
No.
then what happened in compiling process?
Well, one of two things:
If you use compile "com.android.support:appcompat-v7" consistently, Gradle will only use one copy of that dependency.
Your build could fail with an error message complaining about duplicate Java classes, stemming from the duplicate libraries. This would happen if you are not actually using com.android.support:appcompat-v7 in one place, but instead are adding appcompat-v7 by some other means (e.g., directly compiling against a copy of that library project).
What can't happen is your double-the-size scenario, as you cannot have two copies of the same Java class in a single APK.
My scenario is like i'm using same jar in multiple aar and integrating into single project. How to avoid the jar duplication issue.Multiple dex files issue.
I'm not sure if I understand but maybe this will help.
If you're using gradle for every dependency you can define a closure and use exclude property. That way you can define groups, modules, etc, that are to be ignored.
It is often used to solve dependency conflicts in libraries.
Discussion in gradle forums: https://discuss.gradle.org/t/how-to-exclude-transitive-dependency/2119/2
I'm using the commonsguy cwac-camera library, as per the demo-layout example, documented in "Working directlly with cameraview".
All is fine referencing camera/ and camera-v9/ as Android library projects in source form (I need Android 2.3 compatibility, that's what camera-v9 is for).
When I switch to using the library via JARs:
- cwac-camera-v9-0.6.8.jar only includes CameraFragment and BuildConfig classes, so I need also cwac-camera-0.6.8.jar with the other classes.
- including both JARs causes the following self-explaining error when running the project (not at compile time) Conversion to Dalvik format failed: Unable to execute dex: Multiple dex files define Lcom/commonsware/cwac/camera/BuildConfig;
I could just use the source as library project, or use Gradle, but I want to know if this is a bug to open an issue on Github, or if I'm doing something wrong.
To replicate the error, just clone the demo-layout example add both .jar files to libs folder, and run the project.
No, this appears to be my fault. They must have changed something in the Gradle build process that I am using to create the JARs. I will try to fix this tomorrow. In the meantime, you could go into the cwac-camera-v9 JAR and try removing the classes in com.commonsware.cwac.camera, leaving only those classes incom.commonsware.cwac.camera.acl.
My apologies for this, and thanks for pointing it out!
I have maybe this not so common setup:
(> = dependency)
Android project > Android library project 1 > Android library project 2
So I have an Android library project which has a dependency to another library project.
When I'm building project in Eclipse everythings works fine but I cannot get my build working with Ant.
First Ant compiles Android library project 2 which generates a classes.jar and puts this file in the bin folder.
Then Ant tries to compile the Android library project 1 but then I'm getting errors becouse it is missing classes from Android library project 2.
Well this is not so weird becouse the jar file is not included in the libs folders.
But in project.properties i've made a dependency to the library project 2 so why does Ant not copy the classes.jar to the libs folders of library project 1?
Well I can think of a solution to use an Ant task to copy the file to the libs folder, but then I have to modify the build.xml which I do not prefer.
** EDIT
The problem is that the R class is missing, when I look in classes.jar this java file does not contain the R class. So my solution would proberly not work.
This behaviour was caused by a change in R17 of the build tools: http://tools.android.com/recent/dealingwithdependenciesinandroidprojects
In a nutshell: R files for libraries are no longer packaged in the classes.jar for that library. However, since the pareent.R for the parent-library (project1 in your example) also contains the resource-references for the 'child' library (project2 in your example), you don't have to refer to the child-R anyway.
Replace all project2.R-import statements in project1 with project1.R import statements and you should be fine.
For ant to compile add dependency in ant.properties.
eg:
android.library.reference.1=../path/to/library
This sounds like a very brittle setup - you may have good reason for this, but could you instead decouple the libraries dependence on each other?
For example; implement a bridge pattern to translate the calls between both libraries, and make the calling Android project attach them. This way, you have no code in either library that depends on the other, and the only project that needs to handle dependency setup is your main project.
One of the main reasons for using a library is to make the code re-usable, this approach ensures someone (you, a colleague, your successor...) could plug in just one library and create their own implementation of the other one.
Here is another good article on applying the bridge pattern in Java: http://java.dzone.com/articles/design-patterns-bridge
Well the problem was that the R class was missing.
So i removed the R class dependency between the two library projects.
I don't know if this is fixable but i think it is bad practice any way.
Without this dependency Ant builds fine.
Old question, but like me, others might be banging their head on this...
The official answer is "it cannot be done", specifically:
At build time, the libraries are merged with the application one at a time, starting from the lowest priority to the highest. Note that a library cannot itself reference another library and that, at build time, libraries are not merged with each other before being merged with the application.
(extracted from the official documentation: "Referencing a Library Project").
Which means that anything goes, as there is no "clean" way to do it with the tools (and dirty methods are in order).
Hope it helps
I have a rather large Android project, and it takes considerable amounts of time for the sdk to do the resource-parsing / dexing / etc. I'd like to improve this somehow.
I've read that Android library projects can contain resources now too. So we can also put Activities, Fragments, etc. in them.
Does this mean, that if I export parts of my large project into library projects which I reference from the main project, then I don't have to rebuild the already built (and not modified) libraries again, when I rebuild the main project? So I only have to do the resource-parsing / dexing / etc. for the modified libraries and possibly the main project, decreasing the overall build time in most cases.
Does this mean, that if I export parts of my large project into library projects which I reference from the main project, then I don't have to rebuild the already built (and not modified) libraries again, when I rebuild the main project?
Partially no, Android Library Project is not built directly, it is always built along with the dependent Main Project, when SDK compile/build the Main Project, SDK tools compile the Library Project into a temporary JAR file and uses it in the main project. whenever you re-build your Main Project, the referenced Library Project is re-built as a part of main project build life cycle, even though nothing changed in Library Project. Check out timestamp of the temporary JAR generated under your app-lib/bin folder for evidence, it always get changed every time yo build Main Project.
Quoting from official dev guide:
However, a library project differs from an standard Android application project in that you cannot compile it directly to its own .apk and run it on an Android device. Similarly, you cannot export the library project to a self-contained JAR file, as you would do for a true library. Instead, you must compile the library indirectly, by referencing the library in the dependent application and building that application.
When you build an application that depends on a library project, the SDK tools compile the library into a temporary JAR file and uses it in the main project, then uses the result to generate the .apk. In cases where a resource ID is defined in both the application and the library, the tools ensure that the resource declared in the application gets priority and that the resource in the library project is not compiled into the application .apk. This gives your application the flexibility to either use or redefine any resource behaviors or values that are defined in any library.
Android Library Project is different from regular java library project. where you can compile and build everything into and jar library once, and start import/use the class from reference jar dependencies in main project. Currently Android Library Project is designed on source-based mechanism, not compiled-code based library mechanism, as mentioned in this Android blog, although self-contained jar distribution is promised in future release (unfortunately not in neither r15, r16, r17 nor r18 yet).
Yes... The build system rebuilds what needs to be built unless you build Clean.
I wouldn't expect huge time savings here.
In my experience, the slowest step of compilation is actually the dexing of the output files, which can not be performed incrementally, so moving your code into libraries will not speed things up. Similarly, incremental compilation (when it works — it often doesn't with the Android toolchain) will work equally well with unchanged files spread over a bunch of projects as will unchanged files in a single project.
Of course, the best way to find the answer for your actual use case is to experiment on your actual code base. And there may also be code maintainability benefits to splitting your project up into independent modules.