- related to the previous change for saving the scroll position
- also related to bug #9463581 NPE observed while launching News&Weather app from all apps tray
Change-Id: I9f2f8a246e793eefa1cf510e15a56a1058fb9c18
Older apps may have given IDs to ScrollViews and views of a different
class in layouts that vary by configuration. Now that ScrollViews save
state this causes ClassCastExceptions when trying to restore instance
state.
Only save new instance state for ScrollView/HorizontalScrollView for
apps targeting post-API 18.
Change-Id: Icaa095cd20bef35dddc225a17c5a8e30b3faea02
* commit 'bafc8dcf690776ec7fdcf26518f3aff47724871d':
Revert "Make implementation of isEmpty consistent with implementation of getCount in HeaderListViewAdapter"
* commit '34bc73dff1f0c8402da3fc9bd1f0175bddcaa842':
Revert "Make implementation of isEmpty consistent with implementation of getCount in HeaderListViewAdapter"
- make FrameLayout capable of forcing a Gravity.LEFT (when there will be
only one child with Gravity.RIGHT and wider than its parent like for
HorizontalScrollView)
- fix onLayout() so that it is forcing Gravity.LEFT if needed and
setting correctly the initial mScrollX
- also add restore/save from an instance state (by saving if the layout
is RTL and the scroll position)
Change-Id: Ida7ff4654c6a54a1696c2575af46f044dd1aabc8
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
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
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
Basically, the root cause of this issue is a lack of an expected implementation.
This change completes the spec of the architecture to remove modified "SuggestionSpan"s.
Bug: 9190860
Change-Id: I63f2ccf3407ae7c1bc28813e044b8703e2112f34
