..."uid 2000 does not have android.permission.UPDATE_DEVICE_STATS"
Make sure to clear calling identity before getting into the guts
of the activity manager. Also fix the places the activity manager
calls in to battery stats to not require a permission check, anyway.
Change-Id: Ifd90937875b9fe0c36aa3f5cf1ec173746914e6b
If accessibility is enabled and a test tool based on the accessibility APIs
connects to the system we suspend the current accessibility services while
the tool is running (to avoid inteference as the tool is such a service) and
after the tool disconnects we restore the accessibility state. The issue is
that when clearing the accessibility state we were also wrongly clearing the
active window. We are now careful to not clear the active window in such a
case.
It is also possible that the active window was never initilaized before the
tool is run so now it is lazily loaded such that if we do not know which one
it is, we get the one the has input focus. The definition of an active window
is the one that has input focus or the user is touching.
bug:17663432
Change-Id: I8868866a5126c590d3bddad099ababb97978227a
The code to recover when running processes are removed from the
LRU list turned up an existing problem where we would remove a
persistent process from the LRU list, making it more obvious.
Now it is fixed.
Change-Id: I94ccb924b3e5649b2819d3392b6f6c9c725dc903
The UiAutormator tool is a part of the SDK. If it is run while
accessibility is enabled it stops all accessibility services
as it is an accessibility service itself to avoid interference
and when done restores back the accessibility state. The issue
was that the accessibility state is not restored leaving the
device in a bad state.
bug:17662770
Change-Id: I3c4f46fa05c76b874eeffdeb867ef433c3fedf2e
Uninstall for all users should check whether package
is admin for any user not just user 0.
Bug: 17657954
Change-Id: Ia116248b5889fc02dd46816a132e03c8e62662c9
In the past we wrote out badly formed ComponentNames with no
class part. Loading these results in a null pointer exception
blocking boot.
Bug: 17652534
Change-Id: Iec592343425a23c7ada5f73cf30b8646d31eae81
If all accessibility services are disabled we turn off event firing
to avoid a lot of work for nothing. The logic to do that had a flaw
and was not turning event firing off in every case it should. We were
tuning event firing if it is on and no service is enabled but it
is possible that a package on the system image is disabled so the
service is enabled just not bound. Arguably we can remove the
serivice from the enabled list but it is technically on the device.
Note that we correctly handle the case of a package being removed.
bug:17332506
Change-Id: I6d6d9cb9cc271116a3d22ed9fd8d7f533dec9a0b
Add basic filename protection, also only file names that are for
app icons so this can't be abused to access thumbnails.
Change-Id: I2831c0f3f08a39aa734f93f76b6fd4aaf97e87c6
Cleaner paths and better error reporting when a problem goes wrong
while binding an application. This gets rid of the (recently added)
error about removing a process that hasn't been killed, and cleanly
kills the process along with more detailed errors about where things
failed.
Change-Id: I710a209c14da1515929e6254396b793177eee115
Logic in WindowState caused a delayed layout on the starting window,
which forced another layout/draw pass, which was unnecessary. Making
the resize call happen sooner means that that request gets lumped in
with a pending layout request, so there's only one resulting draw.
This saves not only the second drawing operation, but also the creation
of an extra buffer in SurfaceFlinger for that second draw request. This
buffer is temporary, but can be quite large on some devices and push
the system over the memory edge in extreme situations. It's difficult
to track this memory usage difference as the buffer resides at a very
low level in the system. But you can see in systrace that the second
allocation (and the second draw) is not happening after the fix.
Issue #17570761 Constrain starting window to only one buffer
Change-Id: I0e0fff7efdc812730706afccbfb020dea3f8d3e2
In Priority mode, NoMan can block the telecom Ringer
indefinitely when looking up the caller contact details via
ContactsProvider.
Fix this by introducing a 3s timeout and assume the call
matches the call filter when the timeout is hit.
Bug: 17598245
Change-Id: Ia0893cf203e6ffd943c749719ebb9e0f0958eb01
Because user IDs are recycled it is not safe to leave this kind of
information around after deleting.
Bug: 17403144
Change-Id: I441f85750cf8818adaf62a1acdb2ba7b4bfc1b7e
Each time that window manager gets a notification that a display has
been added, removed or changed, run a pass through
performLayoutAndPlaceSurfaces. This ensures that
WindowAnimator.animate() runs once so that the surfaces of remote
displays can be updated with their visibility.
Fixes bug 17533991.
Change-Id: If8745527df86c74da75fbe26b8a2a6fddeb74d2a
BUG: 17625667
Two part clean-up.
1) Don't try to lock in onControllerStateChanged. Do it in the handleMessage
instead where the rest of the locking is. This is sufficient to fix this bug.
2) The other side of the deadlock came b/c we lock when cancelling and calling
stopTrackingJob. Controllers handle their own locking so this isn't
necessary. B/c of a potential race from the controller side, added an explicit
check for the JSS to only run an expired job if it still exists.
Change-Id: Iaeebbc19437eb5b73e3ced3168f1fc13e564a4be
Improve the warning logs when setting up preferred activities
to help identify when there are issues and what they are. Also
improve the algorithm a little to still apply permissions when
resetting them and there are additional third party apps, as long
as the additional app is something like another browser and the
preferred activity being set is more specific (has a better match).
And add an example of using manifest-based preferred activities
in to ActivityTest -- and yes it DOES work! :p
Change-Id: I1ff39e03a5df6526206e0c3882085396b355d814
Setting the display power state currently happens while holding the
display manager lock. This change moves it out of the lock to
ensure other services don't get stuck for several hundred
milliseconds.
Unfortunately, surface flinger ends up stalled a little later
so this only solves part of the problem.
Bug: 17623774
Change-Id: I201137c5e7f82c776f28a436845fcf3191fd0ca5
Since all devices now appear in quick settings, remove the
framework notification and obsolete artifacts.
Bug:17607193
Change-Id: If952b826d79c77068285373c6b44a430f78c20b1
