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
1) listen to SUBINFO broadcast intent to better capture SIM info update.
2) notify HAL about SUPL server/host everytime they get set.
Bug: 17288144
Change-Id: I65cb4e0879c55c078e85d062877e491904e78222
Also try to get rid of a huge wtf we are seeing across a lot of devices
where we incorrectly change real states on a service that is restarting,
and get rid of one of the noisier boot logs in the package manager.
Change-Id: I2510b6fb082eac3f6168cbd57bc3b70ad006114d
Once upon a time when the world was fresh and new, the heavens
had an easy rhythm. Day and night. Night and day. In the day,
the pixel fairies would cavort and play in the bright gardens
with narry a mark of shadow or gloom. In the night, they would
rest peacefully, dreaming no dreams and knowing no fear.
Then one night a fairy dreamed the first dream. At first
the dream was peaceful, full of colors and delight, hopes and
memories. Then all at once, jarringly, it awoke in bright
daylight. The pixel fairy knew fear, for the world had changed
and it was unprepared.
Time passed and the pixel fairies grew accustomed to their
fate, day and night, night and day, sometimes dreaming, until
there came a night when a fairy did not sleep. It roamed
the land in a dreamless doze, lost and afraid amid a grim haze
of grey and darkness. The fairy despaired. It wanted no
part of this place. It pretended for a time to be awake but
the bright daylight would not come. It pretended for a time to
be dreaming but the colors and memories would not come.
That is when the fairy wished for oblivion. Then just as
suddenly, it awoke in the daylight. It fell to the ground,
stunned as if it had forgotten how to walk in the too bright
daylight.
Though the world again grew softer and kinder in time, the pixel
fairies were never the same. For the night is dark and full
of terrors.
---
It used to be easy. Screen on and screen off could explain almost
everything about the state of the device but it's different now with
ambient display. We need to be able to wait for all windows to be
drawn even in the case where the device is still nominally asleep.
In truth, the window manager policy which drives a lot of these
interactions is a thicket of outdated assumptions.
Added a new method to tell the window manager policy when the screen
is being turned off so that it can correctly account for changes
to the interactive state (wakeUp and goingToSleep) and screen state
(screenTurningOn and screenTurnedOff). Now we can independently
poke keyguard during interactive state changes and we can apply
screen on blocking during screen state changes.
Moved the code which manages screen on blocking (which is what
ensures the UI has fully drawn before revealing screen contents)
from the power manager to the display manager since the display
manager is in a better position to accurately track the state of
the screen, particularly when the screen is being turned off.
Fixed a bunch of synchronization issues. Previously some work
had been moved to a handler without considering what might
happen if it became reordered relative to other work happening
elsewhere. Documented the desired behavior in the code to
prevent this from happening again.
There's still a bunch of stuff in here that isn't quite right,
particularly the assumption that there's only one screen, but
it's good enough for now. Hopefully there aren't too many bugs.
Bug: 17605802
Change-Id: Ic7319e09948c8a3cda014d7e169c964a3ad86f14
With the introduction of managed profiles, ActivityManagerService.PackageMonitor
can receive Intents from users other than current one.
Bug: 17580914, 17314317
Change-Id: I7c601618f7819d6775cf422dca70a929ee1089d9
Previously we would restart clatd on every LinkProperties
change, which now happens every time we switch radio technology
(e.g., LTE to HSPA). We also would not stop it if the link got
an IPv4 address.
Bug: 15024258
Bug: 17186694
Bug: 17569702
Change-Id: I65cfcd5e7acec8ea1a12392a59dabd668c58490f
Now that we support unreachable routes, use those to block
address families on VPNs. This is a much more elegant solution.
Also update LinkProperties when IP addresses are added and
removed, fixing a TODO.
Bug: 17462989
Change-Id: Ib749d84710dca70d672350b9f129bb91419ec77e
Seriously, don't look at this. It is so dumb.
Brought up by issue #17307700: retarget a relinquished
task is not working
Change-Id: I947438d3502f75510e2974211bb78d31008eaa90
There exists a lifecycle regression where launching an
app from the lockscreen (camera, etc.) causes a series
of onResume, onPause, onRestart, onStart, onResume.
This CL reverts the behavior to what it was in KK, which
is to say that the Launcher is first resumed/paused, then
the Activity being launched has a simple onRestart,onStart, onResume
lifecycle.
Bug:17459745
Change-Id: I04091d2f86a929ee972c8d6debc1beb033c135a8
Decouple events from alarms in the zen interception function,
and default the new allowEvents to true.
Bug:17580878
Change-Id: Iff10df385206ad73c3423ff118c79e94a10918d9
There was some code here locking on the lock object instead of
the main activity manager lock...!!!
Change-Id: Ic85151fbef915f6fb8fd5ce3c1a7e9b810412cb6
Try to catch any cases where we remove a ProcessRecord from the LRU
list when it may still have a process associated with it, report
that this happened, and try to make sure the process is killed.
Change-Id: Icd74439caba5e1c283c01a49a46dae926a00ba71
When restoring app widget state from XML we read all providers,
hosts, and widgets and only after reading all hosts and providers
for all members of the group we hookup the widgets as they may
cross profile boundary. To esntablish the host-widget and provider-
widget relation we use a tag for the host and the provider that
are assigned before saving the state to XML. When restoring we
are using the tags to match widgets with hosts and providers. The
bug was that we were not clearing the tag of all hosts and providers
before reading from XML as we want the only tags that are defined
to be the ones we are reading. This resulted in wrong app widget
restore for a secondary user.
bug:17505027
Change-Id: I035d8f13142c6b9dbc9d658b82390f9cd8d75e0d
