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, October 2, 2012 3:31:58 PM UTC-4, Kristopher Micinski wrote: > > 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 like you might want a single app, > and not a collection of plugins. > > kris > > On Tue, Oct 2, 2012 at 3:00 PM, Lindley <[email protected] <javascript:>> > wrote: > > 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. > > AbstractPlugin is an interface, and PluginFactory does what is necessary > to > > set up a DexClassLoader and instantiate by reflection a class from Impl > > which implements that interface. Main uses the resulting AbstractPlugin > in > > some way. > > > > Therefore, the compile-time dependencies are Main -> Plugin and Impl -> > > Plugin. There is no compile time dependency between Main and Impl, since > the > > class in Impl is instantiated by reflection. Therefore, when the > Main.apk is > > built, classes from Plugin are included but classes from Impl are not. > > > > The problem is then how to get those dex'd classes in Impl into the > phone in > > a place where DexClassLoader can get at them. > > > > There are two options. First, Impl can be built as an Android library, > then > > the resulting classes.jar can be manually dex'd with dx, and then the > > resulting classes-dex.jar can be pushed into some predetermined > directory on > > the phone. This works, but I am not entirely thrilled with it. For one > > thing, it prevents Impl from having any resources of its own, only Java > > code. > > > > Second, Impl can be built as an apk which just happens to contain > neither a > > service nor an activity. This can be installed normally, and then > > PluginFactory can get the path to the apk from the PackageManager to > pass it > > to DexClassLoader. The problem with this approach is that in each > > configuration I have tried so far, Impl.apk ends up pulling in the > classes > > from Plugin as well since there is a compile time dependency. Therefore > when > > DexClassLoader tries to resolve something, it realizes there are now two > > different AbstractPlugin implementations in the system (which are really > the > > same one in two different apks), and bails out. What I would like to do > is > > keep Plugin on the classpath during the build of Impl, but exclude its > > classes from the apk. Is there a way to set this up either in Eclipse or > in > > Ant directly? (What about in maven?) > > > > This does not necessarily solve the resource problem since the active > > Context in Main would not necessarily know about the resources in Impl > if it > > had any, but it would be a start. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to > > [email protected]<javascript:> > > To unsubscribe from this group, send email to > > [email protected] <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
