...running as the foreground user
Add UserManager.isUserRunning() which is the public version of the
existing method on ActivityManager.
Also add UserManager.isUserRunningOrStopping() since that seems like
it will be useful.
And fix the internal function that returns the array of currently
running users to not include stopped users.
Change-Id: I84672fa8748fc027fd402729586b5603f640e498
Fix a bug in WiredAccessoryManager causing an
HDMI disconnection to be signaled to AudioService when a
headset is connected.
Bug 7313250.
Change-Id: I7c6446104c55f9a4fc146abe7020df45ad6ba5e7
1. If a view is clickable or long clickable perfroming the corresponding
accessiblity action should return true no matter whether there is a
registered on click/long click listener. Currently true is returned
only if there is a listener but it is also possible that a sub-class
overrides performClick and does work there. For example CompoundButton.
Now if the view is clickable or long clickable we will call the
perfrom* method and return true, which is we clicked.
2. Fixed some JavaDoc indentation.
bug:7318777
Change-Id: Id603fee378b8f7d07f1128b5641ede57640bab53
Check the status of Settings.Secure.USER_SETUP_COMPLETE for the current
user when showing the keyguard, disabling the Camera + Search touchpoints
entirely until the user makes it through the setup wizard.
Bug:7308791
Change-Id: Ic8e3596582c2aefc7fe15af1824ed6bfd541dffa
A dream may itself hold a wake lock in order to keep the screen
bright as it runs. However this wake lock also causes the device
to stay awake even when it is not plugged in which is undesirable.
This change makes full wake locks behave differently when napping
or dreaming. The wake lock still keeps the screen bright but
it does not prevent the device from falling asleep. This is
similar to our policy of ignoring full wake locks completely when
the device is manually put to sleep by the user.
Bug: 7295909
Change-Id: Id99e82d2143ae1a81629281d6407d7527efb8137
If the user was in the middle of a phone call and went to the lock screen
it would show a black box with an X, but Face Unlock wouldn't pop up and
the X was unresponsive.
There were a few issues causing this. The X on the default view wasn't a
button, so it has been changed to a button which will go to the backup
lock. The concept of show() and hide() in FaceUnlock.java are obsolete
because Face Unlock is no longer being overlayed on top of the backup so
there's isn't a black box to show or hide. In addition, since it's not being
overlayed, Face Unlock doesn't cover the backup lock so fading to the backup
looks janky. The flip animation is more appropriate.
Change-Id: I730aa4bbce42b4656ee1bce61352b8aefbd6892d
When switching users, Face Unlock starts in onResume(). However,
there is no signal to indicate when the user actually sees their
unlock screen. This means Face Unlock could be running unseen, timing
out soon after it becomes visible, or letting the user in before they
see the preview.
This fix simply suppresses Face Unlock immediately after switching
users. This is not the ideal behavior, but there is no easy way to
make Face Unlock start only after the unlock screen becomes visible.
When the user changes screens it becomes unsuppressed, so if they go
back to the multi-select widget screen or login, Face Unlock works as
expected and is only suppressed again when the user is switched.
Change-Id: I80a302b0aefc1dee3c2dc77557978cbe062de435
ADB installs appear as UserHandle.USER_ALL, and can only be performed by
UserHandle.USER_OWNER, so use the package verifier for UserHandle.USER_OWNER.
This returns a valid userId to call PackageManagerService.getPackageUid.
Bug: 7293091
Change-Id: I7a5497cfe5fa2e7aa804345cf9f507ec26a0db21
During testing it's possible to mock a location provider, but the fused
location provider wasn't being inserted into the "mRealProviders" map so
when the fused location provider was unmocked, it would disappear
permanently from the list until the next reboot.
Bug: 6949478
Change-Id: I4993aa7fbbd21cea16bdbf2722d637c909b1cd73
