"Go" Android app signature

Overview

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 to establish a trust relationship between the programs. Certificates are not intended for users to control which programs can be installed. Certificates do not require an authorization center to sign: the use of their own signed certificates on Android applications is completely permissible and universal.

Understanding the Android application signature has several important points:

• All applications must be signed. The system does not install any unsigned programs.
• You can use your own certificate to sign it. No authorization center is required.
• When you want to publish your application for the end user, you must check in a suitable key. You can not publish the program when you also use the SDK tool to check in the debug Key.
• The system detects the validity of the certificate only when the application is installed. If the application fails after the installation, the application will still function correctly.
• You can use the standard tools--keytool and jarsigner--to generate key and sign the APK file.
• Once you have signed the application, be sure to use the Zipalign tool to optimize the final APK package.

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

When you debug your application, the Android SDK tool signs the application for you. Both the ADT plugin for Eclipse and the ant Compilation tool provide two signature mode--debug modes and release modes.

• 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 (with recognized names and passwords). In each compilation, use this debug key to sign the APK file. Because the password is recognized, at each compile time, do not need to prompt you to enter the KeyStore and key password.
• When your program is ready to be published, you must use the key in release mode to sign the APK file. There are two ways to do this:

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

o Use the ADT Export Wizard. If you are using the Eclipse/adt plugin for development, you can use the Export Wizard to compile the program, generate the key (if necessary), and sign the APK, all of which are in the Export Wizard. Once your program is signed, don't forget to run zipalign to perform additional optimizations for the APK.

Signing policy

Some aspects of application signing can affect the development of your application, especially when you plan to publish multiple applications together.

In general, the recommended strategy is to have all programs sign the same certificate throughout the lifetime of the application. Here are a few reasons to do this:

• Application upgrade-When you upgrade your application, you need to sign the same certificate if you want the user to upgrade smoothly. When the system installs an upgrade application, the system will not allow the upgrade if the new version of the certificate matches the old version of the certificate. If you have not signed the appropriate certificate for the version, you will need to specify a new package name for the application when you install it-in this case, the new version installed by the user is treated as a completely new application.
• Application Modularity-If the application requests, the Android system allows applications with the same certificate to run in the same process, so that the system sees them as a single application. Configuring the application in this way allows the user to choose to update each individual module.
• Code/Data permission sharing the--android system provides signature-based permission checks, so if a specific certificate is checked between applications, the functionality can be shared between them. By signing the same certificate with multiple programs and using signature-based permission checks, your program 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 a key.

• If you plan to support an upgrade for a single application, you need to make sure that your key has an expiration date that exceeds the expected application life cycle. It is recommended to use 25 or more years of validity. When your key expires, users will not be able to smoothly update to the new version.
• If you want to sign the same key for multiple unrelated applications, you must make sure that the key is valid beyond the lifetime of all versions of all applications, including programs that might be added to the camp in the future.
• If you want to publish your program on Android Market, key must expire after 2033.10.22. The market server enforces this requirement and is currently ensuring that users can update their programs smoothly.

When designing your application, be sure to keep these points in mind and sign the application with a suitable certificate.

Basic Settings for signatures

Before you begin, you must make sure 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. Alternatively, you can add the path of the Keytool in the JDK to the variable in path.

If you develop on Linux and use the GNU compiler to compile Java, make sure the system uses keytool in the JDK, not 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 symbolic link to make sure it is pointing to the keytool in the JDK.

If you plan to release your app to the public, you'll need to Jarsigner tools. Both Jarsigner and Keytool are included in the JDK.

Debug signature in the mode

The Android Compilation tool provides debug signature mode, making it easier to develop and debug your application, and also to meet the signing requirements of your Android system. When compiling your app using debug mode, the SDK tool calls the Keytool tool to automatically create a debug KeyStore and key. This debug key is then automatically used for the APK signature, so you don't need to use your own key to sign the application package.

The SDK tool uses a pre-defined name/password to create the debug Keystore/key:

• 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. However, any custom debug Keystore/key must use the same name and password as the default debug key (described above). (in Eclipse/adt, the Operation Windows>preferences>android>build implemented.) ）

Note: You cannot publish an application with a debug certificate to the public.

Eclipse User

If you are developing under Eclipse/adt (and you have configured Keytool in the "Basic signature settings" described above), the signature in debug mode is turned on by default. When you run or debug an application, ADT signs with the debug certificate, runs Zipalign, and installs to the selected emulator or device on the connection. The entire process does not require you to participate, provided that ADT can access the Keytool.

Ant User

