Environment:
The Android OS environment being used is as follows:
URL: https://www.nxp.jp/design/design-center/software/embedded-software/i-mx-software/android-os-for-i-mx...
Android Version: Android Q10.0.0_2.6.0 (Linux 5.4.70 kernel)
Objective:
We would like to create an environment where the NXP certificates located in the following folder are replaced with custom certificates:
(path/to/)/android_build/devices/fsl/common/security/
media, networkstack, platform, shared, testkey
and
releasekey (this one is custom-added)
Problem:
When we place a password-protected certificate and attempt to build, the following error occurs:
> java.lang.IllegalArgumentException: illegal object in getInstance: org.bouncycastle.asn1.DLSequence
> at org.bouncycastle.asn1.ASN1Integer.getInstance(ASN1Integer.java:44)
> at org.bouncycastle.asn1.pkcs.PrivateKeyInfo.<init>(PrivateKeyInfo.java:134)
> at org.bouncycastle.asn1.pkcs.PrivateKeyInfo.getInstance(PrivateKeyInfo.java:83)
> at com.android.signapk.SignApk.readPrivateKey(SignApk.java:277)
> at com.android.signapk.SignApk.main(SignApk.java:1091)
Note: This issue does not occur if the certificate is not password-protected.
Question 1:
In the Android make process, there is no prompt for password input. How should the password be set?
Question 2:
We believe that the prebuilt JDK 9 does not support password-protected certificates.
Has it been confirmed that JDK 9 can be used to build with password-protected certificates?
Or should we assume that Android Q10.0.0_2.6.0 (Linux 5.4.70 kernel) does not support password-protected certificates?
When I sign an apk with a passworded certificate with sign_target_files_apks after making with a non-passworded certificate, I get a prompt for a password.
However, the same error occurs when the password is entered.
This seems to occur when using a pre-built JDK 9, and it is believed that JDK 9 does not support password-protected certificates.
In the Android OS build steps, JDK 9 is set in the path when running source build/envsetup.sh.
Thus, we believe that using JDK 9 is the correct approach.
When using JDK 19 installed on a PC to run sign_targetfiles_apk, this issue does not occur.