[Android_ Pre-submission Work]android Project APK signature

The most lazy way to build the APK is:
As long as you run an Android project, you can find the APK file with the same name as the project in the Bin folder of the working directory, which is signed by the debug user by default.

If you want to sign the APK yourself:

1. The meaning of the signature
In order to guarantee the legal ID of each application developer, to prevent some of the open vendors from possibly confusing the installed program by using the same package name, we need to uniquely sign our released APK file to ensure consistency for each release we publish ( such as Automatic Updates will not be installed because of inconsistent versions).
2. Procedure for signing
A. Creating a key
B. Sign the APK using the key generated in step a
3. Specific Operation
　　 method One: Sign the APK at the command line (principle)
To create the key, you need to use the Keytool.exe (located in the Jdk1.6.0_24\jre\bin directory), using the resulting key to the APK signature is Jarsigner.exe (located in the Jdk1.6.0_24\bin directory), After adding the directory where the two software is located to the environment variable path, open the cmd input
D:\>keytool-genkey-alias demo.keystore-keyalg rsa-validity 40000-keystore demo.keystore/* Description:-genkey generate key-al IAS Demo.keystore alias Demo.keystore-keyalg RSA uses RSA algorithm for signing encryption-validity 40000 expiration 4,000 days-keystore Demo.key Store */d:\>jarsigner-verbose-keystore Demo.keystore-signedjar demo_signed.apk demo.apk demo.keystore/* Description:-verbose output signature details-keystore demo.keystore keystore location-signedjar demor_signed.apk demo.apk Demo.keystore formally signed, three The file demo_signed, the file demo.apk to be signed, and the KeyStore demo.keystore.*/
Note: The demo.apk in the bin directory of the Android project is signed by default with the debug user, so you cannot use the above procedure to sign the file again. The correct step should be: In the project right click->anroid tools-export Unsigned Application package exported APK takes the above steps to sign.
　　 method Two: Use Eclipse to export the signed apk
Eclipse can directly export a signed final apk, which is very convenient and recommended, with the following steps:
First step: Export.

The second step: Create the KeyStore keystore, enter the KeyStore export location and password, remember the password, the next use existing KeyStore will be used.

Step three: Fill in the KeyStore information, fill in some apk file password, use the term and organizational unit information.

Fourth step: Generate a signed apk file, and this is the end.

Fifth step: If the next release, use the previously generated keystore to sign again.

Sixth step: Next,next, End!
Method Three: Use IntelliJ idea to export a signed APK
　　The method steps are basically the same as eclipse, and the approximate action path is: Menu Tools->andrdoid->export signed apk.
4. After signing, use Zipalign (compression alignment) to optimize your apk file.
Unsigned apk cannot be used, nor can it be optimized. After signing the APK Google recommends using the Zipalign.exe (located in the Android-sdk-windows\tools directory) tool to optimize it:
D:\>zipalign-v 4 demo_signed.apk final.apk
As above, Zipalign enables the uncompressed data in the APK file to be aligned on a 4-byte boundary (4 bytes is a well-performing value) so that the Android system can read the file using the Mmap () function (see the purpose of the function itself) to get higher performance on read resources ，
Ps:1. Alignment on a 4-byte boundary means that, in general, the compiler bar 4 bytes are read as a unit, so that the CPU can access the variable efficiently and quickly (not before).
2. The root cause of alignment: The Davlik virtual machine in the Android system uses its own proprietary format DEX,DEX structure is compact, in order to make the performance of the runtime better, can further use "alignment" further optimization, but the size will generally increase.
5. The impact of the signature on your app.
You can not only do an app, you may have a grand strategic project, want to in life, services, games, systems in all areas want to get into the words, you can not only do an app, Google recommends that you put all your apps use the same signing certificate.
With your own signature certificate, no one can overwrite your application, even if the package name is the same, so the impact is:
　　 1) App upgrade。 Upgrade software with the same signature can gracefully overwrite the old version of the software, or the system will find that the new version of the signing certificate and the old version of the signing certificate is inconsistent, does not allow the new version to be installed successfully.
　　 2) App modularity。 The Android system allows the same app to run in the same process, and if it's running in the same process, they're equivalent to the same app, but you can update them individually, which is an app-level modular mindset.
　　 3) Allow code and data sharing。 A signature-based permission tag is available in Android. With the allowed settings, we can implement access and sharing between different apps as follows:
Androidmanifest.xml:<permission android:protectionlevel= "Normal"/>
Where the ProtectionLevel tag has 4 values: normal (default), dangerous, Signature,signatureorsystem. In simple terms, normal is a low-risk, and all apps cannot access and share the app. Dangerous is a high-risk, all apps can access and share this app. Signature refers to apps with the same signature that can access and share the app. Signatureorsystem means that the app in the system image and the app with the same signature can access and share the app, and Google recommends not to use this option, because the signature is sufficient, and generally this license is used in the case of an image that needs to share some specific functionality.