CTS问题分析6
Posted codeking100
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CTS问题分析6相关的知识，希望对你有一定的参考价值。
遇到一个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逻辑是否适用
以上是关于CTS问题分析6的主要内容，如果未能解决你的问题，请参考以下文章