When the calling user is a work profile and the device has
file based encryption enabled, show the work challenge via the
Confirm Credentials APIs before launching the requested activity.
A companion CL in Settings will add support to the Confirm
Credentials flow to read the given intent extra and fire it when
the authorization succeeds.
This is part of the Separate Work Challenge feature.
Note nobody will see this yet as the feature is conditioned by
file based encryption.
Change-Id: I303890095936b1fd1f6a99d645724dffba144345
These simple utility classes (used internally since Property was first introduced
way back in Jellybean) are the best way to avoid autoboxing when using the Property
approach to ObjectAnimator. But since their hidden, developers have to use the
autoboxing version (Property, the superclass) or know to come up with their own
primitive-optimized property subclasses.
This CL simply un-hides these two classes to make them usable outside of the framework.
Issue #21722783 Make [Int|Float]Property public
Change-Id: I7f3a456d108bf48587d711255d3577cce3ac5e24
Added mUsersLock - short-term lock for internal state, when interaction and
synchronization with PM is not required. Modifications to mUsers and
mRemovingUserIds must be guarded by 3 locks: mInstallLock, mPackagesLock and
mUsersLock. While reads can use mUsersLock.
Testing revealed that the following methods in UMS often cause contention:
- exists
- getUserInfo
- getProfileParent
They all now use a short-term lock mUsersLock for reads.
Bug: 24979571
Change-Id: Ie3a22ea7cbb450c7969800fe2a4a2b2516165e5b
Adding performLongClick(x,y) broke compatibility for widgets that
overrode the no-arg performLongClick() and expected to receive a call.
This CL ensures that the no-arg method is called and the (x,y) data is
preserved for use in the default implementation.
Bug: 25411884
Change-Id: Ib0a3fb02d4c08ef64ce3a7165aa83bf0688aa50e
Bundles cascading menu information and stores it in a stack representing
the hierarchy of added menus.
Bug: 23970448
Change-Id: I1621d9eb30ff173767b6ebad2a1977127c42d0ad
I think what probably happened is that since we only report an app
going in to the "interaction" state as an interaction event to usage
stats, apps that sit around in that state forever will only see one
interaction at the start and never again. So usage stats could start
thinking they are idle.
Fix this by having the activity manager report an interaction event
for such long running applications at least once a day.
Also, because it is correct and for paranoia by protected us another
way, system uids should never go in to standby.
Change-Id: I8a3805bfca86cbe78560488a649ecd07427da99a
Helps make the code easier to follow since we are no longer checking
multiple stack ids at various decision points.
Bug: 25282299
Change-Id: Ifa6864a1ef56ce2eca4c94f87a4e0b993de987cd
In order to provide pixel perfect movement of SurfaceViews
'within' other views (e.g. scrolling) we need to be able to
synchronize the attached (parent window) painting with the
movement of the SurfaceView (recall, SurfaceViews are positioned
behind their attached windows and the parent must render a
transparent region for the SurfaceView to appear). Provide
a new WindowManager method to reposition an attaching window
(that is to say, a window which has an attached window like
SurfaceView) and defer the transaction until the parent frame.
SurfaceView is hooked up to use this for movement. This is still
'racy' in the hardware accelerated case as the render thread
could be on either side of dequeing the frame we are working on.
Bug: 22802885
Change-Id: I025d2bdcbe15c1c11047cc0dbca2cf2b7d67c632
The Alarm Manager now supports a set() variant that takes a listener
callback to invoke at alarm trigger time rather than a PendingIntent.
This is much lower overhead and has guaranteed low delivery latency
from the trigger time. The tradeoff is that the app must be running
*continuously* from the time the alarm is set to the time it is
delivered. If the app exits for any reason before the alarm fires,
the listener becomes invalid and the alarm will be dropped. This is
more or less equivalent to setting an alarm with a broadcast
PendingIntent that matches only a runtime-registered receiver.
The app's alarm listener can be any object that implements the new
AlarmManager.OnAlarmListener interface and implements its onAlarm()
method. There is no data delivered at alarm trigger time: whatever
state needs to be associated with the specific alarm instance should
simply be packaged inside the OnAlarmListener instance.
An alarm using OnAlarmListener can request that the onAlarm() method
be called on an arbitrary handler. If the program passes 'null' for
this parameter when setting the alarm, the callback occurs on the
application's main Looper thread.
Bug 20157436
Change-Id: I2eb030a24efdd466a2eee1666c5231201b43684b
