遇到一个Android P相关的问题，和原来CTS/GTS 问题分析1的表现是一样的，但是将 这个修复cp过来，发现不生效，仍然报错，因此记录一下
问题初探
测试命令: run gts -m GtsGmscoreHostTestCases -t com.google.android.gts.devicepolicy.managedprovisioning.DeviceOwnerProvisioningHostsideTest#testRequiredAppsInManagedDevice
报错堆栈：
09-28 13:54:41 W/XtsHostTestBase: java.lang.AssertionError: Should have at least one packages to handle Intent { act=android.intent.action.MAIN cat=[android.intent.category.HOME] }, found []
Expected: a value greater than <0>
but: <0> was equal to <0>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at com.google.android.gts.managedprovisioning.AfwRequiredAppsTest.assertAndGetPackagesHandleIntent(AfwRequiredAppsTest.java:450)
at com.google.android.gts.managedprovisioning.AfwRequiredAppsTest.assertRequiredAppsInDeviceOwnerOrManagedUser(AfwRequiredAppsTest.java:490)
at com.google.android.gts.managedprovisioning.AfwRequiredAppsTest.assertRequiredAppsInDeviceOwner(AfwRequiredAppsTest.java:474)
at com.google.android.gts.managedprovisioning.AfwRequiredAppsTest.testRequiredApps_DeviceOwner_withGms(AfwRequiredAppsTest.java:124)
at java.lang.reflect.Method.invoke(Native Method)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:52)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:148)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:142)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:764)
上面还有：
09-28 01:54:32.486 18930 18956 D ManagedProvisioning: Deleting package [com.mi.android.globallauncher] as user 0
问题分析
可见，E10这个机器自定义的桌面被删掉了，导致case fail。在OverlayPackagesProvider.java中调试一下，结果如下：
OverlayPackage.png
可见我们得到的是vendor/google/products/gms_overlay下面的资源，那么首先怀疑的是不是和上面链接的一样,overlay顺序问题导致资源加载不正确？
那么我们在本地加log看一下：
在build/core/package_internal.mk中添加log
ifdef enforce_rro_enabled
ifneq ($(PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS),)
static_only_resource_overlays := $(filter $(addsuffix %,$(PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS)),$(package_resource_overlays))
ifneq ($(static_only_resource_overlays),)
package_resource_overlays := $(filter-out $(static_only_resource_overlays),$(package_resource_overlays))
LOCAL_RESOURCE_DIR := $(static_only_resource_overlays) $(LOCAL_RESOURCE_DIR)
ifeq ($(package_resource_overlays),)
enforce_rro_enabled :=
endif
endif
endif
else
LOCAL_RESOURCE_DIR := $(package_resource_overlays) $(LOCAL_RESOURCE_DIR)
$(warning ------>a1)
$(warning ------>$(LOCAL_RESOURCE_DIR))
$(warning ------>a2)
endif
注意这个log不是在lunch时出现的，而是在packages/apps/ManagedProvisioning这里编译时出现的
国内版log
build/make/core/package_internal.mk:136: warning: ------>a1
build/make/core/package_internal.mk:137: warning: ------>miui/config-overlay/v6/common/packages/apps/ManagedProvisioning/res packages/apps/ManagedProvisioning/res
build/make/core/package_internal.mk:138: warning: ------>a2
国际版
在根目录执行deploy
Deploy menu... pick a combo:
1. cn
2. cn_chinaunicom
3. cn_chinatelecom
4. cn_chinamobile
5. cn_cta 6. cn_chinamobile-cta 7. global Which would you like? [cn] 7 global ============================================ MIUI_CURRENT_CUST_VARIANT=global ============================================ 重新回到packages/apps/ManagedProvisioning进行mm
build/make/core/package_internal.mk:136: warning: ------>a1
build/make/core/package_internal.mk:137: warning: ------>miui/config-overlay/v6/global/packages/apps/ManagedProvisioning/res miui/config-overlay/v6/common/packages/apps/ManagedProvisioning/res packages/apps/ManagedProvisioning/res
build/make/core/package_internal.mk:138: warning: ------>a2
看着overlay的顺序完全正确，为了再确定下，我们用Android Studio看一下ManagedProvisioning.apk的资源，发现：
ManagedProvisioning资源.png
果然，资源已经顺利被aapt打包到相应apk里面了，前面的怀疑是错的，和原来不是一个问题。
那么剩下的还有两个怀疑点，1. apk的逻辑有问题或改动 2.资源加载出错；我们调试的时候发现加载的资源id是
ManagedProvisioning资源id.png
和上面的id对不上，那么肯定是资源就没加载对。然后突然想到，我调试的时候attach的是system_process进程，那么会不会加载的是framework的资源呢，查看framework-res.apk，果然：
framework-res资源id.png
id对上了。那么可以肯定，是逻辑更改造成的问题
逻辑更改
99 public Set<String> getSystemAppsToRemove(int userId) { 100 if (!shouldDeleteSystemApps(userId)) { 101 return Collections.emptySet(); 102 } 103 104 // Start with all system apps 105 Set<String> newSystemApps = mUtils.getCurrentSystemApps(mIPackageManager, userId); 106 107 // Remove the ones that were already present in the last snapshot only when OTA 108 if (!mNewProfile) { 109 newSystemApps.removeAll(mSnapshot.getSnapshot(userId)); 110 } 111 ComponentName deviceAdminComponentName; 112 try { 113 deviceAdminComponentName = mParams.inferDeviceAdminComponentName( 114 mUtils, mContext, userId); 115 } catch (IllegalProvisioningArgumentException ex) { 116 // Should not happen 117 throw new RuntimeException("Failed to infer device admin component name", ex); 118 } 119 // Get the packages from the black/white lists 120 Set<String> packagesToDelete = mDevicePolicyManager.getDisallowedSystemApps( 121 deviceAdminComponentName, userId, mParams.provisioningAction); 122 123 // Retain only new system apps 124 packagesToDelete.retainAll(newSystemApps); 125 126 return packagesToDelete; 127 } 70 /** 71 * Computes non-required apps. All the system apps with a launcher that are not in 72 * the required set of packages will be considered as non-required apps. 73 * 74 * Note: If an app is mistakenly listed as both required and disallowed, it will be treated as 75 * disallowed. 76 * 77 * @param admin Which {@link DeviceAdminReceiver} this request is associated with. 78 * @param userId The userId for which the non-required apps needs to be computed. 79 * @param provisioningAction action indicating type of provisioning, should be one of 80 * {@link ACTION_PROVISION_MANAGED_DEVICE}, {@link 81 * ACTION_PROVISION_MANAGED_PROFILE} or 82 * {@link ACTION_PROVISION_MANAGED_USER}. 83 * @return the set of non-required apps. 84 */ 85 @NonNull 86 public Set<String> getNonRequiredApps(@NonNull ComponentName admin, int userId, 87 @NonNull String provisioningAction) { 88 final Set<String> nonRequiredApps = getLaunchableApps(userId); 89 // Newly installed system apps are uninstalled when they are not required and are either 90 // disallowed or have a launcher icon. 91 nonRequiredApps.removeAll(getRequiredApps(provisioningAction, admin.getPackageName())); 92 // Don't delete the system input method packages in case of Device owner provisioning. 93 if (ACTION_PROVISION_MANAGED_DEVICE.equals(provisioningAction) 94 || ACTION_PROVISION_MANAGED_USER.equals(provisioningAction)) { 95 nonRequiredApps.removeAll(getSystemInputMethods()); 96 } 97 nonRequiredApps.addAll(getDisallowedApps(provisioningAction)); 98 return nonRequiredApps; 99 } 195 private Set<String> getVendorRequiredAppsSet(String provisioningAction) { 196 final int resId; 197 switch (provisioningAction) { 198 case ACTION_PROVISION_MANAGED_USER: 199 resId = R.array.vendor_required_apps_managed_user; 200 break; 201 case ACTION_PROVISION_MANAGED_PROFILE: 202 resId = R.array.vendor_required_apps_managed_profile; 203 break; 204 case ACTION_PROVISION_MANAGED_DEVICE: 205 resId = R.array.vendor_required_apps_managed_device; 206 break; 207 default: 208 throw new IllegalArgumentException("Provisioning type " 209 + provisioningAction + " not supported."); 210 } 211 return new ArraySet<>(Arrays.asList(mContext.getResources().getStringArray(resId))); 212 } 可见，ManagedProvisioning将这部分逻辑放到了framework中，所以取的是framework的资源；
总结
ManagedProvisioning.apk也会随着大版本升级改动，我们进行CTS测试时需要注意这一点，尤其是其越来越与framework依赖时，我们要注意观察以往的overlay逻辑是否适用