USER_INITIALIZE broadcast 处理较慢

问题描述


模块:managedprovisioning
Case:
-com.android.cts.devicepolicy.DeviceOwnerPlusProfileOwnerTest#testBindDeviceAdminServiceAsUser_canBindEvenIfProfileNotEnabled

-com.android.cts.devicepolicy.DeviceOwnerPlusProfileOwnerTest#testBindDeviceAdminServiceAsUser_corpOwnedManagedProfileWithManagedProvisioning

-com.google.android.gts.devicepolicy.managedprovisioning.DeviceOwnerProvisioningHostsideTest#testRequiredAppsInManagedProfileForManagedDevice

 

————————————————-
Device log:(等待广播超时)
09-07 09:43:14.935 14570 14596 I SilentProvisioningTest: startActivity with intent: Intent { act=android.app.action.PROVISION_MANAGED_PROFILE (has extras) }
09-07 09:43:25.679 14570 14596 I SilentProvisioningTest: managedProfileProvisionedReceiver.awaitForBroadcast(): failed
Line 22032: 09-07 09:43:11.618 14570 14589 I TestRunner: started: testProvision(com.google.android.gts.managedprovisioning.ManagedProfileProvisioningTest)
Line 25504: 09-07 09:43:25.687 14570 14589 I TestRunner: failed: testProvision(com.google.android.gts.managedprovisioning.ManagedProfileProvisioningTest)
Line 25505: 09-07 09:43:25.687 14570 14589 I TestRunner: —– begin exception —–
Line 25506: 09-07 09:43:25.689 14570 14589 I TestRunner: java.lang.AssertionError
Line 25507: 09-07 09:43:25.689 14570 14589 I TestRunner:     at org.junit.Assert.fail(Assert.java:86)
Line 25508: 09-07 09:43:25.689 14570 14589 I TestRunner:     at org.junit.Assert.assertTrue(Assert.java:41)
Line 25509: 09-07 09:43:25.689 14570 14589 I TestRunner:     at org.junit.Assert.assertTrue(Assert.java:52)
Line 25510: 09-07 09:43:25.689 14570 14589 I TestRunner:     at com.google.android.gts.managedprovisioning.ManagedProfileProvisioningTest.testProvision(ManagedProfileProvisioningTest.java:54)
——————————————————–

 GMS 包中apk 执行广播时间过长08-23 05:34:53.689770 15063 15079 V ActivityThread: SCHEDULE 113 RECEIVER: 0 / ReceiverData{intent=Intent { act=android.intent.action.USER_INITIALIZE flg=0x11000010 cmp=com.google.android.gms/.auth.account.authenticator.WorkAccountAuthenticatorInitializerReceiver } packageName=com.google.android.gms resultCode=0 resultData=null resultExtras=null}

执行7s

08-23 05:35:01.749753 15063 15063 V ActivityThread: Performing receive of Intent { act=android.intent.action.USER_INITIALIZE flg=0x11000010 cmp=com.google.android.gms/.auth.account.authenticator.WorkAccountAuthenticatorInitializerReceiver }:

 这个广播发送时已经结束

ACTION_MANAGED_PROFILE_PROVISIONED = 》  android.app.action.MANAGED_PROFILE_PROVISIONED

需要等待 ACTION_PROFILE_PROVISIONING_COMPLETE 这个广播发出来,才能发送 ACTION_MANAGED_PROFILE_PROVISIONED

但是 ACTION_PROFILE_PROVISIONING_COMPLETE 广播之前 有一个广播android.intent.action.USER_INITIALIZE在正在发送,还没有到 ACTION_PROFILE_PROVISIONING_COMPLETE

查看到 整个Log 都没有ACTION_PROFILE_PROVISIONING_COMPLETE 相关的Log


解决方案:


 Patch improving startup time; fixes to prevent GTS failures; ETS v9_r1 released

 

Patch improving app startup time on Android 8.1 (Oreo MR1)

We’ve added an additional patch to the recommended patch list for O-MR1:

Without this patch on Android 8.1, devices may observe notable app startup time increases. For example, we have noticed occasional increases of over 1 second in the startup times of the Twitter app and increases of several hundred milliseconds in other apps.

Fixes in Android 9 (Pie) and 8.x (Oreo) for a more robust framework – preventing GTS failures

We learned from some partners that the following GTS (Google Mobile Services Test Suite) tests are more likely to fail when run on devices with limited available RAM resources.

  • google.android.gts.devicepolicy.managedprovisioning.ManagedProfileProvisioningHostsideTest tests
  • google.android.gts.devicepolicy.managedprovisioning.DeviceOwnerProvisioningHostsideTest#testRequiredAppsInManagedProfileForManagedDevice
  • Other tests which involve provisioning a managed profile may fail as well

After investigation, we discovered the failure is observed more frequently in such situations because of an existing software bug in the platform as described below, and we strongly recommend you taking the following fixes to avoid unnecessary complications during testing.

Issue description: When in FinalizationController#provisioningFinalized, we launched the DPC (Device Policy Controller) screen, causing the ManagedProvisioning process to go to the background. In certain cases, that causes the system to consider the process empty and kills it before being able to send the ACTION_PROFILE_PROVISIONING_COMPLETE broadcast properly. This causes the tests to fail and disrupt the provisioning flow.

———————————————————

由于google新patch将preFinalizationCompleted接口中的 clearControllerLocked()移除后,mcontroller变量没有置为null。测试过程中再次启动provisioningactivity时,由于mcontroller不是null(Trying to start provisioning, but it’s already running)未能执行startNewProvisioningLocked操作,即未能执行创建新用户流程导致测试失败。

 

微信扫码打赏

作者: RESSRC

个人资源站

发表评论

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

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据