This class has existed since ICS, but was hidden. This change
just makes it public API.
Also, cleaned up some internal javadocs.
Change-Id: Id69408446ced183e01d2b065a67397eb305d9665
LayoutTransition side-effects the alpha property on View to fade views
in and out. This works fine if the layout transition is always used on
those views' container. But if you fade out a disappearing view and then
set the transition to null on the container and set that view to VISIBLE,
there is no transition logic to restore the alpha value to 1 (opaque).
The fix is to always restore alpha to its pre-animation value when fading
the view out.
Also, added extra info to alpha and the various View transform properties
to help hierarchyviewer debugging.
Issue #5958434: LayoutTransition temporary disablement may leave some views invisible
Change-Id: I3c21b0e7334dc29c10c5e372b589f0e2b59c2883
This new setting allows users to set a scale factor for the
duration and startDelay of all Animator-based animations. This
setting is very similar to the Transition animation scale and
Window animation scale settings, except this one applies specifically
to Animator animations. The property is only accessible by users
through the Settings UI, not programmatically. The value applies
system-wide and is picked up per-process at the time of the first
ValueAnimator construction.
This is an update to a previous CL; this approach uses the WindowManager
to store the animator scale settings, instead of SystemProperties.
Change-Id: I8295fab060aa6d597ae507ded8f9c9d6077be966
The render threat is likely to break your application if you initiate it.
As such it must be explicitely requested using the following meta-data
tag in your manifest's application tag:
<meta-data android:name="android.graphics.renderThread" android:value="true" />
Change-Id: Ibf0a48af2a0d091562bf6907eac970e3d1d601c4
Users have requested the ability to sequence ViewPropertyAnimator
animations. it is not possible with AnimatorSet, which only takes objects
of type Animator (which VPA does not extend). But the AnimatorSet model
is not appropriate for VPA anyway, since it is not possible to set up
a VPA ahead of time to start later; it's just not the way that VPA is
intended to work.
Instead, there are now two new methods on VPA, onStart() and onEnd(). These
methods take a Runnable which is executed when the animation starts or ends.
These methods should allow other VPAs or other arbitrary code to execute at the
start or finish of any particular VPA animation, allowing simple sequencing
without the overhead of creating listeners and monitoring the cancelation status
of the VPA.
Additionally, this change adds a new method withLayer() which sets a hardware
layer on the VPA's target view for the duration of the animation. This
was already possible, but required writing boilerplate code to create a listener
and override the start/end methods to add and remove the layer. This utility method
makes this common use case much simpler and less error-prone.
Change-Id: I819978517e17c647ffb7028063cd0adde68ff691
These markers will be used to group the GL commands by View in the
OpenGL ES debugging tool. This will help correlate individual GL
calls to higher level components like Views.
Change-Id: I73607ba2e7224a80ac32527968261ee008f049c6
When a view is becoming VISIBLE or INVISIBLE in a container with a
LayoutTransition, animations run to fade the view in and out and also
to run 'changing' animations on the view's other siblings. This logic
also cancels any running 'changin' animations to account for new ones
running.
However, in the specific case of INVISIBLE changes, there will be no
layout changes in the container - layout has already accounted for that
view (unlike in the case of GONE views); the visibility is just a matter of
drawing the view (or not). Therefore, we're canceling 'changing' animations
that should continue running and not replacing them with any other animations,
since new animations would only be started on layout chnages which are not
forthcoming.
One artifact seen from this bug is that the navigation bar buttons sometimes
disappear when changing orientation. This is because the menu button may
toggle between VISIBLE and INVISIBLE, causing animations on the other
buttons to get canceled, which leaves those views in a completely wrong
state.
The right thing to do is to avoid canceling in-process 'changing' animations
and to skip the logic of setting up new 'changing' animations which won't fire
anyway.
There is some minor API work in here because we did not previously have the
necessary information in LayoutTransition to know whether a view was being
hidden or shown to/from the INVISIBLE state.
Issue #5911213: LayoutTransitions ending in an odd state
Change-Id: I5c60c8583c8ea08965727b4ef17b550c40a3882c
Previously, we'd pass in a scale factor (based on whether the app was
being scaled by the compatibility mode) to Animation.getTransformation().
This scales the pivot point of the animation based on thes cale factor.
However, the pivot points were already using information that took the
compatibility mode scale into account. For example, using ABSOLUTE and basing
pixel values on the width/height of the view would give you values relative to the
width/height of the view (pre-scaled). Using RELATIVE_TO_* would use percentages
for the pivot point, again taking the scaling of the view into account. So scaling
the pivot point added in another scale on top of that already being applied.
The net effect was to scale the pivot point in cases where it should not be scale.
For example, setting a pivot point to half-way (.5 and RELATVE_TO_SELF) would
end up with an animation that would pivot around the bottom/right of the view.
The fix is to simply remove the scale factor being passed in; we've already accounted
for it in the pivot point, so we shouldn't concatenate it into the transform
calculated by the animation.
Change-Id: I9daa7581b1b9d0dfb10515e96947160c28c5130e
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused. Also note that at the end the View did not
clear its focus, hence no focus change callbacks
should be invoked.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: Iee80baf5c75c82d3cda09679e4949483cad475f1
1. Now when an interrogating client requires an AccessibilibtyNodeInfo
we aggressively prefetch all the predecessors of that node and its
descendants. The number of fetched nodes in one call is limited to
keep the APIs responsive. The prefetched nodes infos are cached in
the client process. The node info cache is invalidated partially or
completely based on the fired accessibility events. For example,
TYPE_WINDOW_STATE_CHANGED event clears the cache while
TYPE_VIEW_FOCUSED removed the focused node from the cache, etc.
Note that the cache is only for the currently active window.
The ViewRootImple also keeps track of only the ids of the node
infos it has sent to each querying process to avoid duplicating
work. Usually only one process will query the screen content
but we support the general case. Also all the caches are
automatically invalidated so not additional bookkeeping is
required. This simple strategy leads to 10X improving the
speed of the querying APIs.
2. The Monkey and UI test automation framework were registering a
raw event listener for accessibility events and hence perform
connection and cache management in similar way to an AccessibilityService.
This is fragile and requires the implementer to know internal framework
stuff. Now the functionality required by the Monkey and the UI automation
is encapsulated in a new UiTestAutomationBridge class. To enable this
was requited some refactoring of AccessibilityService.
3. Removed the *doSomethiong*InActiveWindow methods from the
AccessibilityInteractionClient and the AccessibilityInteractionConnection.
The function of these methods is implemented by the not *InActiveWindow
version while passing appropriate constants.
4. Updated the internal window Querying tests to use the new
UiTestAutomationBridge.
5. If the ViewRootImple was not initialized the querying APIs of
the IAccessibilityInteractionConnection implementation were
returning immediately without calling the callback with null.
This was causing the client side to wait until it times out. Now
the client is notified as soon as the call fails.
6. Added a check to guarantee that Views with AccessibilityNodeProvider
do not have children.
bug:5879530
Change-Id: I3ee43718748fec6e570992c7073c8f6f1fc269b3
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
This fix does not include the change to ignore app tokens that are
hidden. This causes problems in some dialogs that stay hidden until
their app is ready to display, but need to perform a series of relayouts
during that time to get to the right size. Dropping this part of
the change still (mostly?) seems to allow us to avoid the bad states.
Change-Id: Ic052cb1499d3287f47e9ffeac5cd2470ee5a308c
Also relaxed the settle time constraints a little bit.
With this change, a rotation proposal will always be
advertised within 500ms even if the device is still shaking
around.
Bug: 5496491
Change-Id: I0bf562f4c19c0be45c016254f2f881d265f8e266
This fixes a bug where the device fails to lock when DevicePolicyManagerService
requests the device to be locked and the screen was off because the user hit
the power button.
The change allows DPMS to directly invoke screen lock, bypasssing the screen state.
Change-Id: Iecdda6fc61e9c519119de495be23c69c3b983921
