Directory tree of a typical Android project (at least those created by the "android create project" command) looks like this:
As you may have seen the directory structure of countless J2SE projects, there is a directory to store the 3rd party class libraries of the project. Under the "lib" directory, you can place your Java class libraries in JAR format and they will be added to the classpath when the Android application is running.
Or will they? If you remember the APK format, there is no such thing as directory for libs in JAR format, particularly because the Dalvik VM is simply not able to execute ordinary Java class files in those JARs. You can find JARs on the device but these JARs contain class files in DEX format (Dalvik VM's class file format) inside so the extension of these files is misleading. Then where are those JARs from the lib directory that we "added to the classpath"?
You might have guessed it: these JARs are unpacked, processed by the dx tool just like the classes under the src directory and are placed into the same classes.dex file where the application resides. One application is one DEX file and JARs containing Java class files are not "added to the classpath", they are converted into DEX format and added to the DEX file of the application. Unlike in OSGi, an Android installable package cannot share code with other system components, only services.
Wednesday, January 20, 2010
Subscribe to:
Post Comments (Atom)
6 comments:
Hi
Its really nice to see the post.
I am also a newbie to the android Programming
i had some issue related to adding third party jars to android.
i have explained the issue in my blog
http://blogs.siliconindia.com/vinayGuntaka
if u dnt mind pls slove my issue i need u r help
sorry for navigating to my blog pls help me from this issue
In my blog i have explained the entire process that i did
waiting for u reply....!
Thanks
Vinay Guntaka
So this Drools thingy generates .class files on the fly?
You have to convert them off-device with dx.
All the dynamic languages (e.g. Ruby) has this problem. You have to examine whether that library really generates bytecode on the fly or whether it generates some bytecode first from some description that it does not modify later. In the latter case you just add those generated files to the .class files and let dx incorporate those into the .dex file. In the former case there is no solution.
Hi Gabor,
Thanks for posting reply,
Is there any other way to implement this drools in android
pls give me your valuable suggestions,
at any cost i have to complete this issue.
and i am trying this from last one month.
R & D : Done in last 3 days
if i am able to convert the user-defined object (which is stored in a .txt file) to .dex file than i can
implement (upto my Knowledge).
if this issue is solved then we are first to implement.
pls need u r suggestions....!
waiting for u r reply
Thanks
Vinay Guntaka
hi vinay
were you able to run drools on android ? I am in the same boat, and stuck :)
I'm also very interested in the integration of DROOLS and Android. Has anyone found a way to integrate the two?
-matt
profversaggi@gmail.com
I've run across the work of a very bright man in the UK who did it as part of an integrated systems he was working on ... and I got his code working up to the point where it died loading the DRL rules.
I think this might shed some light on things but it's fast getting into true software engineering and I'm just not there yet ....
Here is his codebase:
https://github.com/cgreenhalgh/droolstest
Post a Comment