This new method on view reflects whether the view has been laid out
at least once since it was attached. hasLayout() seems too vague for that
meaning; every View that has a parent has a layout (since we use container,
parent, and layout interchangeably). The new version of the method
is closer to the actual meaning.
Change-Id: I519745739b6a6317faeb077aa61f994025cf81f3
Some of the code in setButtonDrawable() was unnecessary, resetting
the button drawable state and then refreshing it. This caused many redundant
calls, which can add up, especially during inflation.
Change-Id: I873cf5eef697b5435a1b827cd68e5d836ee25124
- 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
