本文主要是介绍GTS fail之GtsPackageSignatureTest和GtsApexSignatureVerificationTest，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
1. Fail项具体详情
2. Google为何增加测试项
3. 解决方法
1. Fail项具体详情
run gts -m GtsPackageSignatureTest -t android.security.cts.PackageSignatureTest#testPackageSignatures fail
| Test | Result | Details |
|---|---|---|
| android.security.cts.PackageSignatureTest#testPackageSignatures | fail | junit.framework.AssertionFailedError: These packages should not be signed with a well known key: [com.android.hotspot2.osulogin, com.android.wifi.resources]arm64-v8a GtsPackageSignatureTest |
run gts -m GtsApexSignatureVerificationTest -t android.appsecurity.cts.ApexSignatureVerificationTest#testApexPubKeyIsNotWellKnownKey
| arm64-v8a GtsApexSignatureVerificationTest | ||
| Test | Result | Details |
|---|---|---|
| android.appsecurity.cts.ApexSignatureVerificationTest#testApexPubKeyIsNotWellKnownKey | fail | 3 expectations failed: 1. com.android.vndk.v31 must not use well known pubkey expected to be false at android.appsecurity.cts.ApexSignatureVerificationTest.testApexPubKeyIsNotWellKnownKey(ApexSignatureVerificationTest.java:158) 2. com.android.appsearch must not use well known pubkey expected to be false ... 1 more 3. com.android.wifi must not use well known pubkey expected to be false ... 1 more |
从case的名称上来看，两类case都是针对Apex(Android pony express)做的针对性测试，而且从字面上来看都是需要加强对签名Key的强化，而且第二类ApexPubKey其实有点眼熟，之前CTS有处理过类似的问题，具体可参考之前记录的该篇Cts 失败项之CtsAppSecurityHostTestCases-CSDN博客，本文简单梳理下GtsPackageSignatureTest。
2. Google为何增加测试项
为什么Google会增加case来强制让我们更新Apex的sign key呢，不明真相的我们可能会觉得多此一举，个人最初也会有类似的感受，但直到我查了下GTS的release notes，就觉得还是需要重视sign key的，原来是CVE漏洞的需要，这里也没有能力对CVE展开，就贴一下供大家参考，有Google partner账号的，可以继续对漏洞做进一步的了解，这里我就不瞎带路了。
3. 解决方法
因为GtsApexSignatureVerificationTest处理方案就是重新给对用的apex生成相应的avb pub key， 只要参考Cts 失败项之CtsAppSecurityHostTestCases-CSDN博客，
直接说下GtsPackageSignatureTest的签名问题，打开com.android.hotspot2.osulogin, com.android.wifi.resources对应的bp
以com.android.hotspot2.osulogin为例，Android.bp的内容如下：
android_app {name: "OsuLogin",defaults: ["wifi-module-sdk-version-defaults"],static_libs: ["androidx.legacy_legacy-support-v4"],resource_dirs: ["res"],srcs: ["src/**/*.java"],sdk_version: "system_current",
//把默认的签名修改为platform签名
- certificate: ":com.android.hotspot2.osulogin.certificate",
+ certificate: ":platform", apex_available: ["com.android.wifi","test_com.android.wifi",],
}android_app_certificate {name: "com.android.hotspot2.osulogin.certificate",certificate: "certs/com.android.hotspot2.osulogin"
}
这里提一个快速验证是否生效的办法，编译完OS检查OTA target_file的META目录下apexkeys.txt文件中对应的Apex package的签名是否有带platform签名的路径即可，随便举例类似：
name="com.android.cellbroadcast.apex" public_key="packages/apps/CellBroadcastReceiver/apex/com.android.cellbroadcast.avbpubkey" private_key="packages/apps/CellBroadcastReceiver/apex/com.android.cellbroadcast.pem" container_certificate="build/make/xx/xxx/releasekey.x509.pem" container_private_key="build/make/xx/xxx/releasekey.pk8" partition="system_ext"
以上自己做个记录，也分享给遇到这个问题朋友。
这篇关于GTS fail之GtsPackageSignatureTest和GtsApexSignatureVerificationTest的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
