Clarified use of rotationAnimation. Did not add a comment
for ROTATION_ANIMATION_CHANGED as that would be inconsistent
with the other twelve <parameter>_CHANGED flags that it
follows in the source code.
Fixes bug 8657715.
Change-Id: I03b5caf3d6a93ca0044f58485c94c7a600e835a8
- in RTL mode only and if you have left/start or right/end at the same time,
the initial left/right padding (coming from the background drawable or from
some explicit definition) was still used.
- now, override the background left/right initial pading by the left/right one
only and only if there is no start/end padding defined at the same time
(because when start/end are defined, we do not care about left/right padding
except the background ones)
Change-Id: Icc6e69c95ace1307b0c5e9673cbdf3b611b62733
This checkin has preliminary API (in flux, definitely changes still
to be made) and implementation for a new "Scenes & Transitions" feature.
The current implementation allows you to define different Scenes
(via layout resource IDs or callbacks) and Transitions to be used when
changing to those scenes. By default, scene changes will use AutoTransition,
which generally does the right thing.
There are no overview docs or tutorials yet. The best way to learn how things
work is to see the code for the various tests in
frameworks/base/tests/TransitionTests.
Expect the API to change. Expect the implementation to change (mostly to add
more functionality). Expect bugs, but tell me if things do not work
as expected.
Change-Id: Ib025a9f565678b225afa4759325cf6d496cc7215
Fix a few typos in InputFilter. Fix reference in InputEvent currently
causing public documentation breakage.
Change-Id: I6268ad165f11d4d9d5a4a66ed97f1538e174cf84
The invalidate region when the clip bounds are set needs to encompass both
the old clip bounds and the new bounds, to make sure that the right area
of the view gets erased as well as drawn.
Also, we need to keep our own internal copy of the bounds, not just use the
instance passed into the setter.
Issue #8634060 setClipBounds() problems
Change-Id: I123c49cff16e3debe8866974a5612a4efd010de4
Implement new mode for status bar, allowing it to overlay
windows that use WM.LP.FLAG_FULLSCREEN, and introduce
transparency.
No gesture is implemented yet, for now the auto-hiding
status bar can be shown using a debugging intent.
android.intent.action.HIDEYBARS
The auto-hiding status bar hides 3 seconds after shown,
or 3 seconds after last user-interaction with the shade.
Change-Id: Ie4bd625b9cbcddea8f818154719c7a6075972f2a
Adding a view to an overlay usually entails removing the
view from its current parent, if it has one. ViewOverlay.add() will
do this automatically. At the same time, it will check to see whether
the parent view is in a different global location than the overlay's
host view, and will adjust the added view accordingly. This enables
the caller to simply toss a view into an overlay and have it end up
at the same global position on the screen.
the problem is that the current code doesn't bother to check whether
the old parent is attached. If that parent has been removed from the
view hierarchy before this overlay operation, then it will show up as
being at (0,0) in the window, not its old location. This results in the
view being mis-positioned in the overaly.
Fix is simple: if the view's old parent is not attached, simply remove
it from that parent before adding it to the overlay; don't try to compensate
for its position which is based on wrong information.
Issue #8620319 Overlay should only use relative window locations for onscreen parents
Change-Id: I414038a6c355dfd58f9766b007ac44d535ef1889
Split stacks and move tasks between them. Layout the windows
according to the new stack split.
After layout content rectangles are known split the available area
between all stack boxes. Then use those values for future layout.
Provide stack contents to ActivityManager.
Change-Id: I9746e6185445633810d506be514d0b7b540a7f99
since SF now relies on receiving a frame for latching the
transparent region hint, we make sure we will indeed redraw
something.
Bug: 8581533
Change-Id: Ia12ddf5654a7deeac7628b799bfde4b8c16c992b
1. The event dispatch methods should respect the child drawing order.
Hover event dispatch in ViewGroup was not repsecting this order.
bug:8606799
Change-Id: Ie2fd3aff1292c21df23a04ca0aa03a97813c44ef
Adding features which round out the animation APIs (missing
getters, etc.). Also fix doc typos.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I063736848ba26e6d6c809b15fc3a103c74222f46
A bug in FolderEditText or DynamicLayout (b/8600683) was causing
the 'rectangle' parameter passed to scrollToRectOrFocus() to be
roughly 1000 feet to the right of the screen.
This bug is normally masked because the focus found in
mLastScrolledFocus never matches the new focus and consequently
the misleading 'rectangle' is nulled. However, on the first
time in to scrollToRectOrFocus when returning to Launcher
from another app, mLastScrolledFocus is null and the code
skips over the place where 'rectangle' is nulled. Without this
clearing it was determined that 'rectangle' was outside the viewable
area and scrolling not required. This is bug 8547155.
This change causes even null values of mLastScrollFocus to be
compared to the new focus thus masking the bug in all situations.
Bug 8600683 will be fixed in a separate CL.
Fixes bug 8547155.
Change-Id: Ic6cb22c42b0e93a9793dd2babc25727c2ba29155
The last frame of an animation stays stuck on the screen for a couple of frames.
Specifically, the "Quick Contact" animation that animates the picture
closed (fades/scales it away) animates all the way to the end... then hangs there
briefly before being taken down.
The problem is a rendering bug where we correctly detect that a DisplayList
has nothing to draw (since the last frame is completely transparent, alpha==0),
but incorrectly ignore the fact that we cleared the transparent-background
window prior to not-drawing that DisplayList. When we detect that there's
nothing to draw, we don't bother swapping buffers. So even though we drew
the right thing (clearing the buffer), we didn't actually post the buffer to the
screen.
This change factors in both the clear and the draw to decide when to swap buffers.
Issue #8564865 Quick contact close animation jank redux
Change-Id: Ib922cff88a94f025b62f7461c1a29e96fe454838
The new implementation more accurately tracks the velocity
of flings and takes care to avoid obvious discontinuities.
The main goal is for a fling to appear to be a linear
extension of the movement already in progress. The minimum
fling velocity is set to ensure that flings appear to be
fairly smooth despite being discretized.
Use sequences of repeated key events instead of individual
down/up events to represent continuous motions in one
direction which can be helpful for stopping flings at boundaries
such as when flinging the cursor position within a text view.
Compute the movement thresholds based on the physical
size of the touch pad, if known. If not known, we assume a
nominal size.
Support stopping flings with a tap just like we do for
normal touch events elsewhere in the framework.
Moved the detection of ASSIST swipes into the InputReader
where it belongs. These swipes must be detected globally
to ensure consistent behavior across the all applications.
Added a custom protocol in EventHub to enable input device
drivers to override the timestamp of the following events
in a packet. This change enables input device drivers
that have a better idea of when an input event was actually
generated to pass this information to the input system.
Particularly useful with uinput.
Bug: 8583760
Change-Id: I8ef4e827804786d549cfaa00793a2b9dd0fda465
