d004f41188
Delegate the resetting of the INTERACT_ACROSS_PROFILES app-op to DevicePolicyManager, which knows whether it should be pre-granted and knows to apply it equally across all users in the profile group. Further unit tests for DevicePolicyManagerInternal will be added in b/175440570 when we have the better infra for that. The CrossProfileAppsServiceImpl changes look more complex than they are. They consist of the following: - Inclusive language changes to 'allowlist' - Static imports of permissions to improve readability - Previously, the setInteractAcrossProfilesAppOp method would set the app-op for every user within the profile group of the 'calling user'. However, given that we are now exposing this as a server-side internal API where we need to pass in a user ID (from AppOpsService), we don't necessarily have the guarantee that the 'calling user' is in the same profile group. So we split it up: the client-side API and AIDL API still set the app-op for the calling profile group, whereas the internal API sets the app-op for every user within the profile group of the provided user. The changes simply abstract away references to the 'calling user ID'. Fixes: 166561076 Bug: 175440570 Test: atest services/robotests/src/com/android/server/pm/CrossProfileAppsServiceImplRoboTest.java --verbose -c Test: manual Change-Id: I2181fe66022aaf6c3e6d784c0569d2f41ab66537
This folder is for Robolectric tests inside the platform.
To add a test class annotate it as follows:
@RunWith(FrameworkRobolectricTestRunner.class)
@Config(manifest = Config.NONE, sdk = 26)
@SystemLoaderClasses({ClassUnderTest.class, DependencyClasses.class})
@SystemLoaderPackages({"com.android.server.yourmodule"})
Robolectric loads some classes that it decides from versioned jars of the framework. Since we are
part of the framework some of our classes get loaded from these jars. This is NOT what we want, we
want to test against what we wrote in the tree. Because of this we use a custom test runner,
FrameworkRobolectricTestRunner, that bypasses these jars and loads certain classes from the system
class loader.
To specify which classes to load use either @SystemLoaderClasses or @SystemLoaderPackages. In
practice:
* You MUST put the class under test here.
* If you encounter any exceptions that might be caused by a different version of the class being
loaded, such as NoSuchMethodException, put the class involved in the exception in this annotation
and try again.
Check Android.mk file for more info.