I've a main project that depends on other Library projects that use external JARS (that are also used in the main project).
Now with ADT17 I have removed from the main project the external libraries that are also used in library projects, because they are automatically inherited from new AD17 Android dependencies (from library projects).
Until here all works correctly. The problem is when I want to create a Test project for the main project. What I do is mark all externals jars and android dependencies as exportable to be inherited in the test project.
But the problem is that Android dependencies although they are market as exportable aren't inherited from the test project and when I run it I get some Link of class X not found... make sure it's in the apk.
I attach an image to make it more clear:
(It's an snapshot from main project libraries. Blue marked ones are correctly inherited and red ones not).
It seems that it was a bug in ADT17 with test projects that depend on external libraries.
Today I've updated to ADT18 and it works correctly without having any lib defined in test project.
Related
I am writing an android library project and trying to test it. I found testing a library project
more difficult than it has to be using my current method.
Right now, I am exporting the library project into jar file. Then I put it into the libs folder of the test project and the test target project. Then I add it to build path of both projects and run the test.
Every time I make a change to the library I have to do this again. Is there easier way to do this?
There is some reference to this in the google docs. Check out http://developer.android.com/tools/projects/index.html#testing
Basically, the easiest way is to write an application that uses the library project and then add unittests to that application.
When creating the tests via eclipse, you can choose to test modules from within your library project. This way, changes to the library project are automatically applied.
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.
I have some java code (compiles nicely for Android) in a library project (LIB) that I want to use in an another Android project (A).
As LIB's code is unlikely to change much, I opted for adding it as a jar to A. It works fine.
I have another project that is an Android instrumentation project, testing the first Android project (B).
So what we have now is A including LIB as an external jar, and B testing A.
The problem starts when I want to access from B code written in LIB.
From what I see, unless I add LIB as an external jar to B, it refuses to compile (that is, it cannot access the code in the LIB jar that is included in A).
I am reluctant to add LIB as an external jar to B because:
1. It doesn't feel right, and
2. When running the tests it fails with:
java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
I found Mike's question, but his solution only covers compiling using an ant script, and I currently prefer to use the Eclipse IDE for this project.
Any idea how can I solve this issue?
(In order to remove this question from the "Unanswered" filter...)
The solution is outlined here:
Android Testing: External libraries
The LIB should be exported from A to make it accessible from B.
According to this SDK guide, unit-testing a Library project can be achieved by creating a standard application project, reference the Library project and then instrument the application for unit testing.
However, when I do this and launch the test application I get the message
No tests found with test runner 'JUnit 3'.
I'm using Eclipse and the Android ADT plugin, all latest versions.
Note: the projects compile just fine. The test project also installs fine to the emulator. But in the console I can see that it looks for <library>.apk, which of course doesn't exist since I'm compiling this as a library into the test project.
Anyone got this to work? And if so, what is the trickery here?
Update: after discovering and fixing a problem, which was actually including the test classes (!), the test runner now can find all tests. But, all the tests fail with the following exceptions:
java.lang.NoClassDefFoundError: <nameOfClassInLibraryProject>
nameOfClassInLibraryProject are classes defined in the library project. These classes should be compiled into the test project, and indeed, everything compiles just fine. But when running the test project, the runtime doesn't seem to find the library classes.
After much fiddling and wasted time in Eclipse I have managed to get Android Library projects to work.
According to the Working with Library Projects article:
Instead, you must compile the library indirectly, by referencing the library from a dependent application's build path, then building that application.
The problem was that I interpreted this to mean that the library project should be added to the Projects tab in Java Build Path. Doing this makes the test project compile since the library code is obviously available to the compiler. But since the library is not compiled into a .jar or .apk in itself, the library classes are never deployed to the device.
The solution is to not add the library project to Projects, rather on the Source tab, add the library /src folder using the Link Source... button. And yes, it is the library src folder, not the library project root, that must be linked into the test project.