I'm having an error to generate the apk file in flutter
On debug mode it doens't happend
Execution failed for task ':app:validateSigningRelease'.
> Keystore file not set for signing config release
I doesn't know what to to
Someone can help?
first, if you have not set a sign key for release version, you should set a it for your release (see this). Otherwise if you have set it, You should check the informations in the key.properties file, eg. keyAlias, storeFile. If this file is not similar to your signature file, you will get this error.
I had uploaded my app to Google Play (back when it was called Android Market) some time ago.
Today I updated the app, but I had deleted the previous keystore and created a new one.
When uploading, it says the APK must be signed with the same certificates as the previous version:
Upload failed
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):
[ SHA1: 89:2F:11:FE:CE:D6:CC:DF:65:E7:76:3E:DD:A7:96:4F:84:DD:BA:33 ]
and the certificate(s) used to sign the APK you uploaded have fingerprint(s):
[ SHA1: 20:26:F4:C1:DF:0F:2B:D9:46:03:FF:AB:07:B1:28:7B:9C:75:44:CC ]
But I don't have this certificate, and don't want to delete and re-publish the application, because it has active users.
What can I do to sign my app with new certificate?
Nothing. Read the documentation: Publishing Updates on Android Market
Before uploading the updated application, be sure that you have incremented the android:versionCode and android:versionName attributes in the element of the manifest file. Also, the package name must be the same and the .apk must be signed with the same private key. If the package name and signing certificate do not match those of the existing version, Market will consider it a new application and will not offer it to users as an update.
Did you sign with the debug key by mistake?
Google Play does not allow you to publish an app signed with your debug keystore. If you try to upload such an APK, Google Play will fail with the message "You uploaded an APK that was signed in debug mode. You need to sign your APK in release mode."
However, if you try to upload an update which is signed with the debug keystore, you will not see this message; Google Play will display the message shown in the question, referring to SHA1 fingerprints.
So firstly, check whether you signed the app with your debug key by mistake.
How do I check which signing keys were used?
Gather the information from the APK
You can check which certificates the original APK and update APK were signed with by using these commands, using the Java keytool:
keytool -printcert -jarfile original.apk
keytool -printcert -jarfile update.apk
This shows you detailed information about the how an APK was signed, for example:
Owner: CN=My App, O=My Company, L=Somewhere, C=DE
Issuer: CN=My App, O=My Company, L=Somewhere, C=DE
Serial number: 4790b086
Valid from: Mon Nov 11 15:01:28 GMT 2013 until: Fri Mar 29 16:01:28 BST 2041
Certificate fingerprints:
MD5: A3:2E:67:AF:74:3A:BD:DD:A2:A9:0D:CA:6C:D4:AF:20
SHA1: A6:E7:CE:64:17:45:0F:B4:C7:FC:76:43:90:04:DC:A7:84:EF:33:E9
SHA256: FB:6C:59:9E:B4:58:E3:62:AD:81:42:...:09:FC:BC:FE:E7:40:53:C3:D8:14:4F
Signature algorithm name: SHA256withRSA
Version: 3
The important parts to note here — for each APK — are the SHA1 fingerprint value, the Owner identity value, and the Valid from/until dates.
If that keytool command doesn't work (the -jarfile option requires Java 7), you can get more basic information via the jarsigner command:
jarsigner -verify -verbose:summary -certs original.apk
jarsigner -verify -verbose:summary -certs update.apk
This unfortunately does not show the SHA1 fingerprint, but does show the X.509 owner identity, along with the certificate expiry dates. For example:
sm 4642892 Thu Apr 17 10:57:44 CEST 2014 classes.dex (and 412 more)
X.509, CN=My App, O=My Company, L=Somewhere, C=DE
[certificate is valid from 11/11/13 12:12 to 29/03/41 12:12]
[CertPath not validated: Path does not chain with any of the trust anchors]
You can ignore any "CertPath not validated" message, along with warnings about certificate chains or timestamps; they're not relevant in this case.
Compare the Owner, SHA1 and Expiry values between the APKs
If the Owner/X.509 identity value is CN=Android Debug, O=Android, C=US, then you have signed the APK with your debug key, not the original release key
If the SHA1 fingerprint value is different between the original and update APKs, then you did not use the same signing key for both APKs
If the Owner/X.509 identity values are different, or the certificate expiry dates differ between the two APKs, then you did not use the same signing key for both APKs
Note that even if the Owner/X.509 values are identical between the two certificates, this doesn't mean that the certificates are identical — if anything else does not match — such as the fingerprint values — then the certificates are different.
Search for the original keystore, check backups
If the two APKs have different certificate information, then you must find the original keystore, i.e. the file with the first SHA1 fingerprint value that Google Play (or keytool) told you.
Search through all the keystore files you can find on your computer, and in any backups you have, until you have the one with the correct SHA1 fingerprint:
keytool -list -keystore my-release.keystore
Just press Enter if prompted for the password — you don't necessarily have to enter it if you just want to quickly check the SHA1 value.
I can't find the original keystore anywhere
If you cannot find the original keystore, you will never be able to publish any updates to this particular app.
Android mentions this explicitly on the Signing Your Application page:
Warning: Keep your keystore and private key in a safe and secure place, and ensure that you have secure backups of them. If you publish an app to Google Play and then lose the key with which you signed your app, you will not be able to publish any updates to your app, since you must always sign all versions of your app with the same key.
After the first release of an APK, all subsequent releases must be signed with the exact same key.
Can I extract the original signing key from the original APK?
No. This is not possible. The APK only contains public information, and not your private key information.
Can I migrate to a new signing key?
No. Even if you do find the original, you can't sign an APK with key A, then sign the next update with both keys A and B, then sign the next update after that with only key B.
Signing an APK (or any JAR file) with multiple keys is technically possible, but Google Play no longer accepts APKs with multiple signatures.
Attempting to do so will result in the message "Your APK has been signed with multiple certificates. Please only sign it with one certificate and upload it again."
What can I do?
You will have to build your app with a new application ID (e.g. change from "com.example.myapp" to "com.example.myapp2") and create a brand new listing on Google Play.
Possibly you will also have to change your code so that people can install the new app even if they have the old app installed, e.g. you need to make sure that you don't have conflicting content providers.
You will lose your existing install base, reviews etc., and will have to find a way to get your existing customers to uninstall the old app and install the new version.
Again, ensure you have secure backups of the keystore and password(s) you use for this version.
Nothing - Google says it clearly that the application is identified by the keys used to sign it. Consequently if you've lost the keys, you need to create a new application.
I just had this occur out of the clear blue. I really do not think I changed anything.
However, Build => Clean Project fixed it.
Today i faced same issue, unfortunately, i was having two aliases in my keystore file.
Here i get the answer for that question . After searching for too long finally i get to crack the key and password for this . I forget my key and alias also the jks file but fortunately i know the bunch of password what i had put in it . but finding correct combinations for that was toughest task for me .
Solution -
Download this - Keytool IUI version 2.4.1 plugin
the window will pop up now it show the alias name ..if you jks file is correct ..
right click on alias and hit "view certificates chain "..
it will show the SHA1 Key .. match this key with tha key you get while you was uploading the apk in google app store ...
if it match then you are with the right jks file and alias ..
now lucky i have bunch of password to match ..
now go to this scrren put the same jks path .. and password(among the password you have ) put any path in "Certificate file"
if the screen shows any error then password is not matching .. if it doesn't show any error then it means you are with correct jks file . correct alias and password()
now with that you can upload your apk in play store :)
I highly recommend Keystore Explorer (https://keystore-explorer.org/) which lets you access your keystore without having to upload it to Google Play. This way you can troubleshoot whether you are entering your password incorrectly.
If you have previous apk file with you(backup) then use jarSigner to extract certificate from that that apk, then use that key or use keytool to clone that certificate, may be that will help...
Helpful links are jarsigner docs and keytool docs.
Please check your android/app/build.gradle file for
android{
...
buildTypes {
release {
// signingConfig signingConfigs.debug
signingConfig signingConfigs.release
}
}
...
}
before releasing the appbundle, It should have the signingConfig signingConfigs.release this line enabled instead of signingConfig signingConfigs.debug this line.
I made this silly mistake.
I was testing my updated app on other devices by releasing it with the debug sign in config and when I was ready to publish the update I didn't change the config and released the bundle which had the debug config.
After scratching my head for around an hour I realized that I had this debug config all the time then I changed it to release mode now the problem is solved.
I had faced this issue recently, after trying different ways to sign in like enable V1 Or V2, signed in by changing alias name and last come to know that I am using wrong key store file
You can use new feature Google play app signing to generate a new key file .
After May 2017 Google play store add a new feature on Play store and
It’s Good News For Android Developers.
From this feature, Developer can update their app or Apk who lost a KeyStore file.
you need to enable google play app signing on play store console.
https://support.google.com/googleplay/android-developer/answer/7384423?hl=en
http://www.geekcodehub.com/2018/05/23/keystore-lost-in-android/
My [silly] mistake was that i used app-debug.apk file instead of app-release.apk file.
You need to to choose "release" in "Build Variants" frame when you generate signed APK.
The app-release.apk file should be located under "app\release" folder in your project root.
What worked for me: I realized I had previously uploaded an .aab file and I was now trying to upload .apk file. I just needed to check Build App Bundle (Google Play) on build settings
For Flutter Developers:
You need to reverify key.properties file.
android/key.properties
Click on the Select Sign-in key(locate top of AppBundle text) and select Release signed by google
I've specified wrong credentials, which then were remembered. How do I make NuGet forget it?
As SayusiAndo guessed, the credentials were stored in Control Panel -> Credential Manager. After removing of which everything works fine.
UPDATE:
Two gotchas (as #Jurri mentioned in the comments):
There may be two credentials to delete (Windows and Generic). The generic one, in my case, had "VSCredentials_" prefix.
Restart VS.
I ran into a situation where the NuGet credentials I entered into Visual Studio were not in my Credential Manager. Deleting the package source in Visual Studio, closing Visual Studio, reopening Visual Studio, and recreating the package source allowed me to re-enter my credentials.
Hence, if the credentials don't exist in the Credential Manager, it appears deleting the package source and closing Visual Studio may be sufficient to cause Visual Studio to forget the saved credentials.
For me this isssue happens if i updated my system password. I fixed this problem by updating the passwords.
Steps:
Go to Control Panel -->User Account -->Credential Manager
In window credentials section update the password of your artifactory with encrypted password.
In Generic Credential section update your generic password which starts with VSCredential_ prefix with encrypted password.
Close and open your visual studio & Rebuild your visual studio project.
You can get encrypted password from you artifactory site(JFrog) user profile section.
You can also try looking in %AppData%\..\Local\NuGet\v3-cache. Some credentials (or configuration pointing to the credentials) are stored in a subfolder that starts with a guid, then a dollar sign, then the feed address. In my case I needed to reset my credentials for the Telerik feed, and the folder was named:
9908746e042bf0f6edf045e1c69a504b09f96883$https_nuget.telerik.com_nuget
I merely deleted the folder, restarted VS, and was asked to enter my credentials.
At least for Visual studio 2017 besides cleaning up credential cache - it does makes sense to wipe up nuget cache folder, as it keeps nuget packages downloaded locally - and then will not try any remote connection while restoring.
Run following two commands from command prompt, after that nuget authentication will be removed:
del /f "%localappdata%\MicrosoftCredentialProvider\SessionTokenCache.dat"
rmdir /s /q "%localappdata%\NuGet"
You can delete your credentials from the Credential Manager or force update the package reference by executing the following command in the Package Manager Console: dotnet nuget update source "your package name" -s "your package source/url" -u "your username" -p "your password/token"
I had to go into the credential manager and remove the machine name, i.e. in Cred Mgr my
User Name was: 10.4.4.4\username
needed to edit back to:
User Name: username
I already have an development certificate in apple developer portal. Am developing an iPhone app,i want to integrate Apple Push Notification in this app. I have created a new App ID with used the existing certificate and enabled the Push Notification in this app id. And i have created a new Provisioning Profile used the newly created app id. Before these steps i have created and downloaded the .cer file from keychain access. After done these steps i downloaded the newly created SSL (Apple Push Notification Service SSL certificate) file and installed in my Mac Keychain Access. Once i installed this file, verified (Green tick mark is there) and got the .p12 file from this ssl file.
I followed the apple document RemoteNotificationsPG.pdf, in this document they mentioned after saved the .p12 file open the Terminal app and type below commends,
openssl pkcs12 -in Certificates.p12 -out Certificates.pem -nodes
I have used this in my Terminal app, but the error message is appear that is,
Error opening input file Certificates.p12
Certificates.p12: No such file or directory
Can you please suggest or guide me where i did wrong or what i missed in these steps? Please help me. Thanks in advance.
EDIT:
I stored my Certificates.p12 file in my desktop. Folder path is Desktop->1/5/2012_Certificate->2/5/12->Certificates.p12
I have used 'ls' command in Terminal it is not listing my Certificates.p12 file.
I have typed cd *path* this returned No such file or directory.
Please help me. Thanks in advance.
Are you in the right directory? Use ls command, does it list Certificates.p12?
EDIT: In the terminal type:
ls
this will list all the files of the current directory that you are in. If Certificates.p12 is not listed, you are not in the correct directory in the terminal.
To get to the correct directory type:
cd *path*
where path is the folder containing Certificates.p12. You can drag and drop that folder into the terminal after typing cd. Hit return. Then run the openssl command.
Open the terminal and click ls to list the items in the current directory,
then if you are not in the folder in which the .p12 is having move to the correct directory by
cd directory path
for example,
cd Downloads
Then list the files using and make sure the .p12 file are existing in the directory.
Then convert the .p12 file to .pem file using the following command.
openssl pkcs12 -in filename.p12 -out filename.pem -nodes
The .pem file which you have created will be saved in the directory which is having the .p12 file.
I wrote a script that uses xcodebuild to generate an AdHoc build of an iPhone application.
I would like to edit this script to output the name of the Provisioning Profile used to sign the build.
This would allow me to include the Provisioning Profile in the zip that is automatically generated. This way, I could automatically send the archive to the AdHoc testers and be sure that they have the right Provisioning Profile to install the app.
Is there any way to extract the Provisioning Profile name or file used to sign the application:
from the builded and signed application
from the Xcode project (I don't want to manually parse the project.pbxproj file, as this solution might break in the next Xcode update)
any other way that is scriptable
Unforgiven suggested to use the command security to get the name of the certificate used to sign the app. Once you have this information, is there any way to then find the name of the Provisioning Profile?
Here is what I tried:
Sadly, the output of xcodebuild during the build does not contain this information. During the CodeSign step, there is the line:
/usr/bin/codesign -f -s "iPhone Distribution: My name" ...
but I can't match this with a certificate.
I looked into using codesign, and the command /usr/bin/codesign -d -vvv --entitlements - -r - /Users/lv/Desktop/TicTacBoo.app/TicTacBoo looked promising, but it doesn't give me the information I need.
I haven't found any useful option in xcodebuild either.
The provisioning profile is already in the application. You don't need another copy in your zip file (unless your testers do not understand how to use the copy inside of the application.)
It's named YourApplication.app/embedded.mobileprovision
This doesn't answer your question because the original filename is lost, however it does seem to solve your bigger problem.
You can use the "security" command from the terminal; unfortunately, at least on my MBP with Snow Leopard it appears to cause a segmentation fault in one of the commands you need to issue. For more information, issue from the terminal
man security
Anyway, here is what you can try, assuming your development/production certificates are stored in the login keychain:
security unlock-keychain login.keychain;
security find-certificate -a -c "iPhone Distribution: Your name" -p > cert.pem;
The second command causes the segmentation fault (caused by the -c argument), but it should be exactly what you need. Alternatively, you can use
security find-identity -p codesigning -v;
to get a list of all of the valid certificates you can use to code sign your applications.
For each certificate, the output also contains the SHA1 message digest, so that you can easily search the certificate in the keychain matching the SHA1 digest associated to "iPhone Distribution: Your name". This however, requires that you write your own application using the keychain APIs.
Let me know if this works on your mac or if you experience the same segmentation fault issue.
EDIT/UPDATE: I have verified the bug on other machines and filed a bug to Apple.
How about looking in the _CodeSignature/CodeResources plist file (of the built application) for files of type "mobileprovision"?
Here's a way to do that using defaults(1) to read the plist file. You have to copy the CodeResources file to something with the ".plist" suffix to keep defaults happy...
cp /build/Distribution-iphoneos/MyApp.app/_CodeSignature/CodeResources /tmp/defaults.plist
defaults read /tmp/defaults files |grep .mobileprovision |grep -v embedded.mobileprovision
(in my test case, there were 2 .mobileprovision entries there; ignore the one named "embedded.mobileprovision")