If you use ant to compile your apk file, you need to add the debug option to the ant command to turn on Debug signature mode (assuming you are using the Android tool to generate the Build.xml file). When you run ant debug 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 whole process doesn't require you to be involved. Read "Other IDE Development: Debug Mode Compilation" To learn more.

Debug Certificate Expiration

The certificate used for signing in debug mode (by default, Eclipse/adt and Ant Compilation) expires 1 years from the date it was created.

When the certificate fails, you get a compile error, and on the ant compilation, the error is as follows:

Debug
[Echo] Packaging bin/samples-debug.apk, and signing it with a debug key ...
[EXEC] Debug Certificate expired on 8/4/08 3:43 PM

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

In order to solve this problem, only delete the Debug.keystore file can be removed. The AVD is stored in the default location: ~/.android/avd (OS x and Linux), C:\Documents and settings\\.android\ (Windows XP), C:\Users\\.android\ (Windows Vista).

The compilation tool regenerates a new KeyStore and debug key The next time it is compiled.

Release signature in the mode

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

1. Get a suitable key

2. Compiling the program in release mode

3. Using the key signing program

4. Align APK package

If you are using Eclipse/adt plug-in development, you can use the Export Wizard to complete the operation of compiling, signing and aligning. Throughout the process, the Export Wizard can even generate a new keystore and key. So, if you use Eclipse, you can jump directly to "use Eclipse ADT to compile and sign."

1. get a suitable key

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

• Personal possession.
• Represents the identity of an individual, company, or organization entity.
• have an expiration date. Validity is recommended for more than 25 years.

If you're posting your app on Android Market, it's important to note that the program will expire after 2033.10.22. You 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 a suitable key, you must use Keytool to generate one. Make sure the Keytool is available, as described in "Basic settings".

To generate a key with Keytool, use the Keytool command and pass in some optional parameters, as shown in the following table.

Warning : Ensure the security of the secret key. Be sure to read "Safely store your keys" to discuss how to ensure the security of your keys and why this is so important to you and your users. In particular, when you generate your keys, be sure to use strong passwords for KeyStore and keys.

Keytool Options	Describe
-genkey	Generate a key pair (public key and key)
-V	Log output
-keystore <keystore-name>.keystore	Name the KeyStore that contains the key
-storepass <password>	Set the KeyStore password. For security reasons, do not include this option on the command line unless you are on a secure computer. If you do not provide, Keytool will prompt you to enter. In this way, your password will not be stored in the shell record.
-alias <alias_name>	Set the alias of key
-keyalg <alg>	Specifies the encryption algorithm to use when generating the key. Supports DSA and RSA.
-dname <name>	Specifies a name that describes who created the key. This value will be populated in the field of the certificate issuer. Note: You do not need to indicate these options on the command line. If not provided, Jarsigner will prompt you to enter each field (Cn,ou, etc.).
-validity <valdays>	Key expiration date, number of days. Note: It is recommended to use a number of 10000 or greater.
-keypass <password>	Key's password. For security reasons, do not include this option on the command line unless you are on a secure computer. If you do not provide, Keytool will prompt you to enter. In this way, your password will not be stored in the shell record.

The following is an example of using the Keytool command to generate a key:

-alias Alias_name-keyalg rsa-validity 10000

Running the above example command, Keytool will prompt you to enter the password for KeyStore and key, and will prompt you to enter the other fields in key. It then generates a file called My-release-key.keystore. KeyStore and key are protected by the password you enter. The keystore contains a key that is valid for 10,000 days. Aliases will be used later, when the program is signed to refer to the current keystore.

For more information about Keytool, please refer to the http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security.

2. compiling The program in Release mode

In order to release the program to the user, you must compile the program in release mode. In release mode, the compiler does not make a default signature, and you need to sign it with a key.

Note : You cannot release unsigned programs or sign a program with Debug key.

Use Eclipse

Right-click the project in the Package explorer and select the Android tools>export Unsigned application package to export an unsigned apk. Then specify the storage location of the unsigned apk. (Alternatively, you can open the Androidmanifest.xml file in Eclipse, open the manifest Tab, and then click Export an unsigned APK).

Note: You can also use the Export Wizard to complete the compilation and signing steps, and refer to "compiling and signing using Eclipse/adt."

Use Ant

If you are using ant, you can start the release mode by adding the release option to the Ant command. For example, if you run ant on a folder that contains build.xml files, the command might look like this:

Ant Release

Generally, the compilation script does not sign the APK when it is compiled. The output file is located in the project's bin/folder, named <your_project_name>-unsigned.apk. Because the APK file is not signed, you must manually sign it with the key, and then use Zipalign to align.

