Have you thought about making the core of your application a shared library? I am not sure it would be possible with your specific application, and it would depend on what kind of contributions and changes you want to allow.
A common way to allow others to contribute is by being open source. Is there a reason this is not an option? One thing you might find very interesting is the way themes are implemented in ADW launcher. The content contributed is in a separate apk. You may look into this approach, but I am not sure it would be robust enough to meet your needs. The source code is out there and worth a read. It might be something that could be extended, but you'd have to look into that. I guess it all comes down to what exactly you are trying to accomplish. On Jun 25, 8:20 am, Nate <[email protected]> wrote: > After reading the documentation on shared UIDs and APK signing, I > concluded that using multiple signatures for an application I am > writing would be a good solution. First, I'll explain the problem I'm > attempting to solve, and next I'll explain how I imagined multiply > signed APKs would solve it. > > I'm writing an application that will allow users/developers to freely > contribute content to. The contributable content is functionality; > not simply images, sounds, data, or other resources. Let's say for > example, the content is an implementation of an interface that > contains a controller for an interactive character in a video game. > The users/developers should be able to package this content and > distribute, for money if they wish, on the Android Market, in the same > manner that the application itself was. > > By having the application and the content packages use the same > sharedUserId, the Java classes contained in the content packages are > available to be directly used by the application. However, in order > to be able to install two APKs wishing to use the same sharedUserId, > they must have common signatures. This could be achieved by sharing > the applications signing key with the contributors, but this has > serious implications, and should not be done. The logical thing to do > would be to sign the application with a truly private key, in addition > to a key that is publicly available to the contributors of the > application. The contributors would sign their packages with their > own private key, and the previously mentioned shared key. > > This solution, however, does not work in the current implementation. > Or at least I haven't managed to make it work. From my testing, and > likely soon to be confirmed by code inspection, the APKs can only > share a UID if and only if the sets of signatures are identical across > APKs. I'm curious, is this truly the case? If so, is the use case > above not enough to warrant the functionality sought? Finally, if the > solution presented will not work, may you suggest an alternative that > will? > > As an aside, an alternative I was brainstorming involved: > 1) getting the list of all installed packages > 2) checking for the existence of a class (or perhaps meta-data from > the manifest) (or some other suitable convention) > 3) creating a DexClassLoader for the packages that match > > I'm not sure of the security of this method; perhaps it's not possible > to use the DexClassLoader for packages for which you don't share > signatures. Perhaps no security exists at all, in which case I could > perform the signature check myself if I deemed it necessary. > > I appreciate any advice. Thanks in advance! > > -- > Nate -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" 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-security-discuss?hl=en.
