About the Android application APK program signature detailed

Source: Internet
Author: User
Tags manual require

Certificates are not used to allow users to control which programs can be installed, nor do certificates require authorization centers to sign them. In the Android system, applications using their own signed certificates are completely permissible and common.

There are several key points about the Android application signature:

• All applications must be signed. The system does not install any programs that do not have a signature. This rule applies to any place where the Android system is running, whether it's a real machine or an emulator. Therefore, you must sign the program before running/debugging the program on the emulator or the real machine.
• You can use your own certificate to sign. No authorization center is required.
• You must check in an appropriate key when you want to publish the application for the end user. Debug Key that is checked in with the SDK tool is not available when the program is published.
• The system detects the validity of a certificate only when the application is installed. If the application does not expire after installation, the application will still function.
• You can use standard tools--keytool and Jarsigner to generate key and sign apk files.
• Once the application is signed, be sure to use the Zipalign tool to optimize the final APK package.
Debug Key and Release key
When you debug an application, the Android SDK tool automatically signs the application. Both the ADT plug-in and the ant compilation tool for Eclipse provide two signature mode--debug mode and release mode. You can use the debug mode when developing and testing. In debug mode, the compiler uses the Keytool tool embedded in the JDK to create a keystore and a key (including recognized names and passwords). The debug key is used to sign the APK file each time it is compiled. Because the password is recognized, every time you compile, you do not need to be prompted to enter KeyStore and key passwords.

When the program is ready to be published, the key must be used in release mode to sign the APK file. There are two different ways to do this:

1. Use Keytool and Jarsigner in the command line.

In this method, you first need to compile an unsigned apk. Then use the Jarsigner (or similar tool) and manually sign the key for APK. If you do not have the appropriate key, you can run Keytool to manually generate your own keystore/key.

2. Use the ADT Export Wizard.

If you are using the Eclipse/adt plug-in for development, you can use the Export Wizard to compile the program, generate the key (if necessary), and sign the APK, all in the Export Wizard. Once the program is signed, do not forget to run zipalign to perform additional optimizations for the APK.

About signing policies
Some aspects of application signing may affect application development, especially when you intend to publish multiple applications together. In general, the recommended strategy is that all programs are signed with the same certificate throughout the life of the application. This is mainly due to the following considerations:

• Application Upgrades-When an application is upgraded, you need to sign the same certificate if you want the user to have a smooth upgrade. When a system installs an upgrade application, the system will allow upgrades if the new version of the certificate matches the old version of the certificate. If you do not have the appropriate certificate checked for a new version of the program, you will need to specify a new package name for the application at installation time. In this case, the new version that the user installs will be treated as an entirely new application.
• Application Modularity-If the application declares that the Android system allows applications that have the same certificate to be executed in the same process. So the system will think of them as a single application. Configuring the application in this way allows the user to choose to update each individual module.
• Code/Data rights sharing the--android system provides signature-based permission checking, so if you have a specific certificate signed between applications, you can share functionality between them. With multiple programs that have the same certificate, and with a self-signed permission check, programs can share code and data in a secure way.
• If you plan to support an upgrade of a single application, you need to ensure that the key has a validity period beyond the expected application lifecycle. It is recommended to use a 25 year or longer period of validity. When the key expires, the user will not be able to smoothly update to the new version.
• If you have signed the same key for multiple unrelated applications, make sure that the key is valid beyond the lifecycle of all versions of all applications, including programs that may be added to this camp in the future.
• If you want to release the program on the Android market, the key must be valid after 2033.10.22. The market server enforces this requirement to ensure that users can update their programs smoothly.
When designing an application, be sure to consider these and use a suitable certificate to sign the application.

Configuring a signature environment
The first step is to ensure that Keytool is available to the SDK Compilation tool. You can generally tell the SDK compilation tool how to find Keytool by setting the JAVA_HOME environment variable. You can also add a keytool path in the JDK to a variable in path. If you are developing on Linux and using the GNU compiler to compile Java, make sure the system is using the Keytool in the JDK, not the GCJ. If Keytool is already in path, it may be a symbolic link to/usr/bin/keytool. In this case, check the target of the symbolic link to make sure it is pointing to the keytool in the JDK.

If you want to publish your application, you also need the Jarsigner tool. Both Jarsigner and Keytool are included in the JDK.

Signature in debug mode
The Android compiler tool provides the debug signature pattern, making it easier to develop and debug applications, and to meet the requirements of the Android system's signature. When you compile the app using debug mode, the SDK tool invokes the Keytool tool to automatically create a debug KeyStore and key. The Debug key is then automatically used for apk signatures, so that you do not need to manually sign the application package.

About the KeyStore used by the SDK tools:

keystore Name: "Debug.keysotre"
keystore Password: "Android"
key alias: "Androiddebugkey"
Key Password: "Android"
cn: "Cn=android Debug,o=android,c=us"
If necessary, you can change the location and name of the debug Keystore/key, or provide a custom debug Keysotre/key (in Eclipse/adt, by modifying the windows>preferences> Android>build configuration Implementation). However, any custom debug Keystore/key must use the same name and password as the default debug key (described above).

Note: You cannot publish an application that has a debug certificate to the end user.

Eclipse User: If you are developing under Eclipse/adt (and have already configured Keytool as described above), the signature is turned on by default in debug mode. When you run or debug an application, ADT uses the debug certificate to sign it, runs Zipalign, and installs it to the selected emulator or connected device. The whole process does not require manual intervention.

Ant User: If you are using ant to compile the apk file, you will need to add the debug option in the Ant command to turn on the debug signature mode (assuming you are using the Android tool to generate the Build.xml file). When you run the Ant debug Compiler, the compilation script generates a Keystore/key and signs the APK. The script then aligns the APK with the Zipalign tool. The whole process does not require manual intervention.

Debug certificate Expiration
The certificate used for signing in debug mode expires after 1 years from the date it was created. When the certificate is invalidated, a compilation error is obtained and the ant error is as follows:

View Sourceprint?
1 Debug:

2 [echo] packaging bin/samples-debug.apk, and signing it with a debug key ...

3 [EXEC] Debug certificate expired on 8/4/08 3:43 PM
The Android console will also see a similar error in the Eclipse ADT. To solve this problem, simply delete the Debug.keystore file. The default storage location for this file is:

OS X and Linux:~/.android/
Windows Xp:c:/documents and Settings/.android/
Windows Vista:c:/users/.android/
After deletion, the compilation tool regenerates a new KeyStore and debug key at the next compile time.

Sign in release mode
When an application is ready to be published to another user, it needs:

• Get an appropriate key
• Compiling programs in release mode
• Using key signing programs
• Align APK packages
If you are using the Eclipse ADT Plug-in development, you can use the Export Wizard to complete the compilation, signing, and alignment operations. Throughout the process, the Export Wizard can also generate a new keystore and key.

About the key generation
In order for the program to be signed, an appropriate key must be available. This key should have the following characteristics:

• Personal possession.
• Representing the identity of an individual, company, or organization entity.
• There is an expiration date. The validity period is recommended for more than 25 years. When you publish a program on Android Market you need to be aware that the program will expire after 2033.10.22. Cannot upload an application and its key is valid until this date.
• Debug key not generated by the Android SDK tool.
If you do not have the appropriate key, you need to use Keytool to generate one. To generate a key with Keytool, you can use the Keytool command and pass in some optional parameters

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.