Android requires that each application be signed with the developer’s digital keys to enforce signature permissions and application requests to use shared user ID or target process.

The core Android platform uses four keys to maintain security of core platform components. The keys are located in build/target/product/security:

• platform: a key for packages that are part of the core platform.

• shared: a key for things that are shared in the home/contacts process.

• media: a key for packages that are part of the media/download system.

• testkey: the default key to sign with if not otherwise specified.

Building an Android OS image using make will sign all .apk files using the test-keys. Since the test-keys are publicly known, anybody can sign their own .apk files with the same keys, which may allow them to replace or hijack system apps built into your OS image. For this reason it is critical to sign any publicly released or deployed Android OS image with a special set of release-keys that only you have access to.

To generate your own unique set of release-keys, run these commands from the root of your Android tree

subject='/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'

mkdir ~/.android-certs

for x in testkey platform shared media; do \

`./development/tools/make_key ~/.android-certs/$x "$subject"; \`

done

$subject should be changed to reflect your organization's information

Its a 2 step process, where we need to include our custom releasekey path for the device build

1. Save the keys generated in above steps in a folder mkdir device///security/ cp ~/.android-certs/* device///security/
2. Include relekey path to dlt.mk PRODUCT_DEFAULT_DEV_CERTIFICATE := $(LOCAL_PATH)/security/testkey

After above steps, all the AOSP applications, which are part of the image are signed with vendorcertificates.

Its also a 2 step process:

1. Create Application specific folder with its own Android.mk and apk file. ls device///< App_Name> device///<App_Name>/ Android.mk device///<App_Name>/*.apk
2. Modify device///<App_Name>/Android.mk, to include below line: LOCAL_CERTIFICATE := device///security/platform

At the end of above steps application can be built with vendor certificate, But is still not part of system.img For it to be part of system.img, add below in dlt.mk PRODUCT_PACKAGES+=<App_Name> Note: As per, https://source.android.com/devices/tech/ota/sign_builds#certificates-keys. The build can use only private keys that are not password protected. Important Links: More information on Application signatures can be found at : https://source.android.com/devices/tech/ota/sign_builds https://boundarydevices.com/android-security-part-1-application-signatures-permissions/ https://cfig.github.io/2015/10/15/signing-keys-in-android/ https://wladimir-tm4pda.github.io/porting/release_keys.html

Ans: Building an Android OS image using make will sign all .apk files using the test-keys, located under build/target/product/security Since AOSP is open source and the test-keys are publicly known, anybody can sign their own .apk files with the same keys, which may allow them to replace or hijack system apps built into your OS image. To avoid this, its necessary to sign the apk's with our own secret keys.

Ans: By default all apk's are signed with build/target/product/security/testkey, unless LOCAL_CERTIFICATE is defined in the Android,mk of the application. For example: Settings application, needs to be signed with platform key instead of test-key, hence packages/apps/Settings/Android.mk has LOCAL_CERTIFICATE := platform As a result, in default case: Settings application will be signed with build/target/product/security/platform,
and with custom vendor certificate, i.e. with PRODUCT_DEFAULT_DEV_CERTIFICATE := $(LOCAL_PATH)/security/testkey in dlt.mk, Settings application will be signed with device///security/platform.

Ans: It tells the signing script that this APKs are already signed and should not be signed again. For example, In android_x86 code Terminal application has LOCAL_CERTIFICATE:=PRESIGNED, and thus during build we are not resigning them with default AOSP keys or with vendor keys.