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对上了。那么可以肯定，是逻辑更改造成的问题

逻辑更改

见http://cisys.pt.miui.com/opengrok/xref/v10-p-dipper-dev/packages/apps/ManagedProvisioning/src/com/android/managedprovisioning/task/nonrequiredapps/NonRequiredAppsLogic.java#120

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逻辑是否适用

作者：weiinter105 链接：https://www.jianshu.com/p/a6065587ce43 來源：简书简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。