When creating admin users, default
UserRestrictions do indeed apply, so updating
the javadoc.
Test: N/A
Bug: 143491938
Change-Id: Id495599abd4ddee100ca2c761d3b420fff315482
Fix a potential race condtion when the same message object
is being enqueued by two threads.
Bug: 150263007
Bug: 154867444
Test: atest android.os.cts.MessageQueueTest
Change-Id: Id79448ba8719479cbdb054f2cdd172fdcbe86d47
(cherry picked from commit 96a6fec4d6)
Background
* Secondary users should be disabled
when the device is an organization-owned
managed profile device.
* This is because supporting secondary
users would complicate the semantics of
user restrictions.
Changes
* Add DISALLOW_ADD_USER as a base restriction
when the device is an organization-owned
managed profile device.
* Handle removal case when the device is no
longer in this mode.
* Remove the ability of other admins to apply
DISALLOW_ADD_USER.
Manual Testing Steps
* Provision an organization-owned managed
profile device.
* Check Settings > System > Multiple users
and verify that a user cannot be added.
* Check WP TestDPC 'Set user restrictions
on parent' and verify 'Disallow add user'
is not present.
Bug: 155281701
Test: Manual testing
atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I83348fc8b854cef20383803124000540b5b130cb
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
(cherry picked from commit e0624c7a40)
An earlier CL with benchmarks has shown that sending strings as UTF-8
is 50% faster for US-ASCII strings, and still 68% faster for complex
strings referencing higher Unicode planes. (So an improvement in
both cases!)
Since code across the OS still makes heavy assumptions about Parcel
strings typically being UTF-16, we need to carefully migrate
Parcelables by hand, which is what this CLs begins doing.
Bug: 154436100
Test: manual
Change-Id: I9a675473e0ce3a4a5c5e305dd851b40bb1560e1c
ServiceSpecificException might be thrown, but it is not
actionable by the caller. Hence hide the comment.
Fixes: 151156841
Test: none
Change-Id: I07836fe2c5cc361fa81f6fc24851ad2b0721591b
(cherry picked from commit d3abb6d385)
Merged-In: I07836fe2c5cc361fa81f6fc24851ad2b0721591b
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
ServiceSpecificException might be thrown, but it is not
actionable by the caller. Hence hide the comment.
Fixes: 151156841
Test: none
Change-Id: I07836fe2c5cc361fa81f6fc24851ad2b0721591b
