分类： Android

[6.0r4]GtsAssistantHostTestCases fail

问题描述

 [gts6.0r4]GtsAssistantHostTestCases fail
com.google.android.assistant.gts.AssistantTest#testAssistantOpenFrontCamera
com.google.android.assistant.gts.AssistantTest#testAssistantOpenRearCamera
com.google.android.assistant.gts.AssistantTest#testAssistantTakePhotoWithoutVoiceInteraction
com.google.android.assistant.gts.AssistantTest#testAssistantTakeSelfieWithoutVoiceInteraction

解决方案

这是6.0人新增的case, Hal1的camera会四条全fail, Hal 3的会fail两条可以通过check log （mtkcam-dev1，表示hal1； mtkcam-dev3表示hal3）

[STS201902]MT6580 / MT6739 STS遇到lowmemorykiller detected的大量測试fail

问题描述

MT6580 / MT6739 STS遇到lowmemorykiller detected的大量測试fail，报错信息常常为java.lang.AssertionError: Phone has had a hard reset，查看下host_log是否出現「lowmemorykiller detected」，如下所示

继续阅读“[STS201902]MT6580 / MT6739 STS遇到lowmemorykiller detected的大量測试fail”

[STS-8.1-2019010]run sts-engbuild -m CtsSecurityTestCases -t android.security.cts.SeccompTest#testCTSSwapOnOffBlocked

问题描述

 CtsSecurityTestCases -t android.security.cts.SeccompTest#testCTSSwapOnOffBlocked test fail
