[ACCEPTED]-Why should I sign my apk before releasing to PlayStore?-sign

From the Android Documentation for Signing Applications:

The Android system requires that 83 all installed applications be digitally 82 signed with a certificate whose private 81 key is held by the application's developer. The 80 Android system uses the certificate as a means 79 of identifying the author of an application 78 and establishing trust relationships between 77 applications. The certificate is not used to 76 control which applications the user can 75 install. The certificate does not need 74 to be signed by a certificate authority: it 73 is perfectly allowable, and typical, for 72 Android applications to use self-signed certificates.

The 71 important points to understand about signing 70 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 69 will not install or run an application that 68 is not signed appropriately. This applies 67 wherever the Android system is run, whether 66 on an actual device or on the emulator. For 65 this reason, you must set up signing for 64 your application before you can run it or debug 63 it on an emulator or device

Why means:

Some aspects 62 of application signing may affect how you 61 approach the development of your application, especially if you are planning to release multiple applications.

In 60 general, the recommended strategy for all 59 developers is to sign all of your applications 58 with the same certificate, throughout the expected 57 lifespan of your applications. There are 56 several reasons why you should do so:

• Application upgrade – As 55 you release updates to your application, you 54 must continue to sign the updates with the 53 same certificate or set of certificates, if 52 you want users to be able to upgrade seamlessly 51 to the new version. When the system is installing an 50 update to an application, it compares the 49 certificate(s) in the new version with 48 those in the existing version. If the certificates 47 match exactly, including both the certificate 46 data and order, then the system allows 45 the update. If you sign the new version 44 without using matching certificates, you 43 must also assign a different package name to 42 the application — in this case, the user 41 installs the new version as a completely 40 new application.

• Application modularity – The Android system allows 39 applications that are signed by the same 38 certificate to run in the same process, if the 37 applications so requests, so that the system 36 treats them as a single application. In 35 this way you can deploy your application 34 in modules, and users can update each 33 of the modules independently if needed.

• Code/data sharing through permissions – The 32 Android system provides signature-based 31 permissions enforcement, so that an application 30 can expose functionality to another application 29 that is signed with a specified certificate. By 28 signing multiple applications with the 27 same certificate and using signature-based 26 permissions checks, your applications 25 can share code and data in a secure manner.

Another 24 important consideration in determining your 23 signing strategy is how to set the validity 22 period of the key that you will use to sign your 21 applications.

• If you plan to support upgrades 20 for a single application, you should ensure 19 that your key has a validity period that 18 exceeds the expected lifespan of that 17 application. A validity period of 25 years 16 or more is recommended. When your key's 15 validity period expires, users will no longer 14 be able to seamlessly upgrade to new versions 13 of your application.

• If you will sign multiple 12 distinct applications with the same key, you 11 should ensure that your key's validity period 10 exceeds the expected lifespan of all versions 9 of all of the applications, including dependent 8 applications that may be added to the suite 7 in the future.

• If you plan to publish your 6 application(s) on Google Play, the key you 5 use to sign the application(s) must have 4 a validity period ending after 22 October 3 2033. Google Play enforces this requirement 2 to ensure that users can seamlessly upgrade 1 applications when new versions are available.

Why?

Developers can prevent someone from tampering 23 with their app.

Sign to protect your app!

This works in the public 22 key cryptography. You are the only one who 21 has the private key. You are the only one 20 who can sign your apps. The user can trust 19 the app being directly from you. It is mathematically 18 proven to be unfeasible to tamper with the 17 app if the private key is not available.

You 16 know, in public key cryptography there are 15 two keys like the sides of a coin. The private 14 and the public key. You keep the private 13 key secret. You lock it away and keep it 12 secure. On the other hand you publish your 11 public key.

These keys are like the sides 10 of a coin because what you encrypt with 9 one key you decrypt with the other key.

And 8 how is this applied for app signing?

Signing 7 is encrypting with the private key.

Because 6 you publish the public key the app store 5 and the users have your public key. They 4 can decrypt your app and therefore know 3 for sure that the app is really your own. Android 2 and the app store does this for them.

The app store verifies the signature by decrypting with the public key.

That's 1 all, folks.