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
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
So that apps that are already whitelisted don't have to be whitelisted
again if they add a CP.
Bug: 22977552
Change-Id: I4042d531178ab63d5d1e5b963fc081e3ed523835
During system boot, we prune app-ops belonging to apps that have
been uninstalled. However, apps installed on adopted storage devices
haven't been scanned at this point, so they appear to be uninstalled.
To avoid pruning app-ops for these apps, we need a getPackageUid()
variant that also considers "uninstalled" apps for which we still
have PackageSetting values.
Bug: 25206071
Change-Id: I1820f674d45c5ddc1c5f10ed7d859e7025005e28
The battery service just implements the existing commands that
are available through dump.
The activity service implements the small set of commands that
are available through dump (not the rest of the dump commands),
and also introduces some of the simple "am" shell commands as
a proof-of-concept of moving those into the service implementation.
Change-Id: If5ff80930dde787703e2682e43c36ce1dab05d69
Doing this while dragging is really necessary for System UI shelf.
Also, not forgetting to remove the child from the "interested" set when
the child is removed.
Bug: 25231591
Change-Id: I26f5086a0a842868b2d7e9809f7483152098f314
(cherry picked from commit a82c8709f0914064f4b00262f1d411594bab467f)
Add a Window API for setting a view which will be placed in
the decoration area (next to the window control buttons).
Change-Id: Ie106cbea653ff95fdba987a2a43506d394600612
