谷歌GMS认证一般哪些测试不容易通过，怎么整改
- 供应商
- 深圳市华商检测技术有限公司
- 认证
- CTC
- 11
- gms
- 11
- 深圳
- 11
- 手机号
- 13244700087
- 联系人
- 余世伟
- 所在地
- 深圳市光明区光明街道翠湖社区光明大街150号伟创业大厦606
- 更新时间
- 2019-08-31 15:51
前言 这段时间接手了cts认证相关的工作，在这里整理一下相关的问题。（同时感谢同事对此总结提供的帮助及补充） 1.0 google waive项目 这个部分的整理，根据cts版本来进行分类，以r13为基础版本。 1.1 r13 1.1.1 ctspermission2testcasesandroid.permission2.cts.permissionpolicytest#testplatformpermissionpolicyunaltered 报告分析，而后使用该分析报告，向google申请豁免 1.1.2 ctssecuritytestcasesandroid.security.cts.stagefrighttest#teststagefright_bug_23270724 报告分析，而后使用该分析报告，向google申请豁免 1.1.3 ctswebkittestcasesandroid.webkit.cts.webchromeclienttest#testonjsbeforeunloadiscalled 该项为chrome60版本的问题，使用59版本即可测过。也可使用nexus机器跑出的报告申请豁免。 2.0 常规项目 2.1 ctsappsecurityhosttestcases 2.1.1 android.appsecurity.cts.adoptablehosttest#testapps > 相关问题 a. android.appsecurity.cts.adoptablehosttest#testejected b.android.appsecurity.cts.adoptablehosttest#testpackageinstaller c. android.appsecurity.cts.adoptablehosttest#testprimarystorage 这项测试主要是测试internal storage和adoptedstorage的功能及apk安装在不同storage下的运行情况。测试手法建议如下。 1. 使用大容量高性能的tf卡 2. 清理phone storage 3. 重启后测试 2.2 ctscarrierapitestcases 2.2.1android.carrierapi.cts.carrierapitest#testhascarrierprivileges 该项为白卡测试，需要使用特定的卡片测试。 2.3 ctshostsidenetworktests 2.3.1 com.android.cts.net.hostsidevpntests#testappdisallowed 该项需要在ipv6并且可以连接google服务器的环境中测试。 2.4 ctsnettestcases 2.4.1 android.net.cts.dnstest#testdnsworks 该项需要在ipv6并且可以连接google服务器的环境中测试。 2.4.2android.net.cts.multinetworkapitest#testnativedatagramtransmission 有两种报错。 eproto (protocol error)：表示wifi环境连接不上server eperm (operation not permitted)：表示在手机段使用了翻墙软件，导致其底层认为该测试网络为虚拟网络。 所以该项需要使用可以直接翻墙的wifi环境 2.5 ctsjnitestcases 2.5.1 android.jni.cts.jnistatictest#test_linker_namespaces 从android7.0开始不允许app动态链接使用非ndk的so文件，所以也不允许预置so到/system/lib,/system/lib64,/vendor/lib,/vendor/lib64等目录下供app使用，请您打包您的私有so：/system/lib/libandroidmem.so到app中或者其他路径即可。 2.6 ctslibcoretestcases 2.6.1libcore.java.text.olddateformattest#test_formatljava_lang_objectljava_lang_stringbufferljava_text_fieldposition > 同类问题 同模块下 libcore.java.text.olddateformattest#test_formatljava_util_date libcore.java.text.olddateformattest#test_parselstring org.apache.harmony.tests.java.text.messageformattest#test_formatljava_lang_objectljava_lang_stringbufferljava_text_fieldposition org.apache.harmony.tests.java.text.messageformattest#test_formattocharacteriteratorljava_lang_object、 org.apache.harmony.tests.java.text.messageformattest#test_parseljava_lang_string org.apache.harmony.tests.java.util.datetest#test_tolocalestring 不同模块下 ctstexttestcases android.text.format.cts.dateutilstest#testformatsamedaytime 该项需要改为12小时制进行测试。厂商如果要求默认为24小时制也是ok的，实验室反馈可以在测试前手动更改。 2.7 ctsthemehosttestcases 2.7.1 android.theme.cts.themehosttest#testthemes 该项是由于内部客制化需求导致的，请从以下四个角度进行分析和修改。 1.不可以修改alps\frameworks\base\core\res\res\values下的style.xml和theme.xml，如果有定制需求，可以修改styles_device_default.xml来达到修改ui的目的。 2.不可以修改alps\frameworks\base\core\res\res\中原有的图片，layout，dimens，attrs，colors等所有资源或属性值， 可以新增资源或属性，不要修改名称或内容，也不要删除。 3. 不可以修改alps\frameworks\base\core\java\android\widget目录下所有framework default的控件的源代码，若要客制化，请重载对应的函数。 4. 不可以修改alps\frameworks\base\core\java\android\text\format\dateutils.java文件中的privatestatic string formatelapsedtime(stringbuilder recyle, stringformat, long minutes, longseconds)函数，此处会影响cts中的chronometer的显示效果，如需客制化，请重载该函数。 2.8 ctsjankdevicetestcases 2.8.1 android.jank.cts.ui.ctsdevicejankui#testscrolling 该问题有三种可能因素。 1. 修改了以下三个文件，导致fail，请回退修改。 /frameworks/base/core/java/android/view/view.java /frameworks/base/core/java/android/view/viewgroup.java /frameworks/base/core/java/android/view/viewrootimpl.java 2. 小内存型号预装过多apk导致开机时，内存占用过多，建议客户在cts版本中移除不必要的预置。 3. 全面屏patch导致，全面屏patch导致的问题。 修改vendor/mediatek/proprietary/frameworks/opt/fullscreenswitchservice/src/com/mediatek/fullscreenswitch/fullscreendatahelper.java文件，将com.android.cts.usepermission，android.ui.cts，android.jank.cts三个包名设为默认打开全面屏效果。当然不要全部默认打开所有cts测试项的 2.9 ctsdpitestcases 2.9.1 android.dpi.cts.aspectratiotest#testaspectratio 该项为18:9屏导致的fail项，因为cts要求的长宽比应在1.333到1.86之间，而该屏比例为2.0，需要根据各自平台申请对应全屏patch并打开对应的宏。 3 器件相关问题 3.1 camera相关 首先有一个主要的思路就是，只测两颗摄像头，保证前后各有一颗被测试到即可，多余的摄像头，请在代码中屏蔽，不进行cts和verifier测试。 由于这个模块问题比较多，后续会单独写一篇来加以介绍和修改。 android.hardware.camera2.cts.robustnesstest#testmandatoryoutputcombinations 修改picture size和 preview size，之后编译libcam.paramsmgr android.hardware.camera2.cts.imagereadertest#testyuvandjpeg 修改featuretable，去掉1080p以上的分辨率配置，例如"1680x1248" android.hardware.cts.cameragltest#testcameratosurfacetexturemetadata junit.framework.assertionfailederror: too many frame intervals outof frame rate bounds: 98, limit 4 此项是camera帧率项，取出log,观察是那颗摄像头fail，修改相应摄像头的驱动文件，不清楚如何修改的，可以问驱动同事帮忙，或者请fae协助修改。 3.2 lcm 3.2.1 ctsviewtestcasesandroid.view.cts.displayrefreshratetest#testrefreshrate 该项是测试屏幕理论帧率与实际帧率的误差是否在2以内。 部分平台存在着全面屏支持问题，会导致屏幕帧率上限被锁死在58左右。如果这样适当下调理论值即可。 另外这边的修改会影响到gts的帧率测试，改完后也验证一下。 3.3 memory 3.3.1 ctslibcoretestcaseslibcore.java.io.fileinputstreamtest#testskiponlargefiles 这一项测试的是内部存储的性能。首先，保证整3g以上的剩余空间。其次，需要保证足够的硬件性能，可以使用androbench进行测试。如果性能较差，建议寻求厂商优化。 |
展开全文