2c68dadb20
Let's have several separate contexts instead of doing strange things
with package names in one monolithic context representing every single
user on the device at once, sometimes multiple times in the same call.
Syntax looks like:
runAsCaller(callerContext, dpms, (dpm) -> {
assertSomething(dpm.doSomething(caller, param));
});
When a caller calls into DevicePolicyManager here's what happens:
PRE
- a new DevicePolicyManager is created with the caller context
- service context callingIdentity is saved
- the callingUid, callingPid, and callingPermissions are added to the service context
TEST
- client-side test code interacts with DevicePolicyManager using the caller context
- server-side coder under test runs as DevicePolicyManagerService using the service context
POST
- service context callingIdentity is restored to what it was before the test.
This should be easier to reason about.
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: I148e3f298b0a958639ce261e9cf91f6eb49fae4d