The Android system requires that all programs be digitally signed before they can be installed. The Android system uses this certificate to identify the author of the application and establish a trust relationship between the programs. Certificates are not used by users to control which programs can be installed. Certificates do not need to be signed by an authority: using self-signed certificates on Android applications is perfectly allowed and common.

There are several important points to understand Android application signature:

·All applications must be signed. The system will not install any unsigned program.

·You can use your own certificate to sign. No authorization center is required.

·When you publish your application to end users, you must check in an appropriate key. You cannot use the DebugKey checked in by the SDK tool when publishing the program.

·The system only detects the validity period of the certificate when installing the application. If the certificate expires after the application is installed, the application will still work normally.

·You can use standard tools - Keytool and Jarsigner - to generate keys and sign apk files.

·Once you have signed your application, be sure to use the zipalign tool to optimize the final APK package.

The Android system will not install and run applications that are not properly signed. This rule applies wherever Android is running, whether it's a real device or an emulator. It is for this reason that you must sign your program before running/debugging it on an emulator or real device.

When you debug the application, the AndroidSDK tools sign the application for you. Eclipse's ADT plug-in and Ant compilation tool both provide two signature modes - Debug mode and Release mode.

·When developing and testing, you can use Debug mode. In Debug mode, the compilation tool uses the Keytool tool embedded in the JDK to create a keystore and a key (containing a recognized name and password). During each compilation, use this DebugKey to sign the apk file. Since the password is recognized, you do not need to be prompted to enter the keystore and key password every time you compile.

·When your program is ready for release, you must use the key to sign the apk file in Release mode. There are two ways to do this:

1. Use Keytool and Jarsigner on the command line. In this method, you first need to compile an unsigned apk. Then use Jarsigner (or similar tool) to manually sign the apk with your key. If you don't have a suitable key, you can run Keytool to manually generate your own keystore/key.

2. Use the ADT export wizard. If you develop using the Eclipse/ADT plug-in, you can use the export wizard to compile the program, generate a key (if needed), and sign the apk, all within the export wizard. Once your program is signed, don't forget to run zipalign to perform additional optimizations on the apk.

Signing Strategy

Certain aspects of application signing may affect application development, especially if you plan to release multiple applications together. Generally speaking, the recommended strategy is to sign all programs with the same certificate throughout the life of the application.

There are several reasons why you should do this:

·Application upgrade - when you upgrade your application, if you want users to upgrade smoothly, then you You need to sign the same certificate. When the system installs an upgrade application, the system will only allow the upgrade if the new version's certificate matches the old version's certificate. If you do not sign the version with the appropriate certificate, you will need to give the application a new package name when you install it - in this case, the new version installed by the user is treated as a completely new application .

Application modularization - The Android system allows applications signed with the same certificate to run in the same process if the application requests it, so that the system treats them as a single app. By configuring the application this way, the user can choose to update each individual module.

·Code/data permission sharing - The Android system provides signature-based permission checking, so if applications are signed with specific certificates, they can be shared with each other. Function. By having multiple programs signed with the same certificate and using signature-based permission checking, your programs can share code and data in a secure way. Another important factor in determining the signature strategy is how to set the validity period of the key.

·If you plan to support upgrades of a single application, you need to ensure that your key has a validity period that exceeds the expected application life cycle. A validity period of 25 years or more is recommended. When your key expires, users cannot smoothly update to the new version.

·If you want to sign multiple unrelated applications with the same key, then you must ensure that the validity period of the key exceeds the life cycle of all versions of all applications, including the possibility of adding this key in the future. Camp program.

·If you want to publish your program on AndroidMarket, the key must be valid after 2033.10.22. Market servers enforce this requirement, currently to ensure that users can smoothly update their programs.

When you design your application, be sure to keep these points in mind and use an appropriate certificate to sign the application.

Basic settings for signing

Before you begin, you must ensure that Keytool is available to the SDK compilation tool. In most cases, you can tell the SDK compilation tool how to find Keytool by setting the JAVA_HOME environment variable. In addition, you can also add the path of Keytool in the JDK to the PATH variable.

