Generate an APK for the android project in eclipse and sign the APK

The lazy way to generate an APK is:
If you have 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. This APK file is signed by the debug user by default.

If you want to manually sign the APK:

1. Significance of Signature
To ensure that each application Program The developer's legal ID prevents some open vendors from confusing and replacing installed programs by using the same package name. We need to make a unique signature for the APK file we released, ensure the consistency of the versions we release each time (for example, automatic update will not be unable to be installed because of version inconsistency ).
2. Signature steps
A. Create a key
B. Use the key generated in step a to sign the APK
3. Specific operations
Method 1: sign the APK under the command line (principle)
Keytool.exe (located in jdk1.6.0 _ 24 \ JRE \ release (located in the directory of jdk1.6.0 _ 24 \ bin). Add the directories of the above two software to the environment variable path and open CMD and enter
D: \> keytool-genkey-alias demo. keystore-keyalg RSA-validity 40000-keystore demo. keystore/* Description:-genkey generates the key-alias demo. keystore alias demo. keystore-keyalg RSA uses RSA Algorithm Encrypt the signature-validity 40000 validity period 4000 days-keystore demo. keystore */D: \> jarsigner-verbose-keystore demo. keystore-signedjar demo_signed.apk demo.apk demo. keystore/* Description:-details of the signature output by verbose-keystore demo. keystore location-signedjar demor_signed.apk demo.apk demo. the keystore is officially signed. in the three regions, demo_signed is the file after the signing, and demo.apk is the file to be signed and the keystore demo. keystore. */
Note: by default, demo.apk under the binlog of the androidproject uses the debug user signature. Therefore, you cannot use the preceding steps to re-sign the file. The correct steps should be: Right-click the project and choose anroid tools-export unsigned application package to use the above signature for the exported APK.
Method 2: Use eclipse to export the signed APK
Eclipse can directly export the final APK with a signature, which is very convenient and recommended. The steps are as follows:
Step 1: export.

Step 2: Create the keystore, enter the location and password for the keystore export, and remember the password. It will be used in the next use existing keystore.

Step 3: Enter the keystore information, password of some APK files, expiration time, and organization unit information.

Step 4: generate an APK file with a signature, and this will end.

Step 5: Use the previously generated keystore to sign the next release.

 

Step 6: Next, next, end!
Method 3: Use intellij idea to export the signed APK
The steps are basically the same as those in eclipse. The approximate operation path is menu tools> andrdoid> export signed APK.
4. After signing, use zipalign to optimize your APK file.
Unsigned APK cannot be used or optimized. After signing, apkgu song recommends using zipalign.exe (in the Android-SDK-Windows \ tools directory) to optimize it:
D: \> zipalign-V 4 demo_signed.apk final.apk
As shown above, zipalign can align uncompressed data in the APK file on the 4-byte boundary (4 bytes are a good value), so that the Android system can use MMAP () (please check the purpose of this function) function reading files can achieve high performance in reading resources,
PS: 1. alignment on the boundary of four bytes means that, in general, it refers to the result that the compiler reads four bytes as a unit. In this case, the CPU can perform efficient and fast access to variables (not aligned before ).
2. root of alignment: The davlik virtual machine in the Android system uses its proprietary Dex format. The Dex structure is compact. In order to improve the running performance, you can further use alignment to further optimize it, but the size usually increases.
5. Influence of signature on your app.
You can't just make one app. You may have a grand strategic project. If you want to plug in every field of life, service, game, and system, you can't just make one app, google recommends that you 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, the impact may be:
1) app upgrade . Upgrade software with the same signature can normally cover older versions of the software. Otherwise, the system will find that the new version of the signature certificate is inconsistent with the old version of the signature certificate, and the new version is not allowed to be installed successfully.
2) app Modularization . The Android system allows identical apps to run in the same process. If they run in the same process, they are equivalent to the same app, but you can upgrade them separately, this is an app-level modular approach.
3) allowCodeAnd data sharing . Android provides a signature-based permission tag. With the allowed settings, we can access and share different apps as follows:
Androidmanifest. xml: <permission Android: protectionlevel = "normal"/>
The protectionlevel tag has four values: normal (default), dangerous, signature, and signatureorsystem. In short, normal is a low risk. All Apps cannot access or share this app. Dangerous is highly risky, and all apps can access and share this app. Signature means that apps with the same signature can access and share this app. Signatureorsystem indicates that the app in the Image System 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 is used when a specific function needs to be shared in an image.