Android uses signatures in two places:

  • Every .apk in the firmware image must be signed. Android’s Package Manager uses an .apk signature in two ways:

    • To replace an application, the new version must be signed with the same key as the old one.

    • If two or more applications share a user ID (to share data, etc.), they must be signed with the same key.

  • OTA update packages must be signed with one of the system keys or the installation process fails.

Running an Android system signed with the test-keys publicly distributed is dangerous. It allows third party applications access to functionality reserved for system applications by signing them with the publicly available certificates.

Digi Embedded for Android test-keys are under device/digi/common/security. When generating your images, the build system uses these test-keys. This is a valid approach during development, but not for a final production release or for deployment as the keys are publicly known.

It is critical to sign your final artifacts with private release-keys that only you have access to.

To completely secure your device, see Digi TrustFence for Android.

To do show follow these steps:

See OTA and APK keys for more information.

1. Generate your release keys

A key consists of two files:

  • The private key, with extension .pk8. It is protected by a password. You must kept it secret.

  • The certificate, with extension .x509.pem. It is the public part of the key, so you can distribute it. Android uses it to verify the signature of an update package.

To generate your private release-keys, follow these steps:

  1. Set up your environment and install the sources. If you have not already done so, see Set up your development workstation and Install Digi Embedded for Android.

  2. Change to the directory where the source code is installed.

    $ cd dea-11.0-r2
  3. Create a directory to store the keys. For example, at your home directory ~/android-certs.

    $ mkdir ~/android-certs
  4. Define your organization’s information in a environment variable. For example:

    $ subject='/C=US/ST=Minnesota/L=Hopkins/O=Acme/OU=Acme/CN=Acme/emailAddress=android@acme.com'
  5. Generate the release keys inside ~/android-certs:

    $ for x in releasekey platform shared media networkstack; do \
        ./development/tools/make_key ~/android-certs/$x "$subject"; \
      done

    Enter a password for every individual key once prompted.

    Your certificate files (.x509.pem) and encrypted private keys (.pk8) are stored in ~/android-certs.

You are responsible for storing and protecting the release keys. Loss of the private keys will result in not being able to sign artifacts with the affected keys.

Now, you can use these generated private keys to sign your target-files zip.

2. Sign target_files zip

The target_files is a zip file containing a snapshot of a particular software release. It includes everything needed to create signed OTA packages, release images, etc.

This package is generated by the Android build system using its test-keys (see Build your custom distribution). Android provides a python script, build/tools/releasetools/sign_target_file_apks, to replace those test-keys with your own private keys.

To sign with your private release key:

  1. You must have the target_files zip from a make dist build (see Build your custom distribution) and your private keys

  2. Change to the directory where the source code is installed.

    $ cd dea-11.0-r2
  3. Sign the target-files zip with your private key:

    $ sign_target_files_apks \
      -o \
      -d ~/android-certs \
      out/dist/ccimx8xsbcpro-target_files-<build_id>.zip \
      out/dist/signed-target_files.zip
    • -o replaces the certificate (public key) used by OTA package. That is, /system/etc/security/otacerts.zip file in the final image will contain your keys instead of the default ones.

    • -d indicates that you are using default key mapping and the private keys in the following directory, ~/android-certs in the example.

The resulting out/dist/signed-target_files.zip file already includes your release keys, instead of the test-keys. With it you can Generate release custom images and Create a signed OTA package.

To establish a secure environment where the access to the private key is restricted, see Release in a secure environment.