03-19 15:16:56 D/ModuleListener: ModuleListener.testFailed(android.security.cts.SeccompTest#testCTSSwapOnOffBlocked, junit.framework.AssertionFailedError: Syscall 224 allowed

CTS8.1R13,R14测试CtsAppSecurityHostTestCases－－－android.appsecurity.cts.AppSecurityTests#testPermissionDiffCert失败

问题描述

 CTS8.1R13,R14测试CtsAppSecurityHostTestCases－－－android.appsecurity.cts.AppSecurityTests#testPermissionDiffCert失败
 对应的fail log为：

继续阅读“CTS8.1R13,R14测试CtsAppSecurityHostTestCases－－－android.appsecurity.cts.AppSecurityTests#testPermissionDiffCert失败”

【CTS】android.host.multiuser.CreateUsersNoAppCrashesTest#testCanCreateGuestUser 测试不过

问题描述

CMASReceiver出现crash
复现步骤:
1. 插卡打开手机.
2. 设置>> 系统 >> 多用户 >> 选择客人模式
4. 在客人模式执行多任务,使用信息应用
5. CMASReceiver出现crash

继续阅读“【CTS】android.host.multiuser.CreateUsersNoAppCrashesTest#testCanCreateGuestUser 测试不过”

Android O/P版本更新patch后刷GSI后无法开机问题

问题描述

     近期大量更新patch后，客户VTS 和 CTS-on-GSI测试，刷GSI无法开机问题，都是由于hidl的改动造成的。这个需要google出新的GSI来解决。
[Related Patch]
o1.mp1 ALPS04304953
o1.mp2 ALPS04308385
     上述两笔patch都有涉及hidl的修改，请客户确认是否上述两笔Patch导致的。

继续阅读“Android O/P版本更新patch后刷GSI后无法开机问题”

GPS 更新豁免流程

GTS updated waiver approval process

 

We introduced Business Logic (BL) based tests as Partner Agreement Enforcement System in GTS 6.0 R1 release in July, 2018.  All Business-logics are hosted on Google servers and can be updated and pushed to production as and when required. This also gives the advantage that partners no longer need to wait for another GTS release to get the fixed test. After the fix is applied on production, a partner can rerun the test and get the test pass.

继续阅读“GPS 更新豁免流程”

GTS 6.0 R4 执行日期改为2019-4-15

GTS 6.0 R4 enforcement date changed and known issues

 

The enforcement date for GTS 6.0 R4 version is changed from April 11th, 2019 to April 15th, 2019. This will align GTS 6.0 R4 enforcement date with February Mandatory Functional Patches Due Dates.

GTS 6.0 R4 can fail for the following four test cases for certain devices with either no camera hardware or no HAL3 Camera:

继续阅读“GTS 6.0 R4 执行日期改为2019-4-15”

GPS 周期翻转问题提醒

Reminder of GPS Week Number rollover issue

 

As we previously announced, the broadcast GPS Week Number will rollover from 1023 to 0 on April 6th, 2019. For those who have issues and cannot prepare a new bug fix build on time due to the build approval logistics, reach out to your Google contact. We will review and provide an exceptional build approval guidance only applicable for GPS Week Number rollover issue.

继续阅读“GPS 周期翻转问题提醒”

STS 测试信息更新及豁免流程

4月份起，SECUTITY PATCH 2019-05-01及之后的版本需要通过所有STS测试。

如有失败项需申请豁免，请参考后文描述；

We’re starting the waiver process for STS from April

We appreciate your collaboration with the new process to roll out the STS (Security Test Suite), a test suite that helps validate whether your Android Software build is vulnerable to  CVEs (common vulnerabilities and exposures) that were reported in the security bulletins up to the reported SECURITY_PATCH.

Starting April, all software builds declaring the SECURITY_PATCH 2019-05-01 or later will only be approved when every STS failure is addressed. We recognize there will be cases where waivers will be needed, so we are planning to align the process dealing with the STS test failures with the process you already are familiar with for other test suites (CTS, GTS) as below.

继续阅读“STS 测试信息更新及豁免流程”

【GTS 6.0_R2】 failed com.google.android.nmgiarc.gts.CarrierServicesTests#testCarrierServicesIsTheDefaultImsPackage

问题描述

  GTS 6.0_R2 failed com.google.android.nmgiarc.gts.CarrierServicesTests#testCarrierServicesIsTheDefaultImsPackage
junit.framework.AssertionFailedError: CS not the default IMS package.

继续阅读“【GTS 6.0_R2】 failed com.google.android.nmgiarc.gts.CarrierServicesTests#testCarrierServicesIsTheDefaultImsPackage”

[cts9.0r6] android.jni.cts.JniStaticTest#test_linker_namespaces

问题描述

 [cts9.0 r6]
CtsJniTestCases
android.jni.cts.JniStaticTest#test_linker_namespaces
fail
 junit.framework.AssertionFailedError: The library "/vendor/lib/libMcClient.so" is a public library but it cannot be loaded: dlopen failed: library "/vendor/lib/libMcClient.so" not found

继续阅读“[cts9.0r6] android.jni.cts.JniStaticTest#test_linker_namespaces”

Google CTS 9.0_r6 CtsIncidentHostTestCases模块有四条case不过

问题描述

  Google CTS 9.0_r6 CtsIncidentHostTestCases模块有四条case不过
1.com.android.server.cts.AlarmManagerIncidentTest#testAlarmManagerServiceDump
2.com.android.server.cts.IncidentdTest#testIncidentReportDumpAuto
3.com.android.server.cts.IncidentdTest#testIncidentReportDumpExplicit
4.com.android.server.cts.IncidentdTest#testIncidentReportDumpLocal

继续阅读“Google CTS 9.0_r6 CtsIncidentHostTestCases模块有四条case不过”

6739在Android P / O / N沒打上patch前確實會大量報出一些STS fail

问题描述

1.請問每次重跑「run sts-engbuild」，每次的STS report中fail的項目都是一模一樣的？

2.請確認這筆patch有正確的合入「ALPS04281123」

我司測試該patch合入後理應就不會有此問題，目前我司內部測試都是全pass的

3.請問是用這包STS測試的？「android-sts-8.1_201902-linux-arm.zip」

继续阅读“6739在Android P / O / N沒打上patch前確實會大量報出一些STS fail”