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 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
We fire view subtree mutation events every X amount of time.
It was possible that the runnable that fires an event to be
scheduled more than once while this should not happen. As
a result there was a crash since we did not expect to have
a second run and nullified a reference.
bug:9422804
Change-Id: I914e163b026cd217e1536ab0ed3a6b11113c2c73
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
If WindowManager.addView() is called soon after
WindowManager.removeView() then the MSG_DIE in the ViewRootImpl
mHandler queue may not have had time to execute. This will cause
WindowManagerGlobal to throw an exception since the DecorView
is being added before it has been removed.
This fix detects that situation by saving all Views that are queued
up for ViewRootImpl.doDie(). If addView() is called for one of these
Views then doDie() is called immediately and not called when MSG_DIE
eventually makes its way through the queue.
This change also makes doDie() non-reentrant by only allowing it to
carry out its functions the first time it is called. This keeps
dispatchDetachedWindows() from causing destruction by recursively
calling back into doDie(). This is usually caused by calling
dismissDialog() from within dispatchDetachedWindow().
Fixes bug 9404689.
Fixes bug 9406261.
Change-Id: Id4fc8054e273215d82366428fef51b9ba98385fe
Implement all system level InputEvent monitors as new
InputEventListeners. Only one InputChannel required and monitoring
can be enabled or disabled by registering with WindowManagerService.
Change-Id: I64714ab858342ed183c62b421098478ffb6637bc
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
We fire notifications that the a view subtree changed for accessibility.
In some cases the notifications were fired if accessibility is not
enabled. This is now fixed. Also the runnable for making the recurring
subtree change was not dequeued if it was pending but we received a
request which we decided to run immediately.
bug:9337912
Change-Id: I27401b3d11f81c653e8761a704ee530263b08c3a
Fix bug introduced by deferring nulling of mParent.
In dismissDialog the removal was being put on a queue while the
state of the Dialog was being updated immediately. This meant that
if a show() was called before the remove was executed it would try
and add the DecorView a second time. Boom!
Fixes bug 9370301.
Change-Id: I576d1e207c786bc2e21dfd40cb94f2b63a020fe2
Bug #8725945
Selecting text in an EditText causes the View to have transient
state. This would in turn cause the View to be removed from its
ListView parent. When removed, the EditText would lose its
AttachInfo, causing all sorts of problems. Headers and footers
must not be removed, only detached. This is the part of the fix
in AbsListView.
Fixing AbsListView triggered a second bug: when a View is removed
from the Window manager, it would keep its parent assigned, thus
making it impossible to add it again to the window manager. When
a ViewRootImpl goes through doDie(), it must set its content view's
parent to null to properly cleanup.
Change-Id: I0489daa74f8f7fcf85526f0928f8925ec30d4f42
- 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
Cloning drawables (which happens a lot) was creating copies of NinePatch
objects, which would cause the hardware renderer to generate more meshes
than necessary. Also avoid keeping a String we don't need (it was interned
but still.) Last but not least, remove 1 RectF per NinePatch in the system.
Change-Id: If4dbfa0c30892c9b00d68875e334fd5c2bde8b94
The three arrays were being reconstructed and copied for each add
and each remove. By replacing them with ArrayList only three
constructions total are required. Also, the number of
System.arraycopy() calls is halved.
Change-Id: I0f8def1b517eb1bc5f930fcd5d3d1e0394071f0e
Conflicts:
core/java/android/view/WindowManagerGlobal.java
Small fixes in CrossFade to handle more general situations.
Also, added API to CrossFade to enable different behaviors during
the transition.
Change-Id: I12d17ab8f8f96be370c070373112ad8a62df9115
When relaunching activities the window manager clears out all windows
by calling a ViewRootImpl.die() in a deferred fashion. Then it
immediately deletes the ViewRootImpl and its view from its list
of windows. When the die() is eventually executed it calls
dispatchDetachedFromWindow() which tries to remove the previously
removed windows causing an Exception to be thrown.
This change waits to remove the windows until after die() has been
completed. Fixes bug 8253030.
Change-Id: I5b41be1c6b776e32128c064267653db98bd95292
When a View is added to a ViewGroupOverlay, it must not be parented
in another container. If it is, it will automatically be removed.
This works in general, but if there is a LayoutTransition on the
view's parent, then the actual removal will be delayed until the
transition completes. This means that the call to add(view) in
the ViewGroupOverlay's container will fail and throw an exception because
the view is still parented for the duration of the LayoutTransition.
This fix cancels the running transition to ensure that the view is not
parented prior to adding it to the overlay's container.
Issue #9303245 Crash combo: add(View) and animateLayoutChanges
Change-Id: Id4eaddccf64c353fc77e020882b978cdeb14c0ef
1. Before we were firing an accessibility event from the common
predecessor of views with accessibility related state changes
every X amount of time. These events designate that the tree
rooted at the source is invalid and should not be cached.
However, some of the state changes do not affect the view tree
structure and we can just refresh the node instead of evicting
and recaching nodes infos for views that did not change. Hence,
we need a way to distinguish between a subtree changed over a
node changed.
Adding a new event type will not work since if say two siblings
have local changes and their predecessor fires a window state
change event, the client will drop the subtree rooted at the
parent including the two views with changes. Subsequent, more
specialized events emitted from the two changed siblings will
be useless since the parent which did not changed is already
evicted from the cache. Conversely, if the specialized events
are fired from the two siblings with local changes and they
are refreshed in the cache the subsequent window state change
event from the common predecessor will force the refreshed
nodes to be evicted.
Hence, to enable distinction between node being changed and
a subtree baing changed while not changing existing behavior,
we will fire only window content change event with an additional
argument specifying what changed - node or a subtree for now.
Also if the changes are local to a view we fire the window
content changed event from the view. So, the two siblings will
fire such an event independently and the client will know that
these are local changes and can just refresh the node. If the
changes are structural, then we fire the window state change
event from the common predecessor.
2. Added the input type of a text view as one of the properties
reported by an AccessibilityNodeInfo. It is nice to prompt the
user what input is expected.
3. Added a bundle for optional information to AccessiiblityNodeInfo.
For example, it will be used for putting web specific properties
that do not map cleanly to Android specific ones in WebView.
4. AccessibilityInteractionController was not taking into account
whether the current accessibility focused node is shown before
returing it. Hence, a disconnected node would be returned and
caching it puts our cahche in an inconsistent state.
Change-Id: I8ed19cfb4a70bdd7597c3f105487f1651cffd9e0
