The app bundle was generated by the first PC (Ubuntu 18.04) using keystore and its password. Google Play accepted app bundle and application was updated successfully.
After that same process was repeated in another PC (same project, same keystore, same password) and successfully generated app bundle. But Google Play did not accept it and showing error:
App bundle was signed with wrong key. Choose appropriate key: SHA1: C9:AF....
I tried different ways to solve this problem:
Tried to create app bundle on Windows and MacOS machine. Could not try on Linux machine because there are no Linux machine available
Besides the app bundle trying to create the apk which was generated successfully, but when uploading Google Play showed error: signature is invalid
Developer who owns Linux machine is leaving project and we need to generate app bundle in another machine.
What is the reason for this problem if app bundle is created by same keystore and password? How can I solve this problem?
I'm pretty sure even though you think it is being signed with the same keystore, you have made a mistake somewhere. You can check this for yourself though. App Bundles are just signed using the same scheme as jarsigner. So you can print them using keytool.
keytool -list -printcert -jarfile mybundle
If the values are the same for the bundles produced on both PCs then they are signed with the same key in the same keystore. Otherwise you are doing something wrong. Maybe using a release key on one, and a debug key on another, or the keystore has two different keys with different names. Or maybe you think you are using the keystore when you aren't.
Google play accept the apk generated by same keystore file. So please check you have made some mistake. Use the previous keystore and compare it with the current one to check and verify the SHA! and SHA256 Signature
if upload an Application on play-store with one Keystore you don't need to create another keystore for the same project, just use the same keystore for your next version uploading.
NOTE: Google not allow to create multiple keystore for same project.
Remember the selection of signature of version what you selected. this must be the same for your next release.
Related
I'm using SHA1 debugging key in firebase for debugging my application, but I want to release my app in the play store where I'm providing Google authentication in my application.
What can I do for release mode where do I get SHA1 release mode certificate and what can I do with that?
Is it necessary to download the json file again? How can I do that?
I had the same problem and found this enter link description here
Basiclly what he did, and for me works fine, is one you upload the app to google play:
Go to Release Management
Select App Signing
Use the SHA1 that you see there in FireBase
I recently switched back to Android Studio after a few months of trying out the Android plugin of IntelliJ.
Then I tried signing the APK of an app that is currently in beta test in the play store but the signature does not match what is on the Dev Play Console for the previous versions.
I double checked and I am sure that I am using the same keystore (and same key) as before.
Now I am left with two possibilities:
• There's a problem of code signing when migrating IntelliJ to Android?
• My passwords for the keystore are wrong. But then, why would it succeed in building the APK?
Can I rule out any of these two directions?
It reads on the Google help that if the keystores are lost (which is not the case, but maybe the password is), one need to recreate a completely new app on the Play Store with a new package name.
There really would be no alternative to this?
PS: I had downloaded some certificates for apk signing in the past, but I don't know how to use them within Android studio in stead of the jks files.
EDIT
The error message I get from the store is :
You uploaded an APK that is not signed with the upload certificate.
You must use the same certificate. The upload certificate has fingerprint:
[ SHA1: XXX ]
and the certificate used to sign the APK you uploaded have
fingerprint:
[ SHA1: YYY ]
Yet, when I run the following:
keytool -list -v -keystore "/Path/upload_keystore.jks"
-alias "upload_key" -storepass ***** -keypass ****
I get that the SHA1 is actually XXX (and not YYY).
So it should be right.
Also, weird thing: whatever passwords I use, I get the same SHA1, and it is the correct one!
But I also get the following message:
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 /Path/upload_keystore.jks -
destkeystore /Path/upload_keystore.jks -deststoretype pkcs12".
Which is weird since it was generated by Google.
Ok, I just did a clean build, and signed it again, and it worked.
I guess the first signing attempt was wrong, but it got cached and prevented the other signing attempts to really be effective.
I'm setting up a new app and I need that to authenticate with firebase. I have tried a lot of different codes to get SHA1 key but I am unable to do so. Please help me.
Checkout the image please
You can easily get SHA1 for your app using Signing Reports option from your IDE. Please check image below.
Please note:
You will have to mention your keystore details and create a signing config in project settings / Gradle file. once your signing config is added, using this option you will be able to get SHA1 for signed apk as well. Otherwise there will be SHA1 for Debug config.
Result as :
I have created a Midelt which accesses phone contact details [read and write contacts] and access network, this application is working fine S60 emulator.
When I try to install in Nokia E71, it is giving certification error.
I have created certificate using below link. When I try to install it in the phone still I am getting the certification error.
http://www.j2start.com/
Can anybody suggest, is there any way to test a midlet in actual Nokia e71 device without certificate from CA?
If certificate is mandatory,
which is the most suitable CA [Verisign or Thawte ] for Nokia E71?
It was stated in that page (where you signed your app) that the validity of the certificate is between Sept 1, 2010 to Sept 17, 2011. You need to set your device's date to any date between the validity period.
If the same error persists, try to check the certificates in the jad and check if the same certificate is in the phone.
Find JadTool.jar in your machine. You may find it in the Java SDK installation directory or WTK installation directory. If you can't find it then simply download it from the internet. For simplicity, put it in (root directory) C: (I'm assuming you're using Windows, if not then tell me later ;)).
Copy your signed jad file in C. (I want you to have both files, JadTool.jar and your app's jad file, in one directory, preferably C, as a prerequisite of the next steps :D)
Open terminal/command prompt. Go to C; type cd \ (Again, I'm assuming you're on Windows.)
Still on the terminal, type java -jar JadTool.jar -showcert -all -inputjad YourAppName.jad. Mind the case of the letters.
On the previous step, you can see which certificates are available in your jad file. You can see the details of each certificate. Let's focus on the fingerprints. If, for example, you see a Thawte certificate, take note of its SHA fingerprint.
Check the certificates in your device. The certificates are usually found in Security under Settings. If you have a Thawte certificate in the jad then you must check the Thawte certificates in the device. Compare the Thawte SHA fingerprint found in the jad against the Thawte fingerprint of the device. If they match then the app with this certificate is install-able on the device. If they don't match then it is more likely that you cannot use this certificate with your jad file.
Do steps 6 and 7 for the rest of the certificates. If you can't find any pair
then, with the signing, it is more likely that you cannot install your app on your device.
By the way, you can still install your app on the device even if it is unsigned. One problem, if your app is unsigned, is that the user will be be bugged with security prompts. However, this can also be minimized. See my answer on how to minimize these prompts.
This could be the problem becase your either your certificate is old or just check the date on your phone. Your Phone might be running old date.
I've already asked similar question on this issue on stack overflow already, but I believe this part of the issue can be separated into a new question.
I've not done mobile development before so the use of signing and certificates is a new concept to me, and for all the reading of topics I have done, its not really improved my knowledge as each website I read talks only about a small part of signing, not the complete process, and piecing it all together has been difficult.
The issue I have is my driver is not been loaded at startup on WM6.1. Its a driver for GPS so needs to be loaded so its available to any GPS software accessible on a COM port. I believe this is due to a signing issue, given that the DllMain method is never called.
I have been given a privileged certificate (.pfx) to use, and for the record have also got the new (Jan 2010) SDKSamplePrivDeveloper certificate as well. I assume a privileged certificate is needed for drivers.
So what have I actually done. I've tried atleast several variations on this over the last 4-5 days all with no success.
In visual studio;
1)The DLL project has authenticode signing set to our .pfx certificate. Build the project.
2)The CABWizard project has authenticode set to the same certificate. Build the project.
3)Following the MSDN instructions... Converted the .pfx into a 509 Base64 Certificate, and created an XML provisioning file from it.. It has been created into its own CAB Or CPF file. And also tried provisioning the _setup.xml file into the previously created CAB file so its installed with the application.
4)I have installed these onto the device, and whilst the driver does work in our test app it does not load at boot even though its registry settings in "BuiltIn" are correct. When checking the certificate stores in the registry I can see the certificate added to the SPC, Root, Privileged and Unprivileged stores. And when using System|Certificates I can see the certificate in Root tab. So they have definitely been added.
Given the above did not work. I have also tried the siggner.exe tool from http://www.modaco.com/content/i8000-verizon-sch-i920-omnia-ii-http-i8000-modaco-com/306870/sdkcerts-2010-and-signing-tool/ with the SDKSamplePrivDeveloper certificate.
1)The Dll project has authenticode signing set to No. Build the project.
2)Load up siggner.exe and sign the Dll file with SDKSamplePrivDeveloper.cer.
3)The CABWizard project has authenticode set to No. Build the project.
4)Load up siggner.exe and sign the cab file with SDKSamplePrivDeveloper.cer.
5) Use NewSDKCerts.Cab to install the SDKSamplePrivDeveloper certificate into the stores.
6) Install the CAB file i created with the driver.
7) Again, on a warm reboot the driver is not loaded at boot into device.exe.
Given the above, can anyone give me some clear instructions on a sure fire way to load the driver at startup. I'm obviously doing something wrong with the signing given this does boot up without an issue in Windows CE5. I know the device driver code is OK as I can activate it manually in code with ActiviateDevice() method in WM6.1.
Edit--
It maybe worth adding, I also created a DLL and CAB with no signing at all. And on a clean boot of the OS it installed without complaining. Whilst still not loading at boot I did expect warnings about the CAB and DLL been unsigned.
The reason for driver failure, was not a certificate issue.
The driver was originally self contained and also contained some GUI code, and has since expanded. A library used to make the application full-screen was not available at start up so it silently failed with a dependency issue.
This has currently been resolved with a start-up application loading later to wake up the driver, once the library is available. A proper solution to be added is late loading of the required library to prevent a dependency failure.
Driver signing was also an issue in a related matter with this driver. We now have a certificate from the manufacturer to sign drivers so that issue was resolved as well.