Transitions used to be three phase:
- captureValues(): get all relevant property values in the
affected view targets
- setup(): set appropriate start values for affected views
prior to any transitions being played
- play(): create/play Animators for affected views
Now the second and third phases have been collapsed (and named
"play()"). This single step sets initial values for target views
and creates any Animators that should be played during the transition.
The transition mechanism stores these Animators and then starts
them at the appropriate time in the overall transition.
Issue #9507585 Transitions: Simplify Transition.play() design
Change-Id: I3fc67599b38fe49eee885dc5d32444db90b7703b
This has a minor API change: deprecation of the nullary constructor.
The class is entirely composed of static methods, and was written
without a constructor, but the compiler dutifully generated a
default implementation and the API tool slurped it up.
The other changes are to the documentation:
- Added warnings about the use of overlapping input and output
on certain methods.
- Fixed a few inaccuracies (e.g. transposeM() returns a transposed
matrix, not an inverted matrix).
- Tidied up the formatting.
- Generally placated the consistency hobgoblins.
Bug 8868762
Change-Id: Ie3f86b98c477d8dc82d9dcaa311959bd4d191359
Previously, Fade transitions did not work correctly on hirearchies; they
only handled individual views. in particular, they would side-effect all
fading views by removing them from their parent to fade them out in the
overlay of the scene root. This worked for the fade-out transition itself,
but caused problems when those same hierarchies were added back in and
another Fade was run on the hierarchy, because now all of the views inside
that parent node had been removed, so they didn't fade in at all.
The fix was to add logic in Visibility to detect when a disappearing
view was inside a hierarchy that was also disappearing, and to skip the
fade on the views inside that hierarchy, leaving only the top-most
disappearing view to be faded out, thus preserving the hierarchy under
that faded-out group.
Along the way, there were various cleanups, fixes, and refactorings in the
transition code, and slight API modifications.
Issue #9406371 Transitions: Removing view hierarchy not working correctly
Issue #9470255 Transitions: Separate different transitions by Scene Root
Change-Id: I42e80dac6097fee740f651dcc0535f2c57c11ebb
This change adds simple APIs that enable an Android application
to generate a PDF document by drawing content on a canvas.
Change-Id: Ibac93d7c37b01a376ce7c48238657d8c7698d588
This change enables applications to create a private virtual
display that renders its content to a surface of its own creation.
The display is private in the sense that only the application
that owns the display is allowed to place windows upon it.
Mirroring and blanking is also disabled for these displays.
Bug: 9192512
Change-Id: I852ea07f0c7df1d244e354e3daca3a6960285ca0
This change adds several traits and properties to AccessibilityNodeInfo
aiming to allow better description of native Android components to
accessibility services as well as mapping web content to native Android
node info tree.
Change-Id: I36b893cbaa6213c9d02d805e9dc36b6d792b4961
Change call log so instead of overloading the phone number with special
strings "-1", "-2", etc to denote private phone numbers, payphones, etc,
put presentation type in its own column and expose in the public API these
type values.
Bug:6948882
Change-Id: I230c26aa0428d605a0e83169a635b5bbf1aa4e3f
This change adds simple APIs that enable an Android application
to generate a PDF document by drawing content on a canvas.
Change-Id: Iddcd126b3af37c73d99262f6b276caa07b998c1d
isAttachedToWindow does what it says on the label and provides a
standard, public API for checking a view's attachment state. This
removes the need for tracking this out of band in response to
onAttachedToWindow/onDetachedFromWindow in custom view
implementations.
hasLayout returns true whenever the view has been through at least one
call to layout() since the last time it was attached to or detached
from a window. This allows for standard checks in code that needs to
behave differently if first layout has not completed yet, such as
whether or not to no-op an animation in order to set up initial state.
Change-Id: I8dab70dcd5a22a32e260ed50987ccdaa4100072b
Add TransitionManager.beginDelayedTransition() to handle starting a transition
on the next frame for a given scene root based on all changes that
take place between the first call to that method and the next animation frame.
Issue #9321937 Transitions: consider batching up multiple scene actions
Change-Id: I3fc92b6b4ec5ff42b1e678bcfd385703e32eba2a
- New core API classes in android.hardware.photography
- android.media.Image and android.media.ImageReader classes for
application access to direct hardware image buffers.
- Additions to android.graphics.ImageFormat to describe new image
types needed by new camera API.
- Some documentation included; very little implementation.
Bug: 9111736
Change-Id: I0680f35944d1cb8845b7dc0c67edc8c0f0864573