However, the Ant compilation script can also perform signature and alignment operations for you, provided you have KeyStore name and key alias in the Build.properties file. If this information is provided, the compilation script will prompt you to enter the password for KeyStore and key when executing the ant release command, to sign and align the package. The final output file is located in the project's bin/folder, named <your_project_name>-release.apk. If you follow the automatic signature and alignment actions described above, you can skip the manual steps below (steps 3 and 4). To learn how to specify KeyStore and alias in the Build.properties file, refer to "Developing under Other Ides: Release mode compilation".

3. using the key signing program

If you are ready to sign a package, you can use the Jarsigner tool to sign it. As described in "Basic settings", make sure the Jarsigner tool is available. Also, make sure that the KeyStore that contains the key is available.

In order to sign the application, you need to run Jarsigner and reference the app's apk and the KeyStore that contains the key. The following table lists the options that you might use.

Specifies the password for the key.

Based on security considerations, do not include this option on the command line unless you are on a secure computer. If you do not provide, Jarsigner will prompt you to enter. This way, your password will not be stored in the shell record

jarsigner< /strong> Options	description
-keystore <keystore-name>.keystore	Specifies the name of the KeyStore that contains the key
-verbose	Log output
-storepass <password>	Specify Keyst Ore's password. Based on security considerations, do not include this option on the command line unless you are on a secure computer. If you do not provide, Jarsigner will prompt you to enter. This way, your password will not be stored in the shell record
-keypass <password>

The following is an example of using Jarsigner to sign my_application.apk, using the KeyStore created above.

my_application.apk Alias_name

Running the example command above, Jarsigner will prompt you to enter the password for KeyStore and key. It will then modify the APK file, which means that the APK file is now signed. Note: You can use a different key to sign the APK multiple times.

To verify that the APK file is signed, you can use the following command:

$ jarsigner-verify my_signed.apk

If the APK is signed correctly, Jarsigner output "jar verified". If you want to learn more details, you can try these commands:

$ jarsigner-verify-verbose my_application.apk

Or

$ jarsigner-verify-verbose-certs my_application.apk

The above command, adding the-certs option, will display the "cn=" line that describes who created the key.

Note : If you see "Cn=android Debug", this means that the APK file uses the Android SDK to generate the name of the Debug key sign. If you want to publish your program, you must replace the debug key with your own key to sign it.

For more information about Jarsigner, please refer to the http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security.

4. align APK Package

Once you have signed the APK file using the key, be sure to run zipalign to align. This tool allows the uncompressed data to be aligned in a specific byte. With 4-byte alignment, performance can be optimized. When aligned, the Android system can read files through mmap (), even if they contain binary data, rather than copying all the data from the package. The benefit is that the random read memory consumption is reduced when the program is run.

Zipalign is provided by the Android SDK and is included under the tools/folder. To align the signed apk, do the following:

Your_project_name your_project_name. apk

The-V flag indicates the start log output (optional). 4 indicates the aligned bytes (do not use a number other than 4). The first file parameter is your signature after apk (input), the second file parameter is the destination apk file (output). If you want to overwrite an already existing apk, add the-f flag.

Note : Before you use the Zipalign optimization package, the APK must be signed with the key. If you sign after the zipalign operation, the alignment operation is white.

For more information, please read the documentation for the Zipalign tool.

Use Eclipse/adt Compiling and signing

If you are using the Eclipse/adt plugin, you can use the Export Wizard to export a signed apk (you can even create a new keystore if needed). The Export Wizard does all the work for you to interact with Keytool and Jarsigner, and uses the GUI to sign the application instead of the manual compilation, signing, and alignment actions mentioned above. Once the wizard has finished compiling and signing, it also uses zipalign to perform the alignment of the package. Because the Export Wizard uses Keytoo and Jarsigner. You should make sure that they are available, as described in "Basic signature settings".

Securely store your keys

Maintaining the security of the key is extremely important. If you let someone else use your key, or if you put keystore and password in an unsafe place so that third-party personnel find and use it, then your authentication and user trust will be compromised.

If a third party does not take your key without your permission, that person can sign and publish the application and maliciously replace or attack your genuine program. This person can also sign and publish applications, use your name to attack other programs or systems themselves, or destroy or steal user data.

The developer's reputation relies on the correct storage of your key until it expires. Here are a few tips for storing your keys safely:

• Set strong passwords for keys and keystore.
• When you use Keytool to generate the key, do not add the-storepass and-keypass options to the command line. If you do this, you can get your password in the shell record.
• Similarly, do not add the-storepass and-keypass options to the command line when you use Jarsigner to sign the program.
• Don't give the key to someone else or lend it to someone, and don't let the unauthorized person know your keystore and key's password.

All in all, it's safe to use as long as you have security awareness when creating, using, and storing keys.

"Go" Android app signature