This question already has answers here:
The apk must be signed with the same certificates as the previous version
(15 answers)
Closed 9 years ago.
I unconsciously deleted the apk file from my app and now I wanted to put a new version on the market. The error message is always this:
You uploaded an APK that is signed with a different certificate to your previous APKs. You must use the same certificate. Your existing APKs are signed with the certificate(s) with fingerprint(s):
and then goes a lot of numbers and letters. I know the password that I used to create the firsk apk.
This is probably a duplicate question, but I will still sum this up for you:
When you are creating APK, you use a keystore file containing a certificate to sign it.
Then, when you want to issue and update, certificates in old and new version must match, otherwise the system does not allow you to install it.
You most probably created this keystore file when you first generated the APK and then just forgot about it, so it is possible it is still sitting comfortably somewhere on your harddrive. You should look for it first :)
(They are quite small, 1-2kB, and every IDE has default path where to save them, so try creating a new one, see where it got saved and look if there isn't another similar file)
If you can't find it, it's time to panic. You are pretty much screwed if you want to issue and update. So, lesson number one:
Always backup your keystore files.
(I still do not understand why this is not shown as some big red flashy box during the APK upload dialog on Google Play :D)
So how to deal with this? You can change your package name, create new keystore, back it up, generate APK, unpublish your old app, publish new APK with same name and info.
Good luck with this. This almost made my hair gray this summer, so hope it won't happen to you :)
Related
Background
I want to check if 2 APK files are identical (or have a very high chance of being identical) in the minimal work on the device.
The reason for this, is that I have an app (here) that allows to install apps using APK files, so I want to check if the installed app is already the same as the APK file. This includes using root privilege for background install. So far, what I did was to check the package name and the version code, but I want to know if there is a little better way to perform this check.
The problem
By "minimal work", I mean minimal reads of the APK file itself. This means that going through all of the bytes of each of the APK files is the most correct way to check if files are identical, but if there is a signature for the APK, that identifies it relatively uniquely, that would be much better.
For example, I know you can do MD5 check on both files, and if it's the same for both, it's a really good chance both are the same, but such an algorithm, along with other similar algorithms (sha1 etc...), go over the entire file, so this is about the same as what I wrote before. It could take a while for large APK files.
What I've found
What I do know is that comparing the package name and the version number gives a clue about whether the APK files are of the same app and version, but I think that Android-Studio knows more about the APK files, because sometimes it asks if we want to uninstall the installed app even though they have the same version, and it doesn't seem like it takes it a lot of time to ask this.
I could add a file size check too, which should be relatively as fast as the package name and the version number, but maybe there is more ...
Here's a sample code of what I did:
public static boolean areApksMostProbablyIdentical(PackageInfo packageInfo, PackageInfo packageInfo2) {
if (packageInfo == null || packageInfo2 == null)
return packageInfo == packageInfo2;
if (!packageInfo.packageName.equals(packageInfo2.packageName))
return false;
if (packageInfo.versionCode != packageInfo2.versionCode)
return false;
final File file = new File(packageInfo.applicationInfo.publicSourceDir);
final File file2 = new File(packageInfo2.applicationInfo.publicSourceDir);
if (file.exists() && file2.exists())
return file.length() == file2.length();
return true;
}
The question
My question is:
Is it possible to perform a "good-enough" check on both files, avoiding comparing all bytes, to see if 2 APK files are the same?
What I do know is that comparing the package name and the version number gives a clue about whether the APK files are of the same app and version,
No it does not. All it tells that both packages used the same values. Anything but that is just pure assumption.
but I think that Android-Studio knows more about the APK files, because sometimes it asks if we want to uninstall the installed app even though they have the same version, and it doesn't seem like it takes it a lot of time to ask this.
Wow :) All AS knows about APK is in APK. There's no magic. Yet, not sure how you managed to reach your 50K (mostly android based) reputation score and still act like you never heard about the APK signing and all the certificate system used on Android. What usually triggers such uninstallation request dialog to popup is ordinary certificate mismatch, usually release vs debug one.
Is it possible to perform a "good-enough" check on both files, avoiding comparing all bytes, to see if 2 APK files are the same?
Once you define what good-enough and the same really means for you in this then perhaps, but by using common means of phrases I'd say no.
EDIT
The reason for this, is that I have an app (here) that allows to install apps using APK files, so I want to check if the installed app is already the same as the APK file
Then all you need to check if your installed app and the APK files are signed using the same certificate and are using the same packageId. If not, this is different app. If this matches, then I'd compare versionCode - if the same -> this is the same app. If higler/lower it's downgrade/upgrade. Sure, one can still release different APKs with the same versionCode and try to sideload it but I'd say it's not your problem to solve (that's the reason Google Play Store enforects versionCode bump on each update). Optionally, if you really got too much spare time you could compare APK file sizes.
I recently asked myself why in android we have to first sign and then zipalign the apk. I searched for some background information, how those processes are technically working in detail. I'm still a little bit unhappy, cause those description do not really technically explain why this sequence is necessary.
But lets start from the beginning:
I know the fact that in the apk-build-process following order is necessary
a lot of prior steps...
creating the apk-file
signing the apk-file (modifies apk)
zipaligning the apk-file (modifies apk)
I found some information here:
zipalign
So it is clear that zipalign will align internals to 4-byte-boundaries, so that all can be loaded with mmap.
It seems that a Signing- process would destroy this alignment. Therefore zipaligning has to be called at the end of the process after signing.
But why is it possible to make a re-aligning of the apk-content, without destroying the signature of the apk!?
the apk gets modified and the signature should not be valid after a modified apk, i thought...
Maybe someone has more technically background information than I did found here:
Signing your application
Thanks, if anyone has some helpful, more technically detailed information.
Luke
The digital signature of the APK is performed by hashing the APK components. As such, you are protecting the contents of the individual files, and not their position in memory. In other words, the APK contents are signed, but not the APK itself as a single file. As you correctly state, zipalign is merely padding the files in the APK so they start on an aligned boundary, to mmap(2) more efficiently (and be able to discard files easily). The contents, however, do not change, and therefore the signature is not violated.
I exported application for the first time and I'm a little bit confused about keystore.
I want to use one keystore for all next apps. So in Eclipse I will make new keystore but what to put in Alias? Can I put there app name or what? Because I want make universal keystore for all kinds of apps. Can I will put different Alias in my next app? Or will be better to put in alias my first and last name?
Is keystore visible when someone decompile your app?
Thanks for little explanation about keystores.
The keystore is simply a file format designed to contain one or more keys, a.k.a. certificates. It doesn't matter whether you keep all your keys in a one keyfile, and it doesn't matter what you name the keyfiles or the key aliases. Nothing but the actual content of the key itself has any affect whatsoever on your app.
The keystore does not normally become part of the app, and you should make sure not to put it in your /res folder or anywhere else where it might end up getting compiled into the APK. In fact, it's probably a good idea to keep it outside the project directory entirely. Most of the strength of the key is in the practical impossibility of guessing or regenerating its contents. If someone acquires a copy of your keystore, the only thing stopping them from publishing bogus versions of your app is whatever password you put on it.
If you want to split hairs, the docs are wrong. The certificate does not identify the author of the app. It only proves that the app was signed by someone who was in possession of your key. Protect your keystores!
If you want to have one keystore file for all the apps then you cannot change the alias name. It is asked during creating the keystore file.
Next time whenever you compile and build the apk file you have to use the existing keystore file.
Hope you understood.
I'm updating my app and I just wanted to know if the apk needs to be named the same as the original one that I uploaded. I'm pretty sure the answer is 'No', but just wanted to check as I can't find an explicit answer anywhere.
The only things that must match the original app are the package name and the signing keystore. Other than that, you can change anything you want, including the name of the apk file (Google Play will rename it on its servers anyways).
You will also need to increment the version code (the version name may stay the same)
As far as I know the key and the package name in your manifest should be same for each update , apk name should not matter.
I'm not familiar with the idea of signing files, and I can't find a satisfactory answer so far, so I think I'd better ask:
What I want to know is when signing a binary file (for Android), does the signing tool assign some sort of checksum to the file so that when a hacker changed something in the apk file, the program would refuse to start because the checksum doesn't match. Does this mechanism exist in Android's signing tool?
Well, I understand when a hacker has the binary, he can disable anything he wants, including the checksum check. But the question is: Does Android's signing tool provide this level or protection in the first place?
Thank you for reading, and answering!
The answers that say "no, they can't modify your apk" are only about halfway right: Yes, no one can modify your code and resign it with your key, meaning the malicious cracker can't make the modified app look like it actually came from you. But that doesn't mean they can't modify and run the APK after resigning it with a different key.
They could take your signed APK, modify its code, and resign it themselves with their own key; they couldn't issue that app as an update or anything like that, but the modified self-signed APK would normally be installable by any user, root or not.
EDIT: Worth crawling around xda-developers to see what people are doing in that respect (some semi-legitimate, like modifying and reissuing theme APKs; other much less so). Tools like android-apktool are particularly interesting.
Also see these SO questions:
Can I re-sign an .apk with a different certificate than what it came with?
is it even possible to modify .apk, by adding additional class to .dex and re-packing with modified manifest.xml?
Android binary signing is accomplished using the Jarsigner tool, part of the standard Java SDK. Signing a jar with this tool simply adds two files; one that contains the hashed values for each file within the jar/application (the signature or .sf file), and one that verifies the signature file and identifies the signing certificate (DSA file).
So checking the signature would, yes, necessarily involve checking whether the hashes of the binary file match the provided value, which would detect any changes to the binary. And yes, the Android documentation says that the system will not install or run an application without a valid signature.
So yes, you can assume that signing your file properly will prevent it from running after being altered.
Yes, the OS must check that the content of the binary actually matches up to the signature. It would be worthless otherwise - someone could just take a signature from a legitimate application and stick it on to any other binary.