All clear! Thank you all! So it is impossible to set
"android.uid.system" in a normal SDK app running in a standard Android
distribution.

On 16 Gen, 06:19, Bob Kerns <r...@acm.org> wrote:
> Either ---
>
> * Build the entire platform yourself, with your own key, and install
> the platform, including your app
>
> * Using advanced industrial espionage techniques, locate the private
> key, develop the appropriate intel, put together a black team to
> extract the hardware key vault on which it is stored, and kidnap the
> family of whoever holds the password to the key vault, and use the key
> vault hardware to sign it.
>
> * Build a quantum computer capable of reverse-engineering the private
> key from the signed platform files, develop the suitable algorithms,
> wait for them to give you the private key, and sign your application
> with it.
>
> You might get lucky -- the private key might be stored less securely,
> and you might not need to capture the hardware, just the data and the
> employee's family.
>
> More seriously: Not having the private key (either because it's
> someone else's, or more commonly, it's yours and you lost it!) means
> you simply *cannot* duplicate the signature of someone who *does* (or
> *did*) have the key. That's the basic premise and guarantee of public
> key cryptography.
>
> You do seem to realize that, when you ask "Do the platform key and
> certificate change from vendor to another".  But it would really
> defeat that basic premise if there were a singlesharedsigning key --
> and every vendor would be at risk for every other vendor losing track
> of the signing key, or misusing it, or allowing it to be misused.
>
> Speaking generally -- if you DO need to delegate signing authority,
> the way you handle that is by requiring that it be signed by a key
> whose corresponding public certificate has been signed by the suitable
> trusted Certificate Authority, and can be revoked by that CA. That
> would be how you'd do it, if only Google-approved builders could
> create builds, but that's not the case here. This is an open-source
> project. So I conclude it must not be set up that way (though
> requiring a Google-signed key would be one way to limit access to the
> Market).
>
> Another way to look at this is, all this signing stuff exists
> precisely to *prevent* you from doing what you're trying to do.
>
> On Jan 13, 9:21 am, Lassarin <zalb...@hotmail.it> wrote:
>
>
>
>
>
>
>
> > Hi all,
>
> > If I add in the AndroidManifest.xml the line
> > "android:sharedUserId="android.uid.system"", I can't install the
> > application neither on the emulator nor on my device (Acer Liquid E)
> > where i get (using the command "adb install") the error...
>
> > Failure [INSTALL_FAILED_SHARED_USER_INCOMPATIBLE]
>
> > On the web I found that it is connected with the certificate which
> > should be a "platform" certificate. However it is not clear how to
> > sign an unsignet apk with the correct "platform" key and certificate,
> > so do some of you know (and tried successfully) the correct procedure
> > to sign an apk with the platform key??? Do the platform key and
> > certificate change from vendor to another?
>
> > On my device, which is already rooted, it is installed the standard
> > distribution of Android (v2.2).
>
> > In alternative is there some way to install and run an application
> > with "android.uid.system" line in the Manifest??

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to