Some stray code from a previous change caused an erroneous content
description to be set on the wrong view in the action bar. Correct
this and sync with the right behavior.
Bug 10969992
Change-Id: I4deaa3528b4bc222e25354679fa93f8316fa2d70
Apply the test for configuration change to all windows. A year ago
this was the test but CL ag/247731 which fixed b/7428221 limited the
test to just Keyguard windows. A week later CL ag/248223 which fixed
b/7444971 applied the test to Wallpaper as well. Then two days after
that CL ag/249762 which fixed b/7453222 reverted the wallpaper. This
fix reverts the Keyguard qualification and restores the test to all
windows.
This fix has been tested against the repro steps for all three bugs
above. In addition this fixes bug 11033407. The fix for the bug is
described in the bug.
Change-Id: Ie0f4c7cd4697c1689c4f331d572359cf7ce934cf
This fixes a problem where the frame would resize mid-animation because
the widget frame was being always being resized.
The issue was caused by having an extra fadeOutChallenge() in
onPageSwitching(). The fix is to remove this and handle this case
special for warping in onPageEndWarp()
Fixes bug 11190745
Change-Id: I6dbda4d09c77e3923887f8d41efb2215e1afb1b9
When we dispatch input events into the actual application, make sure
the input invariants we rely on haven't changed. If they have, we
drop the event and log why.
Bug: 11399505
Change-Id: Id772e41ca41dc332bb02725ab486e3b10a73c220
The breadcrumb section is used for a single pane mode for showing
the current user location. The breadcrumb should not be shown if
its title and subtitle are empty. The code in PreferenceActivity
onCreate updates the breadcrumb with the title and subtitle in
a single page mode but does not hide it if they are empty. This
change fixes that.
bug:11242762
Change-Id: Ib1ba9e8afd9d0ab2e85d78a65ca7c18489464f6d
1. The up event for a long press was not properly adjusted as the
long pressing finger may not be on top of the accessibility
focused item.
2. There was a scenario where two finger swipe leads to a crash.
One finger moves, second finger goes down but no finger moves,
the first finger goes up, and now the second finger moves. All
this has to happen before we decided that user is touch exploring.
Very hard to happen, this is why we could not easily repro the
crash.
3. We use the two finger vector angle to determine whether the
user is dragging or not. However, in some cases we were
unnecessarily waiting too long before performing the check
and as a result the notification shade on Manta was not
expandable.
bug:11341530
bug:11189225
Change-Id: Ieea39783444a1c20581f8addfd518d1c11485099
Actually, the state representation seems fine, but there was a problem
we are now hitting where the restart interval could get reset back to
0 when it shouldn't be. Also tune the restart parameters a bit.
Change-Id: I364f38e52f5387b2ec3f81009ccc78976ff48891
Move the logic for managing dimming the navigation bar
elements on the lockscreen into BarTransitions.
Replace search light + camera assets with new
versions at full brightness, and apply 50% dimming
at runtime, including the IME dismiss button.
Remove unused StatusBarManager _NOP hints.
Improve choreography between camera button +
password security (w/ IME). Fix a few found bugs
in PagedView.
Improve password security unlock transition, manually
fade in back along with the rest of the icons.
Bug:11221659
Change-Id: Ifd1f8c9f400d90542f0ca858b9a4deacabbd518a
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
