LayoutTransition causes artifacts in some situations where a window is just
becoming visible or a container is just being added to the view tree when animations
are kicked off in LayoutTransition due to the normal automatic mechanism of running
animations when views are added/removed/etc. The problem is that containers in these
situations may have children with positions and sizes of (0, 0), causing the animation to
animate from this default/nonsense value to whatever is appropriate for the views when
they are first laid out and drawn. The end result is correct, but the animation is
superfluous and silly.
The fix is to avoid running any kind of transition animation on windows that are not
currently visible or containers that are not currently atached to the view hierarchy.
This should avoid the situation by only allowing the animations to run after the containers
and windows are visible and set up correctly.
Issue #6544410 issue with layout transition when first showing the activity
Change-Id: I737b2598887ef806dec3b02a483a8e8ff2c3d4e2
When Face Unlock was used with pattern backup on a Prime, it was
partially covering the lockscreen music controls that appear when
music is playing.
This makes Face Unlock take up slightly less area when using pattern
backup on phones in portrait layout, regardless of whether the music
controls are showing. Eventually I would like to make it still use
the full area when the music controls aren't showing, but this is the
safest possible fix for JB and looks ok.
Change-Id: Ib2af440ed0f2729dfff9b58cd154efad43ef5499
Delaying the popup by using removeView instead of removeViewImmediate
caused an error when the removal was actually executed after the parent
window was deleted along with the popup.
Fixes bug 6407801.
Change-Id: Ieb17d58467aaf16e1a24f47187f52766d694ba32
We were eating too many jelly beans even when the screen was
off.
Also clean up touch offsets, rotation on fling, and main
platlogo asset.
Bug: 6541052
Change-Id: I34e49b8b7a95ce6daab929885130426a5ae58dc4
1. The code in clear accessibility focus was not updaing the global
accessibility focus reference in view root if the view not a
descendant has accessibility focus.
bug:6382856
Change-Id: I0c99578b5afd1f1f5d0df5bba05b0a03b5951a43
This fixes two issues:
1. The pattern view was shown too low on the device due to shared layout
with 720dp device.
2. The time was showing on top of the transport control view (music playback widget)
Change-Id: Id8a5809f96cfbda7eb55fa91b1bea826d483373a
This also removes the temporary logging from commit
f8dafa14e058cdc2f408b59be7911abaceb73c47.
bug:6535911
Change-Id: Icf1d0438b349a0e92e7d9cefed57a252eed2b9b0
Needed a little extra help from the builder to make this
happen (like the title, you might want a different largeIcon
in the expanded view if---as in this case---it is redundant
with the big picture).
Needed to fix BigPicture template to reveal actions.
Bug: 6289107
Change-Id: I19dc62e693ee2c87cbe82f7327fe9115768b4102
-> We cache RemoteViews which populate the AdapterViews, but only
up to a total memory amount of 2MB. The remainder of the cache
is pruned out. If _every_ item is greater than 2MB, we were failing
to prune the last item, leaving the framework in a loop on a bg
thread, but holding a lock required by the main thread.
Change-Id: I0574a25a59ebec6586ae223fff6605c0fee953c3
The problem was that when dismissing the lock screen, the window manager
would briefly turn off force hiding when it started animating the transition
and then turn it back on until the transition was done.
This would cause it to briefly switch focus to the app behind and then
take focus off it. The app would find out it got focus, and re-start
input on itself, asking the input method service to do so. At this
point the input method service would ask the window manager if the
caller really had focus, and it may or may not be told no depending
on the timing. If it is told no, then it doesn't allow the focus
switch to happen at that point, ignoring the new input connection,
and ultimately when focus does really switch the IME is left talking
with an old dead input connection.
I added some code to the input connection to make sure when we are
no longer using one that we mark it inactive and can't use it. This
bug was especially difficult to track down because it would only
visibly break when a GC happened during this time, causing the weak
reference on the input connection to become null. With this change
it will now always break (though in the scenario here only if you
hit the race condition correctly).
Change-Id: I81a6164dc140c548da1a9736e42cd253e8238a80
The API allows applications to post FrameCallbacks that will
run on vsync and that are provided with the frame time.
Change-Id: Ieb39fcdd085ef8a57805b8f78e7a307f416ff21d
1. This patch has somecode that syncs input and accessibility
focus or tries to put accessibility focus on the top most
container that was missed by the previous patch.
Change-Id: I08f21670b1c6e9f363d5714b1976fb52d84baae4
Bug #6531172
Changing the surface texture would not update the layer properties
nor its transform matrix.
Change-Id: I54e155a410d7e72f1a8edf3a4ab0034bf764ae28
1. Now accessibility focus does not drag input focus and
vice versa. Having the two focuses chase each other
can lead to some pathological cases. For example, a
container is input focusable and manages input focus
for its children i.e. as soon as it gets input focus
it sets input focus to a child. Now assume input and
accessibility focus are on a child and focus search
finds the parent to take accessibility focus, now
putting accessibility focus to the parent will put
input focus there and the parent will put input focus
to the child which as a result will put accessibility
focus there, thus resulting in traversal loop.
bug:6522900
2. Fixed asymmetrical behavior of accessibility focus search
for AbsListView.
bug:6520016
3. Fixed accessibility focus search getting stuck in an
empty AbsListView.
bug:6520049
Change-Id: Ia26e5be7b5a9f340f873861ff466c787467b98dc
