Android relies on cryptographic signatures to enforce system security. The system will absolutely refuse to install or execute any APK that has not been digitally signed. Furthermore, the key used to sign the APK dictates the level of privilege the app holds within the operating system.
When you compile AOSP, the build system automatically handles the complex process of signing every single APK before packaging it into the final system.img.
Specifying the Certificate
When defining an Android application in Android.bp (or Android.mk), you must explicitly tell the build system which cryptographic key to use via the certificate property.
android_app {
name: "Settings",
srcs: ["src/**/*.java"],
certificate: "platform",
platform_apis: true,
}
The Four Standard Keys
AOSP includes four standard cryptographic keys, located in build/target/product/security/. Each key grants radically different permissions to the apps signed by it.
1. platform
This is the most powerful key in the system. Apps signed with the platform key (like the Settings app or the SystemUI) run with the same User ID as the core OS framework. They have total, unrestricted access to hidden Android APIs and can perform highly privileged operations (like factory resetting the device or rebooting the kernel).
2. shared
Used for applications that need to share data or processes with the core Contacts and Calendar providers. It allows different apps to safely run in the same security sandbox.
3. media
Used for applications that are part of the media/download subsystem. It grants specific access to hardware media codecs and internal storage directories.
4. testkey
This is the default key used if you do not specify a certificate in your module definition. It acts like a standard, unprivileged third-party app downloaded from the Play Store. It is heavily sandboxed and requires the user to explicitly grant runtime permissions (like Camera or Location access).
APK Signature Schemes (v1, v2, v3, v4)
When the AOSP build system signs an APK using the specified certificate, it utilizes the apksigner tool. Over the years, Android has evolved its signing schemes to combat vulnerabilities:
- v1 (JAR signing): The legacy method. It relies on standard Java cryptographic hashes, but it does not protect the entire ZIP file format, making it vulnerable to certain "Zip Slip" attacks.
- v2 (Full APK Signature): Introduced in Android 7.0. It calculates a cryptographic hash over the entire binary byte-stream of the APK. If a single byte is altered maliciously, the signature instantly breaks and the OS will refuse to install the app.
- v3 and v4: Newer schemes that support key rotation (allowing developers to update their cryptographic keys over time without locking users out of updates) and highly optimized streaming installations.
# You can manually verify the signature of an APK via ADB or local terminal
apksigner verify --print-certs out/target/product/generic/system/app/Settings/Settings.apk