针对CTS,GTS测试过程中,在profile_provisioning流程分析与常见解决方案

[DESCRIPTION]

由于目前所有的手机都要求支持Android for work, 客户在测试CTS,GTS过程中,经常在profile_provisioning的过程中出错,这边对经常出错的地方进行分析,并提供对应的解决方案

[SOLUTION]


其中就以GTS测试中testProvision这个测试fail为例分析profile_provisioning的流程
一般遇到的fail log为

 

1.ManagedProfileProvisioningTest.java中call

 

2.startProvisioningAndWait ()这个方法:
a.启动PreProvisioningActivity去provisioning
b.等待broadcast-ACTION_MANAGED_PROFILE_PROVISIONED ,timeout为10s
c.如果10s没有等到broadcast,那么就return null,就会打出error log:
SilentProvisioningTest:managedProfileProvisionedReceiver.awaitForBroadcast(): failed”);
xref: /cts/common/device-side/util/src/com/android/compatibility/common/util/devicepolicy/provisioning/SilentProvisioningTestManager.java

 

3.waitManagedProfileProvisioning()这个方法:
a.注册ACTION_MANAGED_PROFILE_PROVISIONED和ACTION_MANAGED_PROFILE_ADDED的BroadcastReceiver
b.调用pollProvisioningResult() check profile_provisioning是否有完成,即是否有接到ACTION_PROFILE_PROVISIONING_COMPLETE的broadcast,timeout为120s
c.如果120s之后没有等待broadcast,pollProvisioningResult()==false,就会打出error log:
SilentProvisioningTest: ManagedProvisioning doesn’t return result within 120 seconds

 

4.pollProvisioningResult() 方法:

 

5. ACTION_PROFILE_PROVISIONING_COMPLETE这个broadcast要在ACTION_MANAGED_PROFILE_PROVISIONED这个broadcast之前,当profile_provisioning完成之后,DpcReceivedSuccessReceiver就会发送这个ACTION_MANAGED_PROFILE_PROVISIONED broadcast,具体代码流程如下:
xref: /packages/apps/ManagedProvisioning/src/com/android/managedprovisioning/finalization/DpcReceivedSuccessReceiver.java

 

 

总结,Provisioning的过程就是通过PROVISION_MANAGED_PROFILE这个intent叫起PreProvisioningActivity,然后开始provisioning,并且等待ACTION_PROFILE_PROVISIONING_COMPLETE这个广播,这个广播被接收后,会send ACTION_MANAGED_PROFILE_PROVISIONED的广播,最终完成整个provisioning流程。
测试OK的log:
Line 5253: 07-25 07:58:57.450 12762 12797 I SilentProvisioningTest: startActivity with intent: Intent { act=android.app.action.PROVISION_MANAGED_PROFILE (has extras) }
Line 5297: 07-25 07:58:57.517 12762 12762 I StartProvisionActivity: result callback class name com.android.compatibility.common.util.devicepolicy.provisioning.SilentProvisioningTestManager$1@92ca4a
Line 40624: 07-25 08:02:15.531 16286 16286 D ManagedProvisioning: ACTION_PROFILE_PROVISIONING_COMPLETE broadcast received by mdm
当cts,gts fail之后,可以通过adb shell dumpsys activity log x on或者将ActivityManagerServiceConfig.java中的DEBUG_ALL=true 打开ams debug开关,根据流程排查,看到底log指向的是provisioning中的哪个部分。

其中目前客户遇见最多的就是因为没有在规定时间内接收到广播,有时候的现象就是概率性通过。
此时:
1.首先先确认测试时使用的是user load
2.可以在打开ams debug之后的测试device_logcat_test的log中以broadcasts为关键字,看是否是因为广播太多,造成拥堵,致使广播未能及时接收到
solution: 去掉设备中预制的过多的apk,将未接收到的broadcast在ams中变成前台广播。
针对O版本,将某个broadcast变成前台广播的方法如下:
以Broadcast sticky为关键字,

 

3.当然也有时候并不是因为太多广播堵塞造成,而是因为是low_ram的项目,客制化了services/core/java/com/android/server/am/ActivityManagerConstants.java中MAX_CACHED_PROCESSES造成系统更加激进的kill process。
该MAX_CACHED_PROCESSES默认为32

作者: RESSRC

个人资源站

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.