You uploaded an APK that is not signed with the upload certificate. You must use the same certificate. The upload certificate has fingerprint: [ SHA1: abc] and the certificate used to sign the APK you uploaded have fingerprint: [ SHA1:xyz]
What kind of step did you follow? please tell it elaborately that can help people to give you a proper solution. I think this step will help you to solve your problem. Build a signed apk with signing key from android studio build option. then go to the project folder, then goo app->relase-> you will find your apk file or aab file please try to upload that.
Related
VS2022
I have succesfully built and archived my Xamarin.Forms app. I've used ad hoc distribution many times in this project, successfully.
With my last archive, it failed to sign the package, quoting the error Signing Packages Failed. 'Keystore was tampered with, or password was incorrect.'
I used this process after successfully archiving:
I click Distribute => Ad Hoc.
I select my signing Identity, and select a save location.
I am prompted for my password, which contains only 6 lower case letters.
I get an error:
Signing Packages Failed.
Keystore was tampered with, or password was incorrect.
Following other SO threads I have:
I've rebooted.
I've rebuilt and re-archived.
I have since deleted the keystore.
I've reinstalled xamarin forms after deleting the 'mono for android' folder.
Still, even with a brand new key (taking care for no special characters), the package signing fails.
I'm absolutely tearing my hair out - can anyone advise how to fix this ridiculous problem?
I am getting this error when creating an APK within Visual Studio:
Failed to load signer "signer #1": C:\...\googleplay.keystore entry "googleplay" does not contain a key
I am a longtime ASP.NET developer who is familiar with Visual Studio but this is my first Xamarin project. (I am not using Android Studio.) I am trying to deploy the Android build to Google Play. I have never uploaded an APK to Google Play so I cannot use Visual Studio's automatic deployment; I must perform a manual deployment first per Google's and Microsoft's instructions.
I am running Visual Studio 2017 15.7.5 (latest) with JDK 1.8. My project is using NETStandard.Library 2.0.3, Xamarin.Forms 3.1.0, and Microsoft.EntityFrameworkCore 2.1.1.
This question is similar to this question that has no answers but I am getting the error from within Visual Studio. If this is a duplicate, I apologize but I am unable to add additional details on that question.
I am using Google Play App Signing. I have created a key through Google Play. I downloaded the certificate in .der format. I have used keytool (from c:\Program Files\Java\jdk1.8.0_172\bin) to convert the .der file to .keystore with the following command:
keytool -importcert -alias googleplay -file "C:\...\deployment_cert.der"
I have re-run this utility a few times changing the options thinking perhaps that there might be a problem with case sensitivity on the alias or special characters in the password that keytool prompts for. In this instance, the alias is all alpha, all lowercase, and the password is alpha-numeric all lowercase. keytool asks to trust this certificate and I press "y".
This results in a file named .keystore. I renamed this to googleplay.keystore and I moved it to a more appropriate place.
I can double-check that the googleplay alias is present in the keystore file by running this command:
C:\Program Files\Java\jdk1.8.0_172\bin>keytool -v -list -keystore "C:\...\googleplay.keystore" -alias googleplay
Enter keystore password:
Alias name: googleplay
Creation date: Jul 23, 2018
Entry type: trustedCertEntry
Owner: CN=Android, OU=Android, O=Google Inc., L=Mountain View, ST=California, C=US
Issuer: CN=Android, OU=Android, O=Google Inc., L=Mountain View, ST=California, C=US
Serial number: e8************************************8a
Valid from: Thu Jul 19 14:18:56 EDT 2018 until: Sun Jul 19 14:18:56 EDT 2048
Certificate fingerprints:
MD5: 0D:**:**:**:**:**:**:**:**:**:**:**:**:**:**:C8
SHA1: 11:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:CD
SHA256: D0:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:74
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
The "googleplay" alias most definitely exists! The certificate fingerprints match the keys that Google gave me (redacted).
In Visual Studio, I set the solution configuration to Release mode, I cleaned my entire solution (successful), rebuilt my entire solution (successful), and then right-clicked my Android project and clicked Archive... per these instructions.
As a side-note, that Microsoft article is extremely frustrating because it does not mention signing or this issue, and their articles on signing do not match how Google Play operates and seem to assume you have a correct APK uploaded to Google Play already (bypassing the chicken-or-egg Catch-22).
At first all I got was The archiving process has failed. Please see the Errors section for more details. The Error List panel is empty. The Output panel just says "java.exe" exited with code 2. I went to Tools -> Options -> Projects and Solutions -> Build and Run and changed MSBuild project build output verbosity from Minimal to Diagnostic and repeated the last few steps (clean, rebuild, archive). Now, the Output panel (slightly redacted) says:
Using "AndroidApkSigner" task from assembly "C:\...\MSBuild\Xamarin\Android\Xamarin.Android.Build.Tasks.dll".
Task "AndroidApkSigner"
AndroidApkSigner:
ApkSignerJar: C:\Program Files (x86)\Android\android-sdk\build-tools\27.0.3\lib\apksigner.jar
ApkToSign: bin\Release\com.mycompany.myproject.apk
ManifestFile: obj\Release\android\AndroidManifest.xml
AdditionalArguments:
C:\Program Files\Java\jdk1.8.0_172\\bin\java.exe -jar "C:\Program Files (x86)\Android\android-sdk\build-tools\27.0.3\lib\apksigner.jar" sign --ks "C:\...\googleplay.keystore" --ks-pass pass:******** --ks-key-alias googleplay --key-pass pass:******** --min-sdk-version 19 --max-sdk-version 27 C:\...\myproject.Android\bin\Release\com.mycompany.myproject.apk
Failed to load signer "signer #1": C:\...\googleplay.keystore entry "googleplay" does not contain a key
"java.exe" exited with code 2.
Done executing task "AndroidApkSigner" -- FAILED.
Done building target "_Sign" in project "myproject.Android.csproj" -- FAILED.
Done building project "myproject.Android.csproj" -- FAILED.
Build FAILED.
From the above output you can see what the (redacted) values are in my project's property's Android Package Signing tab. Through trial and error I discovered that the Keystore Password, Alias, and Alias Password are all required. I set the Keystore Password and Alias Password to be the same, since there is only one password associated with this keystore. As mentioned above, the password is lower-alpha-numeric (no special characters following the advice from another SO question).
Why is AndroidApkSigner failing to find the key in the keystore for the provided alias when keytool finds the key without problem?
And, I can't be the only one with this problem? Deploying from Visual Studio to Google Play should be a fairly common workflow, but I am not finding anybody else (besides this other unanswered SO question) who is experiencing this issue. What am I doing wrong?
I have discovered the answer to my question. The documentation on the Android Developer site will not work with Visual Studio. The ApkSigner that comes with Xamarin does not know what to do with it. Instead, use this to create your own release key:
keytool -v -list -keystore c:\temp\myreleasekey.keystore -alias myalias -storetype pkcs12
Note the -storetype pkcs12 at the end. This command is also modified to (1) write the file somewhere besides Program Files, (2) uses .keystore extension which Visual Studio likes, and (3) avoids special characters in the alias, which Visual Studio does not like, from what I've read. (Avoid special characters in the password, too.)
Note, keytool is located in c:\Program Files\Java\jdk[version]\bin.
The Clue
When I followed the instructions on the documentation, I got a warning from keytool:
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using keytool -importkeystore -srckeystore c:\temp\myreleasekey.jks -destkeystore c:\temp\myreleasekey.jks -deststoretype pkcs12.
I also got this warning when verifying the key is correct:
keytool -v -list -keystore c:\temp\myreleasekey.jks -alias myalias
If you have an existing key and need to convert it, follow the command in the warning.
Thank you:
I want to thank Nick for explaining the reasoning behind signing and differentiating between all the keys.
And thank you, Jon, for pointing me toward how to create my own private key.
The important fact you are missing:
Google Play never gives you a key you use to sign things. It only ever gives you certificates to verify with.
I'll start with the basics you probably know. In public key cryptography, there is a private key and a public key. Only the person who signs has the private key. Otherwise anyone could sign. The public key anyone can have. They can use it to check the signature is valid.
The upload_cert.der download only contains the public key. The reason Google Play lets you download it for verification. You can verify offline your signatures match what the Play Store expects. You probably never need to do this.
Why doesn't Google give you the signing key?
Google Play doesn't give you the private key for the upload certificate for 2 reasons.
Google doesn't have the private part of your upload key! You created the private key part of the upload key, when you enrolled in Google Play App signing. You never gave it to Google. All Google has is the public key part.
If Google did give it to you, the key would have no value. The whole point of the upload key is that even if a hacker breaks into you Play Console account they still cannot upload a new version of your app. They would need the upload key as well. The upload key means Google Play knows the app came from you. If they let you download the signing key from your account, then a hacker could just download it too. Then it would be worthless.
How do I get the upload key I need for signing?
So now the question you probably have is "how do I get the public key I need for signing?". The answer is "you create it". When you first upload your APK, that APK was signed with a key (Google insists on it). It was probably stored in your Visual Studio. That key becomes your upload key. Find where you kept it.
What if I lost it?
Now you might be in a place where you don't know where the key is that you originally used. This is the great thing about Google Play App Signing. If you were signing your app yourself and lost the signing key you would be stuck, you'd have to create a new app. But with Google Play App Signing you can contact Play Console support and they can help you. The process is on the help page.
Look at the section entitled "Create a new upload key". Notice step 1 is you create the key. Google still never has it.
Disable the option "sign the .APK file using the following keystore details."
you will get this option
right click on android project select properties goto Android Package Signing.
For me, the issue had something to do with the packaging/signing screen. I ended up removing everything from the signing screen, then building the archive.
Once built, I then clicked on the archive and hit distribute. At this point it asked me for the keystore and the password. I entered them and it signed the apk. I used that one to sideload the app and it worked great.
I am currently developing an iOS application as a subcontractor for a customer with a very specific deployment process.
For security reasons, they can not provide me production certificate, so the deployment process is the following :
1 - They provide me a developper certificate (and the matching provisioning profile) ;
2 - I build an xcarchive signed with this certificate ;
3 - they deploy the xcarchive with their production certificate.
This works fine when developing native application in Xcode, because there is no restriction for signing an archive with a developper certificate.
But with Appcelerator Studio/CLI, the only way I've found to generate an xcarchive is via the Package deployment with the Studio. But this require a production certificate, and I don't have any.
Is there another way to create this archive with a developper certificate, so I can provide it to this company I'm working with ?
Thanks,
Not sure it is exactly what you are after. But if you run your app on a device it will generate an IPA file (in the /build/iphone/build/.... directory). Could you use that?
That is what I use to upload to installrapp for distributing tests :-)
/John
I am using Sparkle for the first time, and having troubles getting things off the ground. When I check for updates, it correctly detects a newer version, downloads it, unarchives it, and then gives the following error:
Update Error!
An error occurred while extracting the archive. Please try again later.
The output log shows the following detail:
Sparkle: The appcast item for the update has no DSA signature.
The update will be rejected, because both DSA and Apple Code
Signing verification failed.
My archive is named "MyApp.pkg.zip", and contains only "MyApp.pkg". It has an apple ID digital signature. I verified this by downloading the zip manually, extracting it, running the PKG, and clicking the lock icon on the first install page.
The PKG has been created using Packages.
My appcast has the following:
<enclosure url="http://thedomain/MyApp.pkg.zip" sparkle:version="1.0.0.990" length="5752133" type="application/octet-stream" />
My .app also has the same Apple ID signature as the .pkg, though I don't think it matters at this point of the auto-update process.
So my question is: What am I doing wrong? How is Sparkle concluding that the digital signature is not sufficient, when the PKG is clearly digitally signed?
Do you have different certificates for signing the .app and the .pkg? When you go to create the certificate on Apple's Certificates site, you have to choose one or the other type.
You need to have two certificates, one for signing the .app and one for signing the .pkg.
I'm trying to submit an update to my app. I had messed up some files, so had to generate from scratch all of my the certificates, keys, and provisioning files. Would that be a problem for updating? I read someone saying that updates to the app HAVE to be done using the same provisioning file... that can't be true, can it? Otherwise, I'm in major trouble.
Anyhow, my archive builds keep failing validation. I have triple checked that I'm using the Store Distribution certificate for my release. I also ran codesign command and it came through fine. I have also checked the contents of MYAPP.app bundle and the "embedded.mobileprovision" is there. Why does it say "Failed to load"?
Below is the output I get in my log. Any ideas?
(using XCode 4.0.2)
warning: Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)
Executable=/Users/anna/Library/Developer/Xcode/DerivedData/MYAPP-fjmzhplryhwnsrgcsoyuivpwrojd/Build/Products/Release-iphoneos/MYAPP.app/MYAPP
codesign_wrapper-0.7.10: using Apple CA for profile evaluation
AssertMacros: signer, file: codesign_wrapper.c, line: 610
AssertMacros: profile, file: codesign_wrapper.c, line: 914
codesign_wrapper-0.7.10: Failed to load provision profile from: /Users/anna/Library/Developer/Xcode/DerivedData/MYAPP-fjmzhplryhwnsrgcsoyuivpwrojd/Build/Products/Release-iphoneos/MYAPP.app/embedded.mobileprovision
- (null)
You should remove your distribution certificate from your system. Revoke that certificate from developer portal, create a new one. delete the old provision profile and create a new provision profile for app store and use that.
I ended up resolving my issue by moving over to a different machine that had a clean install of all the dev tools. My original install got corrupted because I foolishly installed beta version over it and then tried to revert back, at which point codesign didn't want to play along anymore. I know that wasn't the smartest thing.. but sometimes you do things for the first time and learn the hard way :)
Anyhow, the good news is that new keys and certificates don't really mess things up and life can go on but watch where you install beta versions!
In dev center you can read that it is critical to store your private key somewhere save. It also says that this private key cannot be reproduced if lost.
Therefore I think you are in trouble.