The result from getKeyDispatcherState() was used without
checking if it returned null, which resulted in a NullPointerException.
Change-Id: I4b55ad44d5c08b7f729dbbdbcaed0e978a430258
* commit '6504490cde3ec5d48321d539e654d1f2072b33f9':
GpsLocationProvider: Clean up HAL initialization/cleanup sequence
Fixed GSM encoded network initiated position request
Ensuring thread-safe usage of DateFormat.
Fixing infinite loop for zero duration.
Fix for an infinite loop while scrolling lists.
WAPPushManager, WAP Push over SMS message handler
Add --non-constant-id to aapt.
* commit 'dff6b8e71dda9f5d841fa26408714aec2aef1505':
GpsLocationProvider: Clean up HAL initialization/cleanup sequence
Fixed GSM encoded network initiated position request
Ensuring thread-safe usage of DateFormat.
Fixing infinite loop for zero duration.
Fix for an infinite loop while scrolling lists.
WAPPushManager, WAP Push over SMS message handler
Add --non-constant-id to aapt.
The ICU CLDR data doesn't use the month abbreviations that are
appropriate for the DatePicker, so use the framework copy of the CLDR
data.
Bug: 2641810
Note: cherry-picked from Honeycomb
Change-Id: I3c045dbfb751b8b7ce6361b5a67407206fc64db1
When scrolling in a list it's possible to get stuck in a
loop where the screen is continuously redrawn. This happens
when you are at the end of a list and try to scroll further.
The problem is that you enter a switch statement with the
mState variable set to STATE_PULL_DECAY. This will trigger
code in the switch statement that does some adjustments and
calculations, but it does not change the value of mState to
STATE_IDLE or STATE_RECEDE after it's done. Hence it will
continue to return to the same place and not stop updating
since the update() method signals for completion only when
the mState variable is set to STATE_IDLE.
The fix is changing the value of mState after the
adjustments and calculations have been made.
Change-Id: I57bc84ec12d43ca87a1163d94cb5b206a376a24e
Fix for issue #12945: Changing the maximum of a progress bar does
not cause it to be redrawn, even though a new maximum changes the
position of the current progress in relation to its maximum. With this fix,
setMax() will always cause refreshProgress() to be called if the maximum is
different than it was before.
Change-Id: I971ec3302953bcadc0aac3dd8241481bab2b5a91
This is a convenient way to switch to selection mode without the
context menu. Context menu is still available and offerts Select Input method option.
Browser overloads touch events and this feature is not available in Browser which
limits the conflict with double tap zoom in browser.
Change-Id: I286504cf03733d5c2fb9bc01765f713d14bbd2f4
Fixes a regression from Froyo. Previously, when a scroll view
had no children, its onTouchEvent would return because the scroll
view would only start dragging if the user touched one of its children.
In Gingerbread, the user can drag from anywhere within the scroll
view, not just by touching a child. However, it makes no sense
to drag a scroll view that has no children so an empty scroll view
should just ignore touches like any other empty view group would.
This change fixes applications that for some reason or other happen
to have empty scroll views in strange places.
Bug: 3246230
Change-Id: I76c6136d3cd74968983033014d60deec1718ce30
Bug 3201383
Highlighted is different from selected, only the background is modified
and selection mode is not started.
Tapping inside a highlighted text places the cursor. This is especially
useful for WebView and search bar has been modified to select all on focus.
Selection handles time out is no longer needed.
This CL is pretty involved and especially messes up with the terrible
ExtractedTextView, which causes a lot of problem with text selection
across device rotations.
The current implementation works pretty well. It has one problem: the handles
are not displayed when switching to landscape mode with a selected text.
This is still an improvement over the current GB version, where the handles
are not preserved at all across device rotation and where I can find more bugs.
Handles are now hidden when a context menu is displayed.
I can polish this more if we decide to include this in the MR1.
Change-Id: Id10bf2808ff25752efd59a1987e91d609ba478cd
This prevents these runnable from holding a reference to the context
that will prevent it from being garbage collected.
The blinking cursor is especially bad and appears in memore traces.
Change-Id: I8acbfbbfc59975dfd7bcf06e941074ea7dc0b0bc
{com.android.settings/com.android.settings.applications.StorageUse}
AbsListView could call mAdapter.getItemId() if a save state happened
after the data changed but before a layout occurred.
Change-Id: Ica020971dc458dff79b56dd810733e217f4f7da6
As the Arabic language formatter would make number "1,2,3" to Arabic
language word means one,two,three, NumberPicker won't like to show
any thing other than numbers, add local settings to US, make the
number 1,2,3
Change-Id: If2d161ac4133f6c9c6e1ec284d6d2fbf01855fa0
extract mode IME window
Make the SelectionModifierCursorController track its show/hide state
more accurately in the presence of an extract mode IME.
Lazily initialize CursorControllers so that we don't end up creating
them for various TextViews where they are not needed.
Change-Id: Ib76a95d9e7669016cf11b8b0add8843b438068ea
TabWidget orientation specified in tab_content.xml instead of TabWidget.java.
Generally, the orientation of the TabWidget should be set in xml-files
and not in TabWidget.java. A sub class of TabActivity may call setContentView()
using a custom layout where the TabWidget orientation is vertical.
This is the case in the UI Enablers Bottom Tab feature, for landscape
display orientation.
Change-Id: Ia677441a0af96a8d2ab47ef3298eb440c34924f6
