We handle failures better and exit early if already switched to a current user.
Fixes: 150019926
Test: manual verification
Change-Id: Ib3d70d21cc379f136983f9ddcda31f5bab3f045e
(cherry picked from commit c0bb4e2816)
Merged-In: Ib3d70d21cc379f136983f9ddcda31f5bab3f045e
Due to the switch to Async HotspotControllerImpl, if the controller is
created with the tile it will think that tethering is not available
(because it hasn't received callbacks saying otherwise yet) and the tile
will be preemptively destroyed. This was observable on OTAs (or when
doing a full flash).
With this change, HotspotControllerImpl will assume that tethering is
available by default and will signal callbacks if it learns that it's
not.
There are currently no other consumers of
HotspotControllerImpl#isHotspotSupported.
Fixes: 149492796
Test: atest HotspotControllerImplTest
Test: manual full flash
Change-Id: Id1461b7fbe973b732bc69c7ad77a30e0f66247d8
statsd logs when an sensitive appop is accessed while a foreground
service is held. These appops include
OP_FINE_LOCATION
OP_COARSE_LOCATION
OP_RECORD_AUDIO
OP_CAMERA
It logs the number of times each of these appops is requested per session
during which the uid holds any foreground service.
Appops requested while the app's process state is TOP are ignored.
Also, the pre-existing ForegroundServiceStateChanged atom has an
additional field that logs whether the fgs is considered 'in-use' in the
context of being allowed while-in-use permissions.
Bug: 149497535
Test: atest UidAtomTests#testForegroundServiceState UidAtomTests#testForegroundServiceAccessAppOp
Test: manually monitor: adb shell cmd stats print-logs && adb logcat -v uid -s statsd | grep "statsd : {" | egrep '\((60|256)\)'
Change-Id: I991a427dc2ab00399188b10b266ab2d9aa92696d
Merged-In: I991a427dc2ab00399188b10b266ab2d9aa92696d
(cherry picked from commit 0c8637c067)
When permission is granted to another app via URI, we implicitly grant
visibility to that app of the app ID that that URI resolves to.
Test: atest AppSecurityTests
Fixes: 149781706
Fixes: 145677500
Exempt-From-Owner-Approval: Owner approved prior to cherry-pick
Change-Id: I7c8967a4464fd821e4f95d8eb6c0bcfadadb912e
From this CL onwards, the default for controls is enabled (still not a
Setting).
The controls section in power menu and the new layout will only be used
if there's at least one app that can provide controls.
Test: manual
Bug: 149992619
Change-Id: I4e78735d642d24fe0080a0f0f4cbc58ffa2d5a94
- Draw a background pill instead of frame on the keyguard
for the currently active user.
- Set a different text style for the user switcher
Bug: 146426568
Test: Manual inspection
Change-Id: I5cfefbe375bb0f3b7df8729c473867b97578f81f
(cherry picked from commit d457eef32c)
This migrates the previous Tron events into Westworld. Now we only log
the spec/package for each tile, not the position.
The position in most cases is not interesting as it can be obtained from
other places (in the future, lift this info from QSTileHost for
example).
Fixes: 147508828
Test: manual using statsd_testdrive
Change-Id: I7b27a31b303d6ebe894041433fbf9d81e57a9f3c
The ActivityTaskManagerTestService has a special method to start a
DreamActivity. This CL adds a verification check before the activity is
started to check that the caller is the currently active dream
component.
Bug: 133216167
Test: atest DreamManagerServiceTest
Merged-In: Id71b4cbc57c6569f58b6d906cc8361c104a507dc
Change-Id: Id71b4cbc57c6569f58b6d906cc8361c104a507dc
(cherry picked from commit 20dc51820a)
Currently, the DreamService uses a floating Window to display the
content of the dream on the screen. This introduces difficulties in the
interactions with the Assistant application, which is an activity.
By design, if the Assistant is invoked while the device is dreaming, the
Assistant should be shown on top. However, since floating windows are
always drawn on top of all activities, the Assistant can't be shown on
top of the Dream.
Here, we migrate the implementation of the DreamService to use an
Activity (DreamActivity). Since the screensaver application is not part
of the framework, we can't declare the activity in their AndroidManifest.xml.
Therefore, we start the dream activity with a dedicated method in
ActivityTaskManagerService.
Bug: 133216167
Test: 1. m && ./vendor/google/tools/flashall
2. Go to Settings > Device Preferences > Screensaver > Start now
3. Verify dream appears
4. Click any key to wake up the dream
5. Verify that dream disappears
Merged-In: I8dff0a124cd1b41fb925a73528305431b49ee06d
Change-Id: I8dff0a124cd1b41fb925a73528305431b49ee06d
(cherry picked from commit 148478a85e)
