Currently only device owner can set global user restrictions.
With this CL ENSURE_VERIFY_APPS will be global no matter who
enforces it, DO or PO.
To make it possible for system apps to check who enforces a
particular restriction in this case a new API method is added
to UserManager: getUserRestrictionSources which returns a list
of users who enforce the restriction.
Bug:31000521
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.UserRestrictionsTest (ag/1732744)
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/pm/UserRestrictionsUtilsTest.java
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerServiceMigrationTest.java
Test: installed M on a Nexus5x device, created a managed profile with some user restrictions, and checked that after upgrading M->O all restrictions are preserved and split correctly into base, global and local.
Change-Id: I543d3ec9ef0cf2b730da6f7406021c0bba43b785
The GraphicsEnvironment class is given information during application
start, and makes it available to EGL/GLES/Vulkan loaders that don't
have easy access to the VM or to the application Context. Currently
only the driver path is handled, but the existing support for setting
library paths (for Vulkan extensions) and cache directory information
should move here.
Bug: 33531483
Test: various apps w/ and w/o driver package installed
Change-Id: I5820d3d1301d5461e10706f551b268c54d4f8926
It's not clear this actually makes much difference on modern
devices/drivers. With updatable graphics drivers, we'd have to be able
to unload the preloaded driver from processes that don't use the
system driver, which is additional complexity and risk.
On bullhead and sailfish, meminfo actually showed slightly more memory
available while sitting at launcher just after boot with this change
than previously. Looking at detailed stats, the differences appeared
to mostly within run-to-run variation, but there wasn't evidence of a
regression.
Bug: 33531483
Test: boot through lockscreen/launcher
Change-Id: I1892302c1750cdbeaf5b9979f8da4dc6bd7b3e75
This will hopefully avoid blaming sysui for ANRs when the system
is hosed.
Test: Manual, build, push, wait for time to change
Change-Id: I1661ac1a997ad8917b449dd175229d8b77f583c9
Bug: 34095835
Test: reproduced the bug in b/34095835 to ensure that it is covered by
the test. Manually ran the tests.
Change-Id: I28a887341906dc443e1a854ddba51cd1b4daeead
This CL allows a reason to be specified when installing a package. The
install reason is a sticky piece of metadata: When a package is e.g.
installed via enterprise policy and an update is then manually
installed or sideloaded, the install reason will remain "policy."
The install reason is tracked separately for each user.
With this CL, two install reasons exist: "policy" and "unknown." Other
install reasons will likely be supported in the future.
Bug: 32692748
Bug: 33415829
Test: Tested manually with "adb install" / "adb uninstall"
Change-Id: I0c9b9e1b8eb666bb6962564f6efd97e41703cd86
Using textSize as maxTextSize for autosizing is buggy and
unclean. Introduce and use new autoSizeMaxTextSize attribute for
TextView.
Also while doing this optimized the auto-size process by removing
unnecessary computations:
1. If auto-size is enabled than setTextSize(...) is no-op.
2. After setting the text size internally and from the auto-size
context onMeasure() will stop doing another round of redundant
measurements..
Bug: 33449596
Bug: 32221168
Test: atttached in the same topic
Change-Id: Ieecaea6df0aebb4c182bdd1114e3c6fc5066bed1
Calling isEmpty will ensure the bundle is unparceled before converting
to a string.
Test: dumped network_score
Change-Id: Icaa4e736af55c6112805a2ce0e829739bbb5b312
- Distinguish between task overlays that need to be resumed and
those that should not.
Bug: 34240533
Test: Open PiP, tap to show menu.
Change-Id: Ibdb54d544c501a492260f02cdc2de40c5c1a66d1
If multiple async shared preferences writes are queued, all but the
last one can be ignored as they will be overwritten by the last one
anyway.
For commit() we need to make sure that we have at least persisted the
state of the commit.
Generation counts are 64 bit, hence they never overflow.
Test: Produced a lot of SharedPreferences.Editor.apply and did not see
excessive writes anymore, ran SharedPreferences CTS tests
Bug: 33385963
Change-Id: I3968ed4b71befee6eeb90bea1666a0bb646544f6
(cherry picked from commit 31d6889f4c)
A graphic buffer is most useful, as we can both attach it
to starting windows, and directly use it in Sys-UI. The old
codepath for starting windows/saved surfaces, is co-existing
at the moment, so I don't make large attempts to clean up
the existing screenshot code.
Bug: 31339431
Test: Manual test in combination with other branches
Change-Id: I562fdd5460dbce3201ba090272e8731850780f20
When an app doesn't define a category, look for a fallback category
in a hard-coded list. This change only defines a fallback for a
single package, but device-specific overlays can be used to provide
more detailed fallback lists.
The precidence order is: app manifest > installer hint > fallback
Test: builds, boots, fallback categories work
Bug: 33815939
Change-Id: I1f5ca76fb7e5743a4500c0a1230a754266f34d9e
Upcoming platform features need to cluster apps together into broad
categories to help summarize information to users. (For example,
when presenting battery, network, and disk usage.)
We are tightly limiting the set of categories to keep them easily
presentable to users when summarizing information. This feature is
not designed to be a general-purpose taxonomy, nor should it be
allowed to become one.
Older apps may not have defined a category in their manifests, so
allow the installing app to define a category on their behalf.
Test: builds, boots
Bug: 33815939
Change-Id: I785b882ee7c18072ef47d56e0fc19ad72888e1b7
On FBE devices, don't save the metrics to disk but compute them when the
password is first entered and only store them in RAM.
Merged-in: 5daf273b7e
Bug: 32793550
Change-Id: Icee7f615167761177b224b342970a36c7d90f6ba
On selection of a snooze context SnoozeCriterion.
Test: runtest systemui-notification & make cts-verifier
Change-Id: Iaca567100c29295fbbf1d327195a114106909652
Pass information about content insets of a snapshotted task to
SystemUI and use it there to correctly offset the snapshot
when drawing.
Test: Open app, go to recents, make sure app aligns before
and after the animation.
Bug: 31339431
Change-Id: I2ff9bd44534bd8f66b591385da1e1e3aec40b6c5
All this functionality is hidden behind a flag. If this flag is
active, we disable the regular screenshots.
Instead, we take a screenshot when an app transition for which a
task is disappearing is starting. The screenshot gets stored
into a gralloc buffer. SystemUI uses a new method to retrieve
a snapshot gralloc buffer and then draws it using GraphicBuffer.
createHardwareBitmap().
When starting an existing activity in an existing tasks, or when
bringing an existing tasks to front from recents, we add a new
snapshot starting window. For that, we reuse the existing
starting window, but when creating the window, we use a fake
window that draws the contents of the starting window.
Test: runtest frameworks-services -c
com.android.server.wm.TaskSnapshotControllerTest
Bug: 31339431
Change-Id: If72df07b3e56f30413db5029d0887b8c9665aaf4
Also fix LockSettingsStorageTests. More unit tests on LockSettingsService
to be added in the next CL.
Bug: 33126408
Test: runtest frameworks-services -c com.android.server.LockSettingsStorageTests
Change-Id: I0f143b26fed1d5ae122fba3b57bd39c7793ad8d9
At line break, one offset can be mapped to two phisical
position: previous line end and next line start.
Previously, all cursor handles are placed at next line
start.
With this CL, selection end handle is placed at the
previous line end in such cases.
Test: FrameworksCoreTests
Bug: 21305922
Change-Id: I00d9f9a0cd417ca92534e93b3d3f655cd62f25d3
