Why should I sign my apk before releasing to PlayStore?
From the Android Documentation for Signing Applications:
The Android system requires that all installed applications be digitally signed with a certificate whose private key is held by the application's developer. The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications. The certificate is not used to control which applications the user can install. The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates.
The important points to understand about signing Android applications are:
- All applications must be signed. The system will not install an application on an emulator or a device if it is not signed.
- To test and debug your application, the build tools sign your application with a special debug key that is created by the Android SDK build tools.
- When you are ready to release your application for end-users, you must sign it with a suitable private key. You cannot publish an application that is signed with the debug key generated by the SDK tools.
- You can use self-signed certificates to sign your applications. No certificate authority is needed.
- The system tests a signer certificate's expiration date only at install time. If an application's signer certificate expires after the application is installed, the application will continue to function normally.
- You can use standard tools — Keytool and Jarsigner — to generate keys and sign your application .apk files.
- After you sign your application for release, we recommend that you use the zipalign tool to optimize the final APK package.
The Android system will not install or run an application that is not signed appropriately. This applies wherever the Android system is run, whether on an actual device or on the emulator. For this reason, you must set up signing for your application before you can run it or debug it on an emulator or device
Why means:
Some aspects of application signing may affect how you approach the development of your application, especially if you are planning to release multiple applications.
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:
Application upgrade – As you release updates to your application, you must continue to sign the updates with the same certificate or set of certificates, if you want users to be able to upgrade seamlessly to the new version. When the system is installing an update to an application, it compares the certificate(s) in the new version with those in the existing version. If the certificates match exactly, including both the certificate data and order, then the system allows the update. If you sign the new version without using matching certificates, you must also assign a different package name to the application — in this case, the user installs the new version as a completely new application.
Application modularity – The Android system allows applications that are 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 application in modules, and users can update each of the modules independently if needed.
Code/data sharing through permissions – The Android system provides signature-based permissions enforcement, so that an application can expose functionality to another application that is signed with a specified certificate. By signing multiple applications with the same certificate and using signature-based permissions checks, your applications can share code and data in a secure manner.
Another important consideration in determining your signing strategy is how to set the validity period of the key that you will use to sign your applications.
If you plan to support upgrades for a single application, you should ensure that your key has a validity period that exceeds the expected lifespan of that application. A validity period of 25 years or more is recommended. When your key's validity period expires, users will no longer be able to seamlessly upgrade to new versions of your application.
If you will sign multiple distinct applications with the same key, you should ensure that your key's validity period exceeds the expected lifespan of all versions of all of the applications, including dependent applications that may be added to the suite in the future.
If you plan to publish your application(s) on Google Play, the key you use to sign the application(s) must have a validity period ending after 22 October 2033. Google Play enforces this requirement to ensure that users can seamlessly upgrade applications when new versions are available.
Why?
Developers can prevent someone from tampering with their app.
Sign to protect your app!
This works in the public key cryptography. You are the only one who has the private key. You are the only one who can sign your apps. The user can trust the app being directly from you. It is mathematically proven to be unfeasible to tamper with the app if the private key is not available.
You know, in public key cryptography there are two keys like the sides of a coin. The private and the public key. You keep the private key secret. You lock it away and keep it secure. On the other hand you publish your public key.
These keys are like the sides of a coin because what you encrypt with one key you decrypt with the other key.
And how is this applied for app signing?
Signing is encrypting with the private key.
Because you publish the public key the app store and the users have your public key. They can decrypt your app and therefore know for sure that the app is really your own. Android and the app store does this for them.
The app store verifies the signature by decrypting with the public key.
That's all, folks.