Uses argument escaping inside NativeDaemonConnector, using varargs
to separate boundaries. Also introduces Command object to help build
argument lists.
Bug: 5472606
Change-Id: I357979fc19bb0171a056e690064e01b5a7119501
This change simplifies the code associated with receiving input
events from input channels and makes it more robust. It also
does a better job of ensuring that input events are properly
recycled (sometimes we dropped them on the floor).
This change also adds a sequence number to all events, which is
handy for determining whether we are looking at the same event or a
new one, particularly when events are recycled.
Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
As it turns out, it used to be possible for there to be multiple
input events simultaneously in flight in an application. Although
it worked, it made it hard to reason about what was going on.
The problem was somewhat exacerbated by the introduction of a
queue of "InputEventMessage" objects as part of an earlier latency
optimization.
This change restores order from chaos and greatly simplifies the
invariants related to input event dispatch within the application.
Change-Id: I6de5fe61c1fe2ac3dd33edf770d949044df8a019
Setting it when a new activity is being resumed is too soon, because
things like an activity launching an exiting (without being seen by
the user) can knock out the real previous app that we want.
So now we set it when an activity is stopped. At this point it is
going to move from the preceptible to background oom adj, so it is
a good point to determine whether it should be a previous app to
instead put it to that oom adj. This also avoids things like
activities that start and immediately finish from impacting the
previous app.
Further, we keep track of the time each activity was last shown, and
use this to further filter what is set as the previous app.
Change-Id: I72d1cac4de0cc2d4598170296028f11b06918d4f
This broke with some other path-related changes, so it was scanning for
/data/*/cache instead of /data/data/*/cache
Also remove redundant call to restat
Bug: 5686310
Change-Id: Id1661f0f1337858fc9ead53c56ab7557f421c591
1. AccessibilityInteractionConnections were removed from the
AccessiiblityManagerService but their DeathRecipents were
not unregistered, thus every removed interaction connection
was essentially leaking. Such connection is registered in
the system for every ViewRootImpl when accessiiblity is
enabled and inregistered when disabled.
2. Every AccessibilityEvent and AccessiilbityEventInfo obtained
from a widnow content querying accessibility service had a
handle to a binder proxy over which to make queries. Hoewever,
holding a proxy to a remote binder prevents the latter from
being garbage collected. Therefore, now the events and infos
have a connection id insteand and the hindden singleton
AccessiiblityInteaction client via which queries are made
has a registry with the connections. This class looks up
the connection given its id before making an IPC. Now the
connection is stored in one place and when an accessibility
service is disconnected the system sets the connection to
null so the binder object in the system process can be GCed.
Note that before this change a bad implemented accessibility
service could cache events or infos causing a leak in the
system process. This should never happen.
3. SparseArray was not clearing the reference to the last moved
element while garbage collecting thus causing a leak.
bug:5664337
Change-Id: Id397f614b026d43bd7b57bb7f8186bca5cdfcff9
We could sometimes allow a process to be killed while still waiting for
an activity in it to finish stopping.
Change-Id: Ibf89665c4ad6da6be22de04a82b19ef778a7fda0
We now generate a stack-trace looking thing at the top of the report.
Also fix a bug I hit where the phone window manager was sending a
broadcast before the boot had completed.
Change-Id: I0cee16180e4d05c9bd3fe715212a28f504ec91ac
Perform uniform argument escaping inside NativeDaemonConnector, using
varargs to separate boundaries. Also move to parsed NativeDaemonEvent
instances instead of raw Strings.
Bug: 5472606
Change-Id: I1270733e2b2eeb2f6b810240df82ab24d38ebf40
Turning animations back on exposed this. The problem is that when the
screen brightness changes, it initiates a brightness animation. When
we force the screen to black as we wait for it to be ready to display,
it sees that an animation is running so stops it and thinks this means
it should now turn the display off.
To fix this, don't modify the screen brightness while we are waiting
to show the screen. This is good anyway because the whole point is to
avoid showing the screen until ready, and modifying the brightness at
that point would turn it on prematurely.
Change-Id: I84b296f8ca5705c2d237ea7741cdeb95c5521df9
Make surface management between SurfaceView and the window manager
much more controlled, to ensure that SurfaceView always gets to report
the current surface is destroyed before the window manager actually
destroys it.
Also a small tweak to allow windows that have a wallpaper background
to still have a preview window. This makes launching home after it
has been killed feel much more responsive.
Change-Id: I0d22cf178a499601a770cb1dbadef7487e392d85
