I have been developing an Android application for another person that is to be published to the Google Play Store. They have a developer account, and have given me a key. I have made a build release of the application and now have an unsigned apk. All I have is their key. Is there a way to release this app into the Play store without this keystore I have heard about, just using they key they have provided? All the tutorials and docs I am looking at keep mentioning the keystore, and since this person has their own account with their own key and will be maintaining the app on their own moving forward, it doesn't make sense for me to use my own account.
Alternatively, maybe it is just a situation where I need to give them the unsigned apk key and they are responsible for the remainder of the publishing process. This is less than ideal, because we would like to be able to possibly make some changes to the app after the initial release. Any guidance would be appreciated.
They can create the keystore and send it to you, the keystore should be password protected, then you will have an alias/password pair inside the keystore to access the key you want. When exporting your apk you can select this keystore and sign the package with their key. To make changes in the future you will need to sign it/export it again with the same key and upload it to the Google Play store. If you lose the key you will not be able to upload a new version. You can find more detail at this SO question.
My advice is to generate a keystore the proper way, either the other person needs to or you should and then share the information.
Related
I'm writing a python script to build and sign my android project using gradlew ,
Everyone on the web is talking about how u can lose your generated key and therefor u can lose ability to update your published application. my question is are every generated keys using keytool unique?
and the signed apk using that key would easily be uploaded to google play store and every single app signed using that certain key will be considered as an update ?
thanks .
Yes, every key generated by keytool is unique.
For key management, you basically have a few options:
Generate the app signing key locally, keep it secure, and only use it when generating the release version of your app. Use a separate key for the debug versions of your app.
Generate the app signing key locally, enroll in App Signing by Play supplying your key to Google. During the enrollment, you will be prompted to created another key (called the upload key). You can use the upload key normally to sign the apps you upload to the Play Console, but make sure to keep the app signing in a safe place with strict ACLs. If you lose the upload key, you can always have it reset, so less critical.
The easiest solution (and the default in Play Console) is to enroll in App Signing by Play and let Google generate the app signing key. You are this way sure that you won't be accidentally losing or leaking it, and that it will be secure enough. Also, you'll only have one key to deal with: the upload key, which can be reset if you lose it.
I'd recommend the 3rd option (simplest, most secure), but some people prefer to keep a copy of the key with them and thus opt for the 2nd option. The 1st option is very risky as you seem to have already heard.
Please correct me!!
I read in this article:
https://support.google.com/googleplay/android-developer/answer/7384423
App signing key (1) - managed by Google, is Inaccessible
Upload key (2) - is managed by us
(1) can be different with (2)
How can we obtain the (1) for signing in local?
I need to test update from current version (the latest one on PlayStore which is signed with 1) to the new version N+1.
But since I can not have (1), how can I sign my app for local testing?
Thank you.
Thank Michael for your answer:
When you opt in to have your app signed by Google you can choose to provide an existing key rather than having a new one generated by Google: "To provide your own signing key for Google to use when signing your app, select Advanced options and select one of the options that lets you securely upload a private key and its public certificate". If you've already let Google generate a key for you then I'm not sure if you can redo it (especially if APKs signed with that key have gone out into production).But you could create an Internal Test group for your team and publish new versions there first
You should test with a different key locally. The app signing key is sensitive since it can't easily be changed, so it's good practice to use a separate key for local testing.
If you use APIs that require the certificate to be whitelisted, you can whitelist this test certificate as well.
I am trying to sign an app using the manual method found here
http://developer.android.com/tools/publishing/app-signing.html#signing-manually
Our previous external developers have sent me three keystore files that I need for this (not sure why they would require three??). When going through the process of trying to sign my app I am prompted with a keystore password which I do not know (I'm trying to get this from them).
Is it possible for me to change this myself? I have the three keystore files but I'm not sure if this would have an effect as the app has already been signed and released to the store and I want to update the app rather than release a whole new one.
I know this question has been asked before I just wasn't sure if those answers directly applied to me as my app is already in the Google Play store and published
i have few suggestion for you.
if you don't know password of all 3 key-store then no one will help you. you must have to create new app with new package name(which is different from last live app on Google play), add new app on Google play
now in case you have password then first get last live APK. generate sign keys(sha-1 & MD5) from that APK file check answer here how to generate keys from APK.
then after get sha-1 & MD5 from all 3 key-store and match with APK's sha-1 & MD5. they are match then you are able to know which key-store are used for sign APK(which is currently on Google play)
use that key-store to generate new APK :)
I want to upload apk with different signed keystore after deactivate current apk.
Actually company lost old one keystore that used for signed APK.
So any another way for get old keystore or upload new apk as Same app Update.
For this issue here is the answer from Google Play Team:
Hi x,
Thank you for your note.
If you've lost your keystore you'll have to publish the app with a new package name and a new key. You should also update the description of the original app and unpublish it. Please note that users are allowed unlimited reinstalls of each application distributed via Google Play, an application will remain available to users that have already installed it even after it has been unpublished. Currently we do not support the deletion of apps or the re-use of package names.
Unfortunately, there is nothing else we can do to assist you further with this matter.
Regards,
The Google Play Team
Here is Reference
As blackbelt stated, if you signed it with a different keystore, it will be a new application. So you should tell your users that they have to download the new version of the app.
However you could check this tool which will try to recover your private key with the alias. I don't guarantee that you could retrieve it but you could give a try.
The tool recovers the key for your alias. By default this is the same
like the keystore password. Now there is an option to save
the key in a new keystore with the same password than the key! You can
use this, to sign your apk and update your app in the Playstore.
Here's the link :
https://code.google.com/p/android-keystore-password-recover/
I have to upload a new application, It's just the design that's a little different. Yesterday I generated the keystore file to sign application. Can I use the same?
You can use that keystore for any number of applications.
No need to generate a new keystore.
I'll make a counter argument to the consensus answer so far.
I agree that for most app authors most of the time, sharing the same keystore/certificate/password between your apps will work fine. The critical thing is to use "the same certificate throughout the expected lifespan of your applications" so the app can upgrade itself.
But I can think of one very good reason to have separate keystores for separate apps or families of apps. If you think you might ever want to sell an app to someone else for them to publish as an upgrade to the original, you'll have to share your one-and-only keystore and password with them to do so. Probably not a huge issue but a bit of worry to you and, perhaps, a due diligence issue to a big-enough buyer.
Also, I really don't read the same line in the documentation the same way as #ol_v_er does. I think the current line:
You should sign all of your apps with the same certificate throughout the expected lifespan of your applications.
(note the lack of a comma in the current version) is simply emphasizing that the 'lifetime' recommendation applies to all apps, not actually directing you to use the same certificate for all of your apps.
The official documentation tells us:
In general, the recommended strategy for all developers is to sign all of your applications with the same certificate, throughout the expected lifespan of your applications. There are several reasons why you should do so ...
https://developer.android.com/studio/publish/app-signing.html#considerations
So yes, try to sign all of your applications with the same certificate.
I want to add some clarification here, because this question and the answers provided lead to confusion for me. It is crucial to understand what a keystore actually is.
A keystore is just a means to securely store the public/private key pair which is used to sign your Android apks. So yes, you can use the same keystore to sign multiple apks, without a problem. You can also use the same alias (each alias is a certificate) to sign multiple apks, and it will work. It has security implications, however. If your single alias is compromised, then all of your apps will have been compromised.
However, if you intend to sell the rights to your apps one day, then using the same alias for all of your apps may not be a good idea. However, using the same keystore, provided you use a different alias for each apk, may not necessarily be a bad option. I'm sure there is a way that you can move a certificate from one keystore to another, so that you can securely give the necessary keys for only that certificate to your buyer.
To make it very clear, a keystore is just that, a storage medium for keys. It plays no actual part in the process of signing an apk, but only serves to store the keys which are actually used to sign the apk.
References:
Understanding keystore, certificates and alias
https://www.digitalocean.com/community/tutorials/java-keytool-essentials-working-with-java-keystores
Of course! You can use the same keystore file as many times you want. It's always better to use the same keystore file for all the applications you develop. That will help if you want to update or modify the application. At that time you need to sign your application with the same key.
Recent Update
If you want to enrol in App signing by google you have to use new different key to sign your apk or bundle otherwise after uploading google console will give you error message saying
You uploaded an APK or Android App Bundle that is signed with a key
that is also used to sign APKs that are delivered to users. Because
you are enrolled in App Signing by Google Play, you should sign your
APK or Android App Bundle with a new key before you upload it
I do sign all my apps using the same certificate (keystore). This gives an advantage if i change my mind and want my apps to share their data.
As you might know Android identifies each app with an UID. If all your apps are signed by the same certificate you can request android to assign same user id more than one app and inturn make them run in a single process and share the data.
From android doc android:sharedUserId
android:sharedUserId
The name of a Linux user ID that will be shared with other applications. By default, Android assigns each application its own unique user ID. However, if this attribute is set to the same value for two or more applications, they will all share the same ID — provided that they are also signed by the same certificate. Application with the same user ID can access each other's data and, if desired, run in the same process