> 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.
Common *signers*, not *signatures*. But, yes. If I recall correctly — and I'm not sure I do; verify this — the ability of APKs to have multiple signatures was considered a bug and fixed a year or so ago. > This could be achieved by sharing > the applications signing key with the contributors, but this has > serious implications, and should not be done. Actually, the implications of allowing other developers to sign APKs with your signing key are no more serious than allowing other developers to run their APKs as your UID. Either way, they own you and your users' data. (Assuming you use a distinct key for this app, that is. If you signed all your apps with the same key, and let other people use your key, that'd be worse. So don't do that, either.) In any case, sharing keys is trouble, and multiply-signing APKs is at least not guaranteed to work and probably does not work anymore. The solution you want is IPC. In your case, I'd have the outside developers adhere to an AIDL interface definition, and then create some mechanism for other APKs to register with your app. Then you can call them as remote objects. http://developer.android.com/guide/developing/tools/aidl.html > 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 You could do that too, instead of IPC (if you can read their Dex files) or as an alternative to explicit class registration. But I wouldn't do it. > 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. If you can read the bytes, you can load 'em. But that doesn't mean it's a good idea — now you're allowing outside developers to run as your UID without even having to first share your key! Use IPC. -- http://noncombatant.org/ "These days, though, you have to be pretty technical before you can even aspire to crudeness." — William Gibson -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to android-security-discuss@googlegroups.com. To unsubscribe from this group, send email to android-security-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
