I'm aware of the security concerns.
Anyway, I've gotten it working in Eclipse by removing the project
dependency under Reference on the Android tab of the project properties,
and just setting that the project is required in the Java Build Path tab
(not exported).
However, even though Eclipse
You'll have to tell us more about your build process.
Generally I simply stick them in libs/ or do something more elaborate
with custom rules.
I'm honestly not seeing what your problem is, and still not seeing why
you need a class loader, in my experience if you can do things
statically it's
It's kind of complicated and there are inter-team political considerations.
This seems to be the cleanest solution we've hit upon so far. Whether or
not it's the right solution in the long run we don't know yet, but that
isn't what I'm asking about. I just want help with the mechanics of the
I am using Eclipse with the ADT plugin, as well as ant.
I am trying to design a plug-in architecture. I have three projects, call
them Main, Plugin, and Impl. Main builds a service apk, Plugin is an
Android Library. Plugin just defines two classes, AbstractPlugin and
PluginFactory.
So instead of doing this (ClassLoaders being bad...), I would use an
AIDL service stub for the methods you needed...
Alternatively, I would suggest you look at using an Android library
project, if you can statically link.
What kinds of things do you need.
Multiple functional looks very much
For a variety of reasons, most notably because the plug-in portion is not
supposed to be Android-specific, I don't want to use AIDL here.
Static linking is a fallback option. I don't like it but I'll do it if
that's the only way. There really ought to be a cleaner fix for this.
On Tuesday,
I'll give a little more detail. The Impl class is supposed to be one of
several pure-java implementations of the service in Main that I might drop
in. The purpose of Main is to abstract all Android-specific code away from
this implementation. In particular, the service in Main *already* has an
So wait, I'm not clear, why can't this be statically linked, and why
is this a plugin type architecture..
It seems like you're trying to get code reuse, but still, I'm not sure
why something like a ClassLoader is required from. From where will
the classes be loaded?
kris
On Tue, Oct 2, 2012 at
I would prefer not to make it statically linked because I am not the one
writing the plugins. Each plugin is potentially going to be on a different
branch of a repository, and I would like to code to continue working
without undue hardship when I switch branches. Different versions of the
On Tue, Oct 2, 2012 at 4:45 PM, Lindley lindl...@gmail.com wrote:
I would prefer not to make it statically linked because I am not the one
writing the plugins. Each plugin is potentially going to be on a different
branch of a repository, and I would like to code to continue working without
10 matches
Mail list logo
