I found this Adding a library/JAR to an Eclipse Android project and followed the directions there, but I still seem to be getting a NoClassDefException on my class derived from the third party library.
I downloaded the third party library and imported according to the answer above. According to this, it will convert the code automatically to dalvik. Then, when I run on my phone, it tells me it cannot instantiate the sub-class of the third party library. Other messages say it is because it cannot find the superclass.
Am I missing something obvious?
It appears that the "libs" directory is a magic name. I renamed my directory to libs and re-ran the app and it appears to be working.
Related
I am going to use SkyEpub 3 library in my android application to read ebooks in epub format. To get familiar with the method of using SkyEpub I have downloaded its android demo project from here.
Its demo project is working properly, But when I use the skyepub.jar in my own project, it says some methods and classes from the jar file are undefined. Of course in the mean time I am using an unlicensed version of this library. I want to test it before buying the license if it was ok. I doubt that the errors are because of using the unlicensed version of the library in my project.
Can any one tell me please what is the problem exactly?
Thank you in advance.
Because there are a lot of classes ,which are not in jar, in example project. In the example, they create a lot of classes by extends another classes from jar. I used this jar before.
I found what was the problem. I increased priority of the jar file in eclipse. Now it works.
I am trying to use Google's URL Shortening service in my Android app. I have imported the necessary jar files as mentioned here
I am following this as my reference to code from.
I am able to import the HTTPTransport class from com.google.api.client.http, but I am not able to import the GoogleTransport, GoogleHeaders, JsonHttpParser, nor Result, and JsonHttpContent doesn't seem to have the no-arg constructor given in the example I'm looking at.
Below is a screenshot of my project properties window, on the Libraries tab.
Copy all your jar files in your project libs folder. And remove these jars from Build Path Libraries as showing in image.
It turns out that you can use the Google Plugin for Eclipse to add an API to an Android project, as detailed here. Unfortunately, I still have the problem that I can't use the classes in any example I have found thus far. I guess I must just be using the library wrong.
I have seen this question, and have some more doubts regarding creating a jar file which I can distribute and can be used in any android applications.
What my requirement is
As I said, I want to build and distribute a closed source library. I
don't want the source code to be visible.
In that library I don't want to use any assets, layouts, resources
etc. But I want to use some android specific codes, like getting
android device id.
The most popular answer in the above linked SO question tells to create a regular java project and import android.jar in it. I tried to do that, but I don't know how to add android.jar to any java project. I would like to get some clarification on that too.
Moreover I would like to know if there are any other methods using android sdk itself (without using java project) create a closed source library jar file.
I think what I want is possible, since google analytics for android native apps seems to have done it. I am sure in the .jar file they distribute they are using android specific codes, since there seems no other way for them to get the device information to display in the analytics viewer.
EDIT : CAN SOMEONE CLARIFY THIS??
I think I have made some progress. This is what I have done
Created a regular android project (not library project, the "is
Library" checkmark is unchecked)
In the project I have coded out my logic. It uses some android
specific classes like SharedPreference, UUID, PackageManager. But
nothing related with assets, layouts also no class extending
Activity. Just a java class extending java.lang.object
Exported the project using Project->rightclick->export->Java->JAR
file. In the next screen I unchecked the checkbox near
AndroidManifest.xml. Set a destination directory to export and
clicked next thrice with keeping the default settings. Then I clicked
Finish, and got a lovely libMyLibraryName.jar at my desktop.
Then I created another android project, added this libMyLibraryName.jar to new project using project->rightclick->properties->java build path -> libraries->add external jar.
And I tried to use my class in the library, in my new project
MyLibraryClass objClass = new MyLibraryClass(this);
And I was able to compile and run successfully. I even sent the library to one of my co worker who was able to use the library in his on machine (Just making sure library project in my workspace wont influence the project using it).
Now I have 2 questions.
1) My first question is , what they meant by the term "true library" in the below given documentation ? Is it any non android java project which can be exported to a JAR file?
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.
Well this portion is taken from documentation under title "Library Projects".
2) My second question is, anything wrong with the way I have created the JAR file? Any possible pitfalls which might bite me back later? I would like to make sure I am not doing something terribly wrong, before using it in my important projects.
I might add that I didn't try the method of creating a JAVA project and importing android.jar. I am ready to try that one, if what I have done currently is wrong.
The android.jar will be located where you installed your Android SDK. Under the platforms directory there should be a number of other directories named android-<version>. The android.jar will be there. Choose the one specific to the minimum android version you are targeting.
Once you have that, copy it into your project. If you're using eclipse I think you can just cut and paste jars straight into your project, right click and add it to build path. If you're not using eclipse or any other IDE, you just need to ensure that the android.jar is on the classpath when building your jar file.
After that your newly built android library can be dropped into any Android project.
In answer to your additional questions:
What they mean by a true library is a jar file as opposed to an Android library project.
I don't think there's anything wrong with the way you created the jar file. I would have made it using the android.jar as I mentioned above but your way should also work. To verify this I would examine the jar contents and make sure all you have in there is .class files.
With all the new hype surrounding native extension support in AIR 3, I haven't found a single thing that confirms or denies it is possible to include and use an external JAR inside the native Android implementation.
All of the examples basically showcase the ability to hook into the built-in Android APIs. But what if someone wants to use one of hundreds of libraries that make it easier? Certainly it seems like this should be possible. I'll try to outline what I've done and maybe someone will spot a flaw:
Successfully created native Android library, using compiled-in imports from 3rd party Android library XYZ.
Exported Android project as JAR file.
Note: The referenced 3rd party JAR is in /lib inside the jar.
Successfully created ActionScript library (SWC) to interface with native Android library.
Created ANE package from SWC, extension.xml, Android JAR, and library.swc (for platform Android-ARM, extracted from SWC).
Note: Have also tried putting the 3rd party library in file structure outlined here: http://help.adobe.com/en_US/air/extensions/WSf268776665d7970d-24823354 12ffea65006-8000.html#WSf268776665d7970d-6be13ace1308aaebeca-7fff. I think this is more geared to runtime type execution with JNI or whatever, so that article has left me a little confused.
Used ANE in example Flex Mobile project.
Built and installed APK file on test DroidX device.
Can successfully see AIR application loading (and trace statements) in LogCat "ActivityManager: Displayed com.me.androidapp/.AppEntry"
Can successfully see native Android Java code being invoked via runtime by AIR app to instantiate extension & context. "mye_native: MyExtension.initialize", "mye_native: MyExtensionContext.createContext"
As soon as AIR app tries to call native function, it blows up, not able to find the classes from 3rd party Android library: E dalvikvm: Could not find class 'com.thirdparty.SomeClass', referenced from method com.me.nativeExtentions.MyExtensionFunction.call
Any ideas? It seems like it should work this way.
One thing I have noticed is that when I blow apart the APK and Dex from a pure Java Android app of mine (that also has 3rd party android libraries), it appears that the classes from the 3rd party have been included inside it (not just a jar reference).
When I do the same thing with my Flex APK, I find only my own Java classes plus Adobe's, and the 3rd party ones are nowhere to be found that I can see.
I posted this on the Adobe forums, but I thought I'd give the SO think-tank a try. Thank you.
You have to combine all your jars into one. Something like http://code.google.com/p/jarjar/ or your own Ant script will help.
Edited to add example:
Suppose your main extension jar file is extension.jar and you are using code in external.jar. Then you can put the classes from external.jar into extension.jar using the Java jar tool:
jar -xf external.jar
This will extract the .class files into package folders. If the top-level package is "com", then you can add those to extension.jar with:
jar -uf extension.jar com
(Repeat the second command for each top-level package in the external jar.)
You could also combine the library jars manually by turning them into zip-files (just rename them to .zip) and copy the classes from the 3rd party library into the main one and rename that one back to .jar
I have a basic Android project created in Eclipse Indigo. I have a third-party library on my build path, and it is called is used when I instantiate a class from that library in my initial activity.
Although the app build just fine, I encounter the following error:
10-02 19:51:17.311: ERROR/AndroidRuntime(314): java.lang.NoSuchMethodError: org.apache.http.conn.scheme.Scheme.<init>
Earlier in logcat, I do observe the following error message:
10-02 19:50:48.670: DEBUG/dalvikvm(295): DexOpt: not verifying 'Lorg/apache/http/conn/scheme/Scheme;': multiple definitions
This class is included in the third-party JAR; is it used by Android somehow/somewhere to suggest a conflict or other source of "multiple definitions?"
Thanks!
How does one reconcile the conflict - do I have crack open the third-party JAR and exclude the conflicting files?
My guess is that this would not help, though you can certainly try it. Somebody would appear to be trying to call a method on Scheme that perhaps exists in the JAR's own private copy of that class but is not in the Android SDK.
If the third-party JAR in question is Apache HttpClient, simply don't put that JAR in your build path, as HttpClient is already part of Android, and stick to methods that are in the SDK. If the third-party JAR is not Apache HttpClient, I suspect that once you remove their duplicate org.apache.http classes, that something else will break that depended on their own private version of those classes. If that is the case, you should probably take it up with the third-party developer directly, to work with them on Android support for their JAR. You might be able to use tools like jarjar to get past this, but I would not count on it.
You can try something like jarjar, it can break open the jars and rename the packages to a different path at build time. This avoids conflicts like the ones you're having. I'm just not sure it will work with Android.