If you develop on Linux and use the GNU compiler to compile Java, please make sure that the system uses Keytool in the JDK instead of gcj. If Keytool is already in your PATH, it may be a symbolic link to /usr/bin/keytool. In this case, check the target of the symlink to make sure it points to Keytool in the JDK. If you plan to release your application to the public, you will also need the Jarsigner tool. Both Jarsigner and Keytool are included in the JDK.

Signing in Debug mode

The Android compilation tool provides Debug signing mode, which makes it easier to develop and debug applications, and also meets the signing requirements of the Android system. When compiling your app in Debug mode, the SDK tool will call the Keytool tool to automatically create a Debug keystore and key. This Debugkey is then automatically used to sign the apk, so you don't need to use your own key to sign the application package.

The SDK tool uses the predefined name/password to create Debugkeystore/key:

·Keystore name: "debug.keysotre"

·Keystore password: "android"

·Key alias: "androiddebugkey"

·Key password: "android"

·CN: "CN=AndroidDebug,O=Android, C=US”

If necessary, you can change the location and name of Debugkeystore/key, or provide a custom Debugkeysotre/key. However, any custom Debugkeystore/key must use the same name and password as the default Debugkey (described above). (In Eclipse/ADT, operate Windows>Preferences>Android>Build to implement.)

Note: You cannot publish applications signed with a Debug certificate to the public.

Eclipse users

If you develop under Eclipse/ADT (and have configured Keytool according to the "Basic Settings for Signature" described above), signing in Debug mode is turned on by default. of. When you run or debug your application, ADT will sign it with a Debug certificate, run zipalign, and install it to the emulator of choice or a connected device. The whole process does not require your participation, provided that ADT can access Keytool.

Ant users

If you use Ant to compile your apk file, you need to add the debug option to the ant command to enable the Debug signature mode (assuming you are using the build generated by the android tool .xml file). When you run antdebug to compile your program, the compilation script generates a keystore/key and signs the apk. The script then uses the zipalign tool to align the apk. The entire process does not require your participation. Read "Developing in Other IDEs: Compiling in Debug Mode" for more information.

Debug certificate expiration

The certificate used for signing in Debug mode (the default is Eclipse/ADT and Ant compilation) will expire after 1 year from the date it was created.

When the certificate expires, you will get a compilation error. On Ant compilation,

the error is as follows:

debug:

[echo]Packagingbin/samples-debug.apk,andsigningitwithadebugkey...

[exec]DebugCertificateexpiredon8/4/083:43PM

In Eclipse/ADT, on the Android console you You will see a similar error.

In order to solve this problem, just delete the debug.keystore file. The default storage location of AVD is: ~/.android/avd (OSX and Linux), C:DocumentsandSettings\.android (WindowsXP), C:Users\.android (WindowsVista).

The next time you compile, the compilation tool will regenerate a new keystore and Debugkey.

Signing in Release mode

When your program is ready to be released to other users, you must:

1. Obtain a suitable key

p>

2. Compile the program in Release mode

3. Use the key signing program

4. Align the APK package

If you are using For Eclipse/ADT plug-in development, you can use the export wizard to complete operations such as compilation, signing, and alignment. Throughout the process, the export wizard can even generate a new keystore and keys. Therefore, if you use Eclipse, you can skip directly to "Compiling and signing with Eclipse ADT".

Getting a Suitable Key In order to sign a program, first, you must have a suitable key. The key refers to:

·Personally held.

·Represent the identity of an individual, company or organizational entity.

·Have an expiration date. The validity period is recommended to be more than 25 years.

If you publish your program on AndroidMarket, one thing to note is that the validity period of the program needs to be after 2033.10.22. You cannot upload an application whose key is valid before this date.

·Debugkey is not generated by the AndroidSDK tool.

If you do not have a suitable key, you must use Keytool to generate one. Make sure Keytool is available as described in "Basic Setup".

In order to use Keytool to generate a key, use the keytool command and pass in some optional parameters, as shown in the following table.

Warning: Keep your keys safe. Be sure to read Storing Your Keys Securely for a discussion of how to keep your keys secure and why this is important to you and your users. In particular, when you generate your keys, be sure to use strong passwords for the keystore and key.