| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Use the public API version of the same thing that the private API
access was doing. No behavior change.
Test: built
Change-Id: I4a9032cfb1d4e699f72df3b079ef363d308419e8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug: 65715616
There are two places where views were being removed improperly
during transitions. The first was when making a copy of a view.
Because of hardware bitmaps, views were being moved to the overlay
so that the image could be copied. This CL moves the view back
into its parent after copying the image.
The second location is where the view was being considered an
overlay. When a view is in the starting scene and the view in
the end scene cannot be used, the starting scene view was being
moved to the overlay. This is only valid when the view is alowed
to be removed. Instead, a bitmap copy of the view is moved to
the overlay.
Test: manual testing
Test: I0456d8a699525b08b044236c558b2d84b48c29a6
Change-Id: Ieb32b146cf65e3ff4ed6d7bb8325e74763dbd2d5
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bug: 67049319
TransitionUtils was returning null when the View wasn't attached,
but Visibility transitions can do that intentionally. This CL
temporarily adds detached views to the view hierarchy as part of
an overlay while creating the hardware bitmap representation.
Test: ran transition CTS tests
Change-Id: Ie335619953653dce0224514f0d5c9c8eb00ee1a9
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In transition animations, in order to capture the content of a view
or a drawable in a hw bitmap, a RenderNode needs to be created. The
RenderNode was previously setup with no owning view. As a result,
in cases where RenderNode animations are triggered by the draw calls
in displaylist recording, these animations would fail for lack of a
view to animate on.
This CL ensures that when RenderNodes are created for the purpose of
populating content in a hw bitmap in transitions, there's always a
view associated with each RenderNode.
BUG: 65160121
Test: Force to repro crash by changing press state during hw bitmap
creation, which triggers a ripple animation that led to the
otherwise timing dependent and hard to repro crash.
Change-Id: I2b4ba95cad25a94d50b3904e775606f737e960e3
|
| |/
|
|
|
|
|
| |
BUG: 65160121
Test: Unable to repro the crash before or after the fix
Change-Id: I84fa28557c67a6672b8d82443d4da7be4f28a50d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug: 64851247
Drawing to software bitmaps does not support many
features, most especially hardware bitmaps. This
changes the implementation to using hardware bitmaps
for View snapshots.
Also fixed broken TransitionTest discovered while
testing.
Test: I4ede02db67e578ea4a25069b683f1989c611e06c
Change-Id: I185bbfe1f789055c9efdba5297a74e481607afaf
|
| |
|
|
|
|
|
|
| |
So that SharedElementCallback can setup initial imageView scale
type properly to run transition against.
b/17703309
Change-Id: I0ab212e0413fd666de605bc51ef64c8d66e4d09d
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Have maximum size for Visibility transition bitmaps.
Also changed Visibility to avoid transitioning out child views
while transitioning out their parents.
Also moved view-to-bitmap code to common utility.
Bug 17469198
Change-Id: I05f069a267539b479da1b39cdad2cc9270c5c381
|
| |
|
|
|
|
| |
Bug 17188255
Change-Id: I506a097be4010d7156caf465c95295c58612c16e
|
| |
|
|
|
|
|
|
|
| |
Bug 16460123
Modified ChangeTransform to support any pivot changes.
Modified ChangeTransform to support changes between parents.
Change-Id: I6374890dab9f3d795f334b951bdb9d51d434b8ee
|
|
|
Change-Id: If22ab5162737f2d109e5eaf407a735523a146b7f
|
