Repurpose the "Profile Owner was granted access to device identifiers"
to "Profile Owner of an Organization-owned device".
The old method now throws an exception, as it should not be called by
anything other than ManagedProvisioning (which is changed in this topic).
The new method now provides the functionality the old method provided,
and there's a new permission associated with it.
No functionality has been added or removed in this CL beyond that.
Bug: 138709470
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testDeviceIdAttestationForProfileOwner
Change-Id: I9914e8220213898d0c6b3499af8897e3a6f23819
See build/soong/README.md for more information.
Also converts the rest of frameworks/base/tools/streaming_proto.
Bug: 122332340
Test: m checkbuild
Change-Id: I87c500c5464fb1722b4b518d89065f5e1ee29a97
(cherry picked from commit 45c0d71e77)
In order to allow inclusion of device identifiers in the key attestation
record generated by the profile owner, the platform needs an explicit
signal that it is OK for the profile owner to access those identifiers.
Add a system-privileged method to the DevicePolicyManager that allows
system applications, as well as Managed Provisioning to indicate that the
profile owner may access those identifiers.
In the DevicePolicyManagerService the following has changed:
* The OwnerInfo now contains a flag indicating whether the profile owner
was granted access to the device identifiers or not.
* The permission check for use of the Device ID Attestation flags in
generateKeyPair has been adjusted to allow profile owner (or its
delegate) to use them, if device identifiers access has been granted.
* A couple of utility methods have been added to ease checking of
profile owner presence for a user and whether the profile owner can
access device identifiers.
Additionally, a new adb command has been added to give this grant to an
existing profile owner for testing purposes.
Bug: 111335970
Test: Manual, using TestDPC + ADB command.
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: Additional CTS tests, see cts change in the same topic.
Change-Id: I05f2323d5edacd774cd3ce082ee9c551100f4afd
This is useful because logs are batched every 1.5-2hrs if there are
not enough logs to fill up a batch. The command is throttled at
10 seconds as a spam prevention measure.
Bug: 62251154
Test: in adb shell run dpm force-network-logs. Observe a new batch
being created in the phone directory
/storage/emulated/0/Android/data/com.afwsamples.testdpc/files/. Also
observe a fresh batch is being displayed on the phone in the TestDPC
app, under "Retrieve network logs".
Change-Id: I5ff9d5c78497ea81533b5248816b4d6e160d338f
This command fetches the most recent batch of the logs
and makes them available to the DPC. Primary purpose is
to make security logging testable in CTS without having
to either wait for 2 hours or relying on implementation
details.
To prevent the user from abusing the command and
annoying the DPC, it is throttled if run more than once
per 10 seconds. Waiting happens in Dpm command.
Test: adb shell dpm force-security-logs
Bug: 70886042
Bug: 62251154
Change-Id: Ic5acd5a3e5c3b060881385c472df2b972961b626
Freeze period is defined as a pair of calendar dates (recurring annually)
during which the system should block any incoming system updates, including
security patches. They are set on top of existing system udpate policy
types (automatic, windowed, postpone) such that outside the freeze
periods existing policy semantics will still apply. They are created to
allow admin to keep their device fleet from any destabilizing changes during
critical period of the year, for example during Christmas sales period.
Device Owner can set several freeze periods, although to prevent the device
from not receiving OTAs indefinitely, each single freeze period is
restricted to be at most 90 days, and adjacent freeze periods need to be at
least 60 days apart. To properly enforce these restrictions, any freeze
periods the device previously experienced is tracked by DevicePolicyManager
and are validated against any new policy. This is to deal with corner cases
such as the admin repeatedly set a short but overlapping freeze period on a
rolling basis, hence bypassing the 90-day freeze period restriction.
Test: runtest -c com.android.server.devicepolicy.SystemUpdatePolicyTest frameworks-services
Bug: 64813061
Change-Id: I2864192797dc194edd9c183b881da6cfe3fdba5e
Without this, exec()ing these fails.
Found with `grep -L bin/sh $(grep -Rl Script)`
Bug: None
Test: exec()ed each of these scripts; I no longer get "exec format
error" for any of them.
Change-Id: I47db5007e5cc14ab91eb846b7bffecb925d37874
Add test method to remove admins that declare
FLAG_TEST_APP without informing them.
The method will also remove the device and profile
owner status of the admin.
Bug: 28027468
Change-Id: Idb4d3299a9c6595c94bfb424546cd8a384131835
Add explicit modelling of provisioning state so that integration
of management provisioning flows with packages such as setup-wizard
are cleaner, and can be more direct. Previously we relied upon
USER_SETUP_COMPLETE secure setting and HOME intents to signal intent,
but this is not very clear and can be fragile.
Bug: 25858670
Change-Id: Idc56a040f710c3aee281db420f21717da3960722
- setDeviceOwner() now takes a user ID. (We can infer it from Binder, but
we still need it for the dpm command.)
- Change broadcast target UID for DO to the DO user
- Start the DO user on boot complete.
TODO Investigate whether this is actually the good timing.
TODO Prevent the DO user from being killed
Bug 23827706
Change-Id: I227dbd444f1f4e94d98c317489d151554fe79d91
Added 'Success' at the beginning of the command output every time
it didn't fail, so that we can easily check the output in tests.
The command is brand new, only used by us on CTS tests, so this
shouldn't break anybody.
Bug: 17312478
Change-Id: Ie67bf5b2f44e658e7009e5bd87f8cb81be515584
Required for GTS tests. Needed to relax the restriction that
only root user can run 'pm create-user' as GTS tests can't
get root permissions.
Bug: 17312478
Change-Id: I1841286ddf51756c73018c087a5f29afeb5b9f15
Adds new adb command to execute DevicePolicyManager tasks. First subcommand
allows us to set a device owner on a provisioned device (provided no accounts
are associated with the device). This is required as GTS tests run on provisioned
devices. We plan to add more subcomands required for new GTS tests, such as the
ability to create a managed profile.
Bug: 17312478, 17316711
Change-Id: I2613178ea82a6c6268e7f8012e74c4a852fea0d4
