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
Added equals() and hashCode() to ArrayMap to allow equals() tests
of maps with the same key/value pairs to return true.
Changed putAll() to handle the case of an empty map faster, just copying
the arrays instead of adding elements one by one.
Added to ArrayMapTests to test new equals() and copy constructor
functionality.
Issue #9299310 Optimize ArrayMap copy constructor
Change-Id: I1186a0eddd1fd53a0f380c2f3972fc1942cdf879
Network stats are now read out of the kernel in one sweep, instead of
reading per-UID. We now accumulate the delta traffic between each
stats snapshot using the well-tested SamplingCounter pattern.
Since Wi-Fi and mobile traffic have different costs, track each
separately. Avoids counting misc interfaces like loopback and
ethernet under total.
Bug: 5543387
Change-Id: I642004dc530113c27ef79f2abbae51d8af30117f
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