The DPC can use it to tell if provisioning a managed profile or for
device owner would work or not.
BUG:25338478
Change-Id: I09ea6a9f23a8e88e4ed37c048170b2a68213086e
As a matter of policy, we should never be holding the mPackages lock
while calling down into installd. This little bit of logic helps us
catch accidental cases where this happens.
Change-Id: I676c81df43ef936ffd36290d45a79429630c1b4b
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
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
Otherwise the context within it can't be GCed.
It's better to leave the caching to the ContextImpl.
Bug: 25308506
Change-Id: I9be3ba5b1bb6cdc88b77520b2fbd72d9b72ef30d
There are two improvements in reporting size configurations:
1) duplicates are removed;
2) smallest width is reported separately;
Change-Id: I8f8235c99e6eefcae178e8d61e79ad0c4d6f1144
