If you have only one app, signing with one or a different key makes no difference. However, your app library will increase over the years. From the 2nd app, most developers will start thinking about this issue. Depending on what you want, choose one which is the most suitable for you.
Table of Contents
The most common approach is to use the same key for all apps. When a developer starts publishing apps, I’m sure he just wants to save time and doesn’t really think about why he should create different keys.
If you use the same key for all of your apps, they can work together easier. By having all of the apps signed with the same key, you can use a shared UID or signature-based permissions — permission that the system grants only for apps with the same certificate. This allows all apps to use each others’ certain data or functionality and allow you to restrict access to your apps only.
From Android Developer:
By signing multiple APKs with the same certificate and using signature-based permissions checks, your apps can share code and data in a secure manner.
This approach has 2 cons:
– You won’t be able to sell one of your apps unless you have to sell all apps signed with the same key.
– If you lose the key, you’ll have to republish all apps.
So, remember to create a lot of backups for your key.
Even though it is kind of a hassle to create a new key and sign a new app with it, this approach will give you the best benefits. It allows you to sell your app to another developer.
When you work with other developers, this method proves to be beneficial as well. You don’t want others to know your key. If they know your key without your knowledge or permission, they can sign and distribute apps that maliciously replace or corrupt your apps. The worst situation is that the thief can use your identity and attack other apps or the OS, or corrupt or steal the user’s data.