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
Improved quick launch bookmarks to support category-based shortcuts
instead of hardcoding package and class names for all apps.
Added a set of Intent categories for typical applications on the
platform.
Added support for some of the HID application launch usages to
reduce reliance on quick launch for special purpose keys. Some
keyboard vendors have hardcoded launch keys that synthesize
"Search + X" type key combos. The goal is to encourage them
to stop doing this by implementing more of HID.
Bug: 5674723
Change-Id: I79f1147c65a208efc3f67228c9f0fa5cd050c593
There was an error in some of the OpenGL layer logic such that we would
occasionally set up a layer for rendering and then not clean up when it was
done. This caused future OpenGL rendering to go into that layer instead of
to the buffers being displayed on the screen, resulting in artifacts including
flashes and displaying of stale content. This happened specifically when
using the wifi settings dialog with the InputMethod keyboard displayed,
but it was probably visible in other situations as well.
Issue #5628248: Flickering/flashing after entering password for WiFi
Change-Id: I38139f620b310f4309570fa7224552d2ee633999
Bug #5659476
The FontRenderer was not cleaning up its temporary state, leading
to crashes when invoking renderDropShadow.
Change-Id: I43b24820dd5625af8c080bbe11b64de2f74164b2
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
Bug #5638421
This bug was introduced by the recent changes that force more frequent
flushes of the GL renderer.
Change-Id: I55dd4ace6ba1e70ab41927150d6c60c37d7fb196
The text selection change event was not added to the text
populating accessibility events in View.
bug:5638709
Change-Id: Ie7e319bc07d7e6c48f178a6c1bd22b1fe32ff515
This class provides an API for an application to know when it is time to
destroy its EGL context when memory is being trimmed. By having this in
the framework, we can still detect whether it will be useful to destroy
any EGL contexts (because we know if doing so will destroy all of them).
Change-Id: I1eac8d640052778052926b875c7928008f752182
Stop using system properties to publish information about
the key character map path. Instead, we can retrieve it
on demand by asking the window manager.
It was possible to exhaust the supply of system properties
when repeatedly adding and removing input devices.
Bug: 5532806
Change-Id: Idd361a24ad7db2edc185c8546db7fb05f9c28669
This does not happen on high end gfx devices. This happens
only if only one EGL context is initialized in the current
process.
Change-Id: Ibd1737efdf84eef8a84108b05795440d1ae9964e
Fix a bug that caused animated drawables to not schedule properly when
a view has not yet been attached. Also make ImageViews update their
drawable visibility state properly, which will handle scheduling
concerns as ImageViews are attached and detached from their windows.
This should also fix the bug where animated notification icons in the
status bar do not animate until the posting app posts an update to the
notification.
Change-Id: I24c403182831258d1f251736e920c9efe1d38299
This allows Music2 and other media apps to control master volume without changing their code
Bug: 5567694
Change-Id: I48b6260b193b22c395be5a31cd1d270b2929a91e
Signed-off-by: Mike Lockwood <lockwood@android.com>
Launcher swiping looks choppy. It's because we deliver the
motion events of the drags asynchronously, and sometimes we
may get an event to redraw before the motion event is posted, so we
end up drawing again without updating to the latest motion
information.
This fix makes input event processing more proactive. Every time
we run ViewRootImpl.performTraversals() (which is what
happens whenever we need to layout, measure, and/or draw), we
first process all pending input events, ensuring that we are
completely up-to-date with posted events prior to drawing, so that the
drawing we do is synchronous with the events we've received.
This eliminates the choppiness and means that we can now get the full
refresh rate on the screen with drag events.
The fix was done for Launcher, but it is pervasive in the system,
so this may fix other laggy drag behavior as well.
Change-Id: I8dbed6acadc2662f317f736e769f536f555701aa
