A view may be temporary detached. While in this state the view
state may change for which we fire accessibility events. Clients
use them to know when the view changed and what the change is.
However, detached views do not fire accessibility events.
Hence, a client may hold a stale AccessibilityNodeInfo since
the changes to its source view happened in a temporary detached
state.
bug:11388752
Change-Id: I9052700ca9195841cc2881b65c17f5615e6f71fb
...not to work on KitKat (was: Janky exit animation)
Reworking the LRU list (splitting it into an activity vs. empty
section) accidentally broken the old behavior of "client activity"
processes being prioritized with activity processes. In fact, we
were no longer marking "client activity" processes at all.
In this change, we rework how we manage "client activity" processes
by putting them on the main activity LRU section. This is generally
simple -- ActiveServices now keeps track of whether a process is
a "client activity" process based on its bindings, and updateLruProcess
treats these as regular activity processes. However, we don't want
to allow processes doing this to spam our LRU list so that we lose
everything else, so there is some additional complexity in managing
that list where we spread client activity processes across is so
that the intermingle with other activity processes.
The rest of the change is fairly simple -- the old client activity
process management is gone, but that doesn't matter because it wasn't
actually running any more. There is a new argument to updateLruProcess
to indicate a client process it comes from (since we now need to update
this based on bindings) which is just used to limit how high in the
LRU list we can move things. The ProcessRecord.hasActivities field is
simply removied, because ProcessRecord.activities.size() > 0 means the
same thing, and that is actually what all of the key mechanisms are using
at this point.
Finally, note there is some commented out code of a new way to manage
the LRU movement. This isn't in use, but something I would like to
move to in the next release so it is staying there for now for further
development.
Change-Id: Id8a21b4e32bb5aa9c8e7d443de4b658487cfbe18
When a client of a UiAutomationConnection is set it remembers its UID
and allows subsequent operations only from this UID. The connection
If the connection was not used, i.e. its client is not set, and an
attempt to destroy it is made the connection enforces the caller UID
to be that of the owner but it does not have an owner yet. Now if the
destroy method is called on a connection that is never used (has no
client) we do not enforce caller UID.
bug:11465888
Change-Id: I739dfc45e772ea970b6ab384e4420184724333a3
Use ContentProvider.enforceWritePermissionInner() to handle all edge
cases around checking if caller has write permissions. This fixes
bug where call() would throw if caller and provider were the same app.
Bug: 11464234
Change-Id: Iace8e0e4243d56ed1cdcc9680383103975107036
Layout and write may take some time during which the user can
cancel printing. Currently we wait for the last operation,
being write or layout, to complete before closing the print
dialog. Now in such a scenario we request a cancellation of
the ongoing operation.
bug:11329523
Change-Id: Ia9d747163cc73509369a86c8b5afc83b7ee54859
A static map in TransitionInflater keyed off of Context instances,
which could cause contexts/activities to leak over time. This
fix removes that map and simply creates a new inflater each time.
The savings of the cached inflater was minimal an unnecessary, and the
intended sharing is in the context embedded in the inflater anyway.
Issue #11436919 leak in TransitionInflator
Change-Id: Ic05ca47f57723bd572bb6143df4035d66eedf5ad
This was found by a bug in Firefox where it expects the addresses from a
ProxySelector to be unresolved. Since ProxySelectorImpl returns unresolved
addresses the PAC version should as well to avoid breaking apps.
The ProxyServer also needed to be updated to reflect this change as it was
expecting a resolved InetSocketAddress.
Bug: 11443853
Change-Id: I3a4e9e248d22d7808603c147660df708e01cdf82
bug:11351836
Because SeekBar's thumb Drawable (among others) is positioned without
padding offset baked in, include that offset when invalidating.
This revert fixes invalidate positioning in the system volume SeekBar,
where the original CL broke full redrawing of the thumb Drawable when
it switched states.
This reverts commit e9018f7716d3d2f61602c07c273674585482653d.
Change-Id: I5b3b07e47f466269f8d349e9a63dc29bf213120b
The wrong method was used when getting the user states to dump
and as a result only the state for the current user was dumped
as we get an exception for the other users.
bug:11457875
Change-Id: I9a3bcac01f1f1cf4f6e72aefff7cff2e0c6bca94
The PDF generating canvas we use does not yet support all
drawing operations. This change adds docs which operations
are not yet supported.
Change-Id: I8d5ee8c1e2a473ba783b5e62f23ab90a54bbf106
Move the recent keyguard hidden coalescing down to the callback
level. The lifetime of each callback can be short, make sure
they see visibility changes at least once for each change local
to their lifetime.
KeyguardStatusView.refresh() is called multiple times, and instances
are recreated often. This results in expensive computations
filling the sysui/keyguard ui queue, adding to overall sluggishness.
Traceview points to DateFormat.getBestDateTimePattern as the
main culprit.
As of this change, refresh() will only call the expensive date pattern
computations when absolutely necessary, resulting in better
performance turning the screen off/on.
Bug:11221659
Bug:11447043
Change-Id: I3d4105af7db608803b82d8ef0ff141e42c154257
