I just started wondering if I MUST create a Keystore for each Android app I develop considering that our company develops custom made apps for clients. Should I create one Keystore for each app or just one for all of them?
EDIT: Also how many alias for each keystore and if more than one, why?
If you are developing apps for clients, you shouldn't really hold the signing keys. Since it's their app, they should own the signing keys and publish it. Ideally, you would send them unsigned APKs which they will sign and publish. If they can't/don't want to do that, you should have separate keys for each company. First, because at some point they may require you hand it over, and second to limit the damage if the keystore is lost or damaged.
Also, your question doesn't explicitly say this, but regardless of how manage keystore files, do use different keys for each client. Otherwise Client A may get access to Client B's data if the two apps happen to be installed on the same device and use signature-level permissions.
Related
I've just finished my second react native app and going to release its android version. Should I create a new signing key or I can use my previus project key?
There is nothing that stops you to use one keystore for all apps, but it's not good practice.
With one key, it's easier for you.
With different keys, you can transfer just one of your apps to someone else.
There is no need to create a new signing key. You could use one signing key for every app.
I recently heard a case where a company sold an app to another company, and was more than happy to find out its engineers used separate project keys for all apps; the company basically sold the specific key along with the code and the intellectual property without affecting the rest.
Switching to a new set of keys for an already deployed app is not possible, as it is seemingly tied to the identification of apps for updates, preventing updates from third parties; unfortunately, I do not have a link at hand that documents this.
Android developer site say:
You should sign all of your apps with the same certificate throughout
the expected lifespan of your applications. There are several reasons
why you should do so:
App upgrade: When the system is installing an update to an app, it
compares the certificate(s) in the new version with those in the
existing version. The system allows the update if the certificates
match. If you sign the new version with a different certificate, you
must assign a different package name to the application—in this case,
the user installs the new version as a completely new application.
App modularity: Android allows apps signed by the same certificate to
run in the same process, if the applications so requests, so that the
system treats them as a single application. In this way you can deploy
your app in modules, and users can update each of the modules
independently.
Code/data sharing through permissions: Android provides
signature-based permissions enforcement, so that an app can expose
functionality to another app that is signed with a specified
certificate. By signing multiple apps with the same certificate and
using signature-based permissions checks, your apps can share code and
data in a secure manner.
At these link is another opinion:
I'd recommend using different keystores if they are totally unrelated
apps. If you end up selling one of the apps, you can give away the
corresponding keystore without compromising the security of your other
apps.
There's a developer interested in purchasing one of my apps (the only one that actually have users), meaning I would need to send him the original source code, the keystore and request Google for a transfer following this link: https://support.google.com/googleplay/android-developer/answer/6230247?hl=en
The issue is: all my apps use the same certificate from the same keystore.
So my question is: Would it be possible for the new developer to hijack any of my other apps?
I believe that the answer is "No. A device would allow another apk signed with the same certificate and with the same package name to update on the device, but Google Play wouldn't allow the developer to upload another app with the same package name as any of my other apps".
But I'm not sure on that and I would like further tech details on it.
As I said, the other apps I have are not important and I could just as well unpublish them. But I rather not, and even if I do, the question is still valid.
ps.: yeah, now I've learned that I should have 1-certificate per app.
The package name of your application is unique in the Play Store. It is how devices (and the Play Store) identify your application, and thus must be unique and cannot be changed. Android will not allow your users to install two applications with the same package name.
However, giving your keystore to another developer is still risky. The Play Store employs two gates when updating an application:
First, you must have access to the account that owns the application.
Second, you must have an APK signed with the correct keystore
By giving someone access to your keystore, you remove one of the two security checks. If the new owner of the application where to gain access to your developer account, they could re-publish the other applications as well. There's also the risk of this new owner selling the keystore and application to someone else in the future who might do the same thing.
Theoretically if your account is secure, then your other applications are also safe from hijacking.
Whether this risk is acceptable is up to you.
They could sign an APK and encourage your existing users to sideload it. When sideloading, the app isn't going to be able to know if it came from you or them. But the Play store itself won't let them upload an app that you haven't transferred to them.
Normally, part of the agreement when the buyer buys and app that using a key used by other apps would include a small snippet that the buyer must protect the key. This agreement would be bilateral anyways, since you could in theory hijack their users by sideloading a signed APK.
Would it be possible for the new developer to hijack any of my other
apps?
No way in the world its possible for him to do anything to any other of your apps unless you give him your keystore.
Your keystore is the key to all your applications and you should never share it with anyone. Having an app signed with your keystore in my developer account would never ever let me do anything to your own apps.
Anybody can have apps publish in plays store with different keystores.
So working on pushing our first build of our app to the various app stores.
Apple provides its own set of challenges and irritations.
Google, however, instead of allowing you to somehow authenticate with your google account (which would make sense to me), wants you to create a keystore with a private key & public cert (which it embeds in your apk). Then every update must have that same cert in order to be pushed to Google Play (if I understand the docs correctly).
So the keystore has a password, the private key has a password, and the keystore resides on your filesystem somewhere. This is all well and fine if you're a solo developer, however I am on a development team and any one of us may want to push an update to the app.
How do you deal with distributing the keystore and passwords in a secure way to your team & onboard new teammates when they arrive?
The answer is, you don't. There should only be one person that controls the keystore and passwords because that's who controls who submits it to the Play store. You certainly don't want new onboard teammates just submitting a new apk whenever they feel the need to.
If you're the head of this team, you should be the only one with it and control when new updates are pushed to the Play store.
If you really need to or have reason to allow multiple team member access to the Keystore.. you can subversion them. In my experience, they don't seem to be tied to a specific computer. So even if you have to replace your computer, you should still be able to use the Keystore.
Actually that is a smart thing to do anyway. We have several Keystores that got corrupted or who only knows what, but they stopped working. Which means whatever is tied to that Keystore is hosed.
I just sold one of my Android apps via Apptopia. The selling process requires that I send the buyer my Android certificate key, used to sign the app.
I have several other apps which I'm not selling, that are signed using this same certificate.
Is is safe to send the key to the buyer? Is there any way they could mess with my other apps?
Thanks
I would not say it is safe, but. Given that they are getting access to your key, technically it makes them possible to generate packages that can be 'uploaded' in place of your other applications, but they still do not have acces to your developer console (I am assuming you are transferring your app out of your account), so that gives you a certain degree of safety.
I know it is late, but a good practice could be to sign your apps with separate certificates in the future (which has its own drawbacks too, in certain cases). See this.
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