Android Enthusiasts Stack Exchange is a question and answer site for enthusiasts and power users of the Android operating system. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Are the gapps (e.g. from signed in a way that prevents tampering? Is there a way to verify they're the same as you'd get from Google?

Do all / most ROMs check for this?

share|improve this question
up vote 0 down vote accepted

As Michael Hampton's helpful answer says, all android apps are signed. This means:

  • the android system will ensure that every app it tries to run has been signed by someone.
  • When android updates an app, the new app must be signed by the same key that signed the original app. Otherwise, the upgrade will fail. If the key changes, the name of the app must also change.

All of this does not mean that a recovery console like TeamWin or ClockworkMod recovery will properly check the signatures of these keys, nor does it mean that a rom is from Google just because someone signed it properly.

Do common roms check the signatures on zip files? Yes, they do

  • Fortunately, it appears that TeamWin recovery does check. If I understand it correctly, the source code (here are the installation and verification portions) of TeamWin recovery checks that a zip file in its entirety has been signed by using a private key that corresponds to one of the public keys in /res/keys. It does this if told to verify the signature of a signed zip file, which is different from checking the md5 checksum of the file. In my version (v2.7.0.0) I can see a "Zip file signature verification" option on the install screen, which I assume turns this functionality on.

  • ClockworkMod recovery also checks zip file signatures. The source code (see the installer code and the verification code) behaves very similarly to that of TeamWin: a zip file will count as verified if it is signed with a private key whose public "other half" lives in /res/keys

Can we be sure that the apps came from google because of this signing? Probably Not!

  • It appears from this blog entry and this paper that most recovery roms have at least one key in /res/keys whose private version is publicly known (that's my inference based on what the links say and my knowledge of what the rom verification code does). This means that the validity checks are essentially worthless, since any key in /res/keys can be used to sign.
share|improve this answer

All Android apps are signed.

Android will not run an unsigned app. In addition, the signatures are tied to the app permissions, such that if the signature was wrong, other apps would not be able to talk with it, and you would not be able to receive updates to it from Google Play.

Android signing is discussed in more depth in Signing Your Applications in the Android developer documentation, from which the above information was drawn.

If you are paranoid and want to verify an app's signature, you can use the jarsigner utility included with the Java Development Kit (JDK). For example:

jarsigner -verify -verbose -certs Vending.apk
share|improve this answer
the page you reference says "Android uses this certificate to identify the author of an app, and the certificate does not need to be signed by a certificate authority. Android apps often use self-signed certificates." Doesn't this mean that, while android will verify that the app is signed, it will not care WHO signed it? That would mean that we have no protection against a malicious app unless we somehow check that the gapps we received are signed by Google. This answer seems to be glossing over some VERY necessary checking steps. Am I missing something? – stochastic Jan 24 '15 at 0:01
@stochastic As the page also mentions, updates must be signed with exactly the same key or Android will refuse to install the update. It doesn't matter that the key wasn't signed by a CA, just that it's the same as the one originally used to sign the app. – Michael Hampton Jan 24 '15 at 4:06
Thanks for pointing that out! Doesn't this still presume, though, that there is an existing app with the same name? When installing through, say, Google Play, that is fine, but when installing a zip file of gapps via a recovery rom it's entirely possible that the gapps are simply not present yet (which is why they are being installed in this way), so wouldn't there be a real vulnerability if we don't do some kind of key checking manually? Also, while the android system does the checking you describe, does that mean that a recovery rom will perform the same checking? – stochastic Jan 24 '15 at 15:45
  • If you got your gapps from, you could manually check if the MD5sum of the .zip file you downloaded is correct. This would assure you that the file has not been tampered with.

  • If flashing through ClockworkMod Recovery, there is this option: install zip from sdcard > toggle signature verification.

share|improve this answer
I don't think zip signature verification will check that the apps (or other contents) inside the zip are signed, though; it only checks that the zip file itself is signed. Similarly, checking the md5 of the zip doesn't really prove anything about the apps it contains unless you create your own flashable zip with known good copies of the same versions of the same apps and then md5 them both (but then why would you download it? You'd already have your own flashable version) – eldarerathis Feb 10 '13 at 15:54

While signatures for APK files are checked, it appears that system apps (= apps installed to /system/) have more relaxed checks. This allows inclusion of additional files in an APK file and still pass the verification checks.

I have posted the details on this page, the essence is that the validation code in (part of platform_frameworks_base) only checks files listed in the manifest file against the certificate in the APK file. Other files bypass the validation.

The Nexus factory images include Google Apps without the special classes.dex file (instead they have an "optimized" .odex file in a subdirectory next to the .apk file). This means that anyone could create an APK containing a classes.dex file that is in fact malicious. Be careful with files from untrusted sources!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.