* changes:
Fixes#1853550. Prevent NPE when calling the PopupWindow() and PopupWindow(int, int) constructors. Instead, throw an IllegalStateException when trying to show a popup with no content view.
* changes:
Fixes 1844680. Interrupted scrolling could lead to rendering artifacts. The ListView was invalidating itself in opaque mode but before the drawing could happen, it was getting rid of its scrolling cache, thus becoming translucent again.
* changes:
Fixes#1596240. Optimize invalidate/draw passes by marking opaque views and avoiding drawing them. Whenever a View requests an invalidate its parent check whether the view is opaque or not. When the view is not opaque, the framework behaves as it used to. However, when a view is opaque, the parent marks itself as being dirty because of an opaque view. Its parent then does the same, and so on. When the framework then starts drawing the views, it does not draw views marked as dirty opaque. If a view is dirty opaque and receives an invalidate request from a non-opaque view, it then clears the dirty opaque flag and behaves as before.
with respect to the soft keyboard. getMaxAvailableHeight in
PopupWindow relies on View's getWindowVisibleDisplayFrame, which
always takes into account the IME, whereas in this case, because
we want the window to extend down to the bottom of the display
when it is being interacted with by the user, I added a new
boolean option 'ignoreBottomDecorations' to getMaxAvailableHeight.
If true, the method returns the height which will extend the
PopupWindow down to the bottom of the screen, rather than just
down to the IME.
Then in AutoCompleteTextView, I set this to true when the
dropDownAlwaysVisible attribute is true and the PopupWindow's
input method mode is INPUT_METHOD_NOT_NEEDED (which happens when
the list is dragged or otherwise interacted with).
Then, because the dropdown height is only calculated when we call
showDropDown(), I had to replace a couple calls to mPopup.update().
There are still a few remaining bugs here I'm tracking Still to do:
* Fix a strange re-placement of the window which happens
intermittently.
* Strange behavior when using the directional pad.
* In a few cases, the list does not correctly size itself to the IME.
This seems to be because the available height is calculated before
the IME is yet on screen, and thus is calculated as the entire screen.
* changes:
Fixes 1830181. Tapping disabled items in a ListView would cause the framework to take a code path that wasn't resetting the mMotionCorrection variable if it had been previously set. This would force ListView to apply a scroll to its children even though it was unnecessary. This simple fix prevents the issue by resetting mMotionCorrection appropriately.
* changes:
Fixes 1819406. Take a ListView, add headers/footers, set the adapter after at least one layout pass, and the headers/footers don't know they have a parent anymore. Which causes a lot of trouble, like drawing not happening.
The back key now dismisses the soft keyboard, and then the dialog.
The soft keyboard behavior is improved by having ACTV do the following when 'mDropdownAlwaysShowing' is true:
- touching outside of the drop down doesn't dismiss it
- touching the text field ensures the imei is brought in front of the drop down
- all public apis and framework changes have been reviewed by relevant folks in our branch (e.g romainguy)
- all new public apis are @hidden; they will still get reviewed by api council once we're in git
- other than that, it's mostly GlobalSearch and search dialog stuff, a new apps provider, and some tweaks
to the contacts provider that was reviewed by jham
Automated import of CL 147564
We use a single outstanding message of type SHOW_PROGRESS to refresh the progress
bar's current position as well as textual display of time and duration. This message
could get lost if the scroll ball was used to adjust the current playback position as
we entered state "mDragging" which would cause the subsequent SHOW_PROGRESS message
to be a no-op and would also cause it to not be re-enqueued.
The change refactors the seekbar logic a little and makes sure that while dragging
there isn't a pending SHOW_PROGRESS message in the queue and once dragging is over,
exactly one SHOW_PROGRESS message is reenqueued.
related to bug 1721227
It should be renamed to something more meaninful before being exposed.
Original author: jsharkey
Merged from: //branches/cupcake/...
Automated import of CL 145860
#1748954 (New status bar fades into all white background): FrameLayout wasn't updating its foreground drawable when its padding changed, which would happen as the status bar is shown and hidden. To fix this I also ended up fixing a problem in the view debug stuff where we couldn't get a bitmap for a view that is the full screen size because it is too big... actually I just went ahead and added another function to snapshot the view hierarchy which works a lot better for us anyway.
#1737952 (Home screen icons overlap with the notification bar after exiting any camera app): Originally I punted this because it only happened in rare situations, but now that home is always portrait it happens a lot more so it is more important to fix. This involved a few things to clean up hiding/showing the status bar:
- We now determine when to hide and show it during layout, which allows us to do this at the time it is actually needed rather than during animation after we can actually catch it for the initial display of a window. This required tweaking the layout API so the policy can request a second layout pass if needed.
- When doing layout, we are now much more aggressive about skipping the layout of windows. Basically anything that we know will be hidden in the near future is ignored for layout, so that it doesn't glitch as it is transfered out of the screen. The theory being that it is better to leave it as it was originally placed while we are transitioning it out, than to switch it to something slightly more correct.
Original author: hackbod
Merged from: //branches/cupcake/...
Automated import of CL 143899
