Resolve to create apk for Android projects in Eclipse and explain the implementation of APK signatures _android

The laziest way to generate APK is:
As long as you run the Android project, you can find the APK file with the same name as the project under the Bin folder of the working directory, which is signed by the debug user by default apk.
If you want to sign apk yourself:
1. The meaning of the signature
To ensure that the legitimate IDs of each application developer are used to prevent some of the open vendors from using the same package name to confuse the replacement of installed programs, we need to uniquely sign our published APK file to guarantee the consistency of each release we publish ( such as Automatic Updates will not be installed because of a version inconsistency.
2. Signature steps
A. Create key
B. Use the key generated in step A to apk the signature
3. Specific operation
Method One: apk signature under command line (principle)
To create a key, you need to use Keytool.exe (located in the Jdk1.6.0_24\jre\bin directory), and use the generated key to apk the signature of Jarsigner.exe (located in the Jdk1.6.0_24\bin directory). After adding the directory of the two software to the environment variable path, open 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 the RSA algorithm to encrypt the signature-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 official signature, three demo_signed the file to be signed, the file demo.apk and 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 sign the file again using the steps above. The correct step should be: In the project right click->anroid tools-export Unsigned Application Package Export APK take the above steps to sign.
method Two: Using Eclipse to export signed apk
Eclipse can directly export the final apk with signature, which is very convenient and recommended, as follows:
First step: Export.

Step Two: Create 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 key library information, fill in some apk file password, the use of time and organizational unit information.

Step Fourth: Generate the APK file with the signature, and it's over.

Fifth step: If the next release version, use the previous generated KeyStore to sign again.

Sixth step: Next,next, End!
method Three: Using IntelliJ idea to export the APK with signature
The method steps are basically the same as eclipse, and the approximate operation path is: Menu Tools->andrdoid->export signed apk.
4. After the signature, use Zipalign (compression alignment) to optimize your apk file.
Unsigned apk are not available and can not be optimized. After signing the APK Google recommends using 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 is able to align uncompressed data in APK files on 4-byte boundaries (4 bytes is a good performance value), this allows the Android system to read the file using the mmap (check the function's purpose) function to get higher performance on the Read resource ，
Ps:1. Alignment on a 4-byte boundary means, in general, the compiler bar The result of reading 4 bytes as a unit, so that the CPU can efficiently and quickly access variables (as opposed to the previous alignment).
2. The root of alignment: The Android Davlik virtual machine uses its own proprietary format DEX,DEX the structure is compact, in order to allow better performance at run time, you can further optimize the alignment, but the size will generally increase.
5. The influence of the signature on your app.
You can't just do one app, you might have a grand strategic project, want to get in on life, service, games, systems, you can't just do one app, Google advises you to use the same signature certificate for all your apps.
With your own signature certificate, no one will be able to overwrite your application, even if the package name is the same, so the impact is:
1 app upgrades. Upgrade software with the same signature can normally overwrite the old version of the software, otherwise the system comparison found that the new version of the signature certificate and the old version of the signing certificate is inconsistent, will not allow the new version of the installation successful.
2 app Modularization. The Android system allows the same app to run in the same process, and if it runs in the same process, they're the same app, but you can update them individually, which is an app-level modular idea.
3 Allow code and data sharing. Android provides a permission label based on the signature. With the allowed settings, we can achieve access and sharing between different apps, as follows:
Androidmanifest.xml:<permission android:protectionlevel= "Normal"/>
Where the ProtectionLevel label has 4 values: normal (default), dangerous, Signature,signatureorsystem. In short, normal is low-risk, and all apps cannot access and share the app. Dangerous is risky, and all apps can access and share the app. Signature means that an app with the same signature can access and share the app. Signatureorsystem means that app in System image and the app with the same signature can access and share this app, Google recommends not to use this option, because the signature is sufficient, generally this license will be used in an image need to share some specific features of the case.