views:

89

answers:

2

I want to add a non-native shared library to Android so every application on the device would be able to use it. I mean using packaged classes just like a core library as if they were present in the application itself.

I studied Android source code to figure out a way to add a new path to the application ClassLoader and found out that it is created during startup and there's no way to change the paths later. I can use my own ClassLoader, but all I will get after loading a class will be a reference to a Class object. This way I will be bound to work through reflection mechanism, which is slower than the native execution system.

Is there any way to organise a shared library on Android?

Update: just to be clear here, I don't need interaction between applications. I need classes which I can reuse in any application. Also static libraries don't really suit my needs because this will bloat the applications.

A: 

Even if you get a Class object, the security model (binder) on Android will prohibit applications from reading into another application's directory.

The best you can do on a non-root phone is to create libraries via Intents.

Yann Ramin
Maybe I didn't explain properly, but I need to create classes from the library. Intents have nothing to do with what I want because I don't need interaction between applications. I need reusable classes.
Malcolm
A: 

For static libraries of reusable classes you can use library projects. For dynamically interacting with other applications securely you can bind to a service.

adamp
If I use static libraries, this means that I'll have to shove the same code into every single application, which is exactly what I'm trying to avoid. And I'm definitely not interested in interaction betweeen applications.
Malcolm
What problem are you trying to solve? Are you concerned about storage space for multiple apps using common code? (And if so, is this a premature optimization?) How many apps do you expect will use it? How do you plan to deploy this shared library? Do you want to make it available to 3rd parties? Do you want centralized updating of common components? What if an update to the library breaks older apps? What about security?
adamp
I'm planning to write a tool to convert Java ME applications to APK, but to do that I need all the libraries present in the platform, in my case - JSRs defined by MSA and probably even more. So if I just insert all the code into the applications, this will make them much bigger than they should be. I could offset this by killing dead code, but this would complicate my app. And how many apps do I expect to create this way - well, as many as my users will want to. So the less excessive code I add the better.
Malcolm
I see. Eliminating dead code as part of your build process using a tool like proguard and including the necessary libraries statically is probably going to be your best bet. (What do you mean by "complicate your app?") Android does not offer first-class support for what you want at this time.
adamp
Yeah, I also think that I'll have to port ProGuard to Android and use it as a part of my app in that case. And this is what I meant by complicating the app. Actually Android really diappoints me with the lack of dynamic libraries support, even MIDP 3.0 can do that, not to mention other platforms. And they could implement this very easily by allowing to adjust classpath just like it is possible in Java. Okay, I mark your answer as an accepted answer, thanks for the comments. ;) Though if someone still figures out some hackish way to do it (say, like with Java SE), he's welcome. :)
Malcolm
You don't have to port proguard to Android, it runs on the host machine after compiling but before dexing.
adamp
Maybe I didn't explain this clearly, I'm writing my app for mobile devices running Android, not for PCs, that's why I'm so concerned about keeping my app lighter. So I will have to get ProGuard running on Android.
Malcolm
By the way, if I were writing for PC, then Java ME apps would have to be prepared for running on Android beforehand. And I want to have something like a normal JVM on Android, which supports at least MSA, probably even CDC or MIDP 3.0 on top of it. That would enable crossplatform programming, which is quite useful when there's a handful of variegated platforms.
Malcolm
Proguard does not run on the target Android device just like ant, javac, dx, or aapt does not run on the target device. Proguard runs at build time between compiling and dexing on your development machine, not at run time on the target Android device. By the time you have an apk ready to put on an Android device, proguard has already done its job and is out of the picture. As long as proguard can run on your development machine you're set.
adamp
I'm well aware that ProGuard is meant to run on JARs before converting them to APKs. But it will process JARs prepared by my app and only then they will be converted to APKs. Yes, my app for Android will include the dx tool, this was my intention from the beginning.
Malcolm