Fix unexpected rotation change when re-enabling auto-rotate

getProposedRotation() method returns old value when re-enabling
auto-rotate option. So you can see unexpected rotation change
with the following steps.

settings -> display -> enable auto-rotate
-> rotate device to landscape -> disable auto-rotate
-> rotate device to portrait -> enable auto-rotate

This patch makes mSensorEventListener reset before it is registered again.

Bug: 7964531

Change-Id: I6a8d287bbd9809ef31de67c54efb885e9a4fd76f
Signed-off-by: Sangkyu Lee <sk82.lee@lge.com>
avoid multiple-"0" to exceed the length of upper bound

Limits number of "0"s not to exceed length of maximum number allowed
for the NumberPicker.

Steps to reproduce:
1. Settings -> Date & time -> uncheck "Automatic date & time"
2. Select "Set time"
3. Select Time Area on Set time dialog
4. insert 00000000 via NumberPicker

Bug: 8073759
Change-Id: I0f3f5303d9a4b559217adb436f244407a23e58c0
add reply.writeNoException() for quick response

In case of SET_ACTIVITY_CONTROLLER_TRANSACTION, there is no reply transaction.
So makes same to other transactions.

Change-Id: I3b9527682662a12f78cc96b6084904f18178fee7
Fix bugs regarding IllegalStateException during moving position in cursorwindow.

"startPos + addedRows < requiredPos" could miss a row in boundary position.
Because of the fluctuating row size, "startPos + addedRows < requiredPos" expression could miss a row in boundary position.
For example, simply speaking,
if window capacity = 120 and requiredPos = 120,
"fillWindow" needs to be newly called and "starPos" is 80 for the window.
Unfortunately 120th row is bigger than the rest size of the window,
the row for requiredPos is not in the window.
Then, startPos has to be newly set and the 120th row has to be included in the window.
But by the expression above "startPos + addedRows < requiredPos",
the row for requiredPos is regarded as included in the window.
In that case, by "mCurrentRowID = Long.valueOf(getLong(mRowIdColumnIndex));" statment in AbstractCursor,
IllegalStateException is thrown.

This patch contains modification of the expression as "startPos + addedRows <= requiredPos".

Change-Id: Iaee75241e495949b0a624b836843da18d0bcb98d
Potential NPE in SQLiteConnection

Change-Id: I4d768bda5ea2fccb4a7c6ce7a5f074bf41563eac
Signed-off-by: Sylvain Becuwe <sylvain.becuwe@gmail.com>
Keep native callbacks when primary SQLiteConnection is recreated

When a database was ATTACHed/DETACHed to a database that had Write-Ahead
Logging enabled, the primary SQLConnection was recreated but the
registered native callbacks were not restored.

Change-Id: I8787fee78e68197ae472e05cc694d11381defa71
fix hover events consume issue

View#onHoverEvent() would always consume hover events over the view
if an application window has the clickable view/widget on it.
That's happened even if accessibility/talkback is disabled.
So those events will not dispatch to activity#onGenericMotionEvent().

The onHoverEvent method should return a real consumed state.

Change-Id: I9cac13b82866e5cdda0b03befb0de752a0a2e741
Fix PointerCoords Parcel incorrectly storing values as Int32

PointerCoords stores its values as float and its Parcel should
do the same. Wrong behaviour may be noticed when MotionEvent is
injected using Instrumentation method sendPointerSync. All its
PointerCoords values(size, orientation, pressure, etc) will be
casted to integer omitting their decimal part. This fix addresses
this issue.

Change-Id: Ifa3dfce4d5c2e6c060852f4208cb5684e827c7e6
Signed-off-by: Ilya Polenov <daioptych@gmail.com>
DateView: Use Intent.ACTION_LOCALE_CHANGED to refresh notification bar clock

Add the Intent.ACTION_LOCALE_CHANGED to DateView BroadcastReceiver for detect when the
user change the locale. Otherwise, the notification bar clock is not refreshed until
the next tick or time changed occurs.

Change-Id: Ic8830fbabf24b62b60a6d3babe5e211f14948d08
Handle hotplug events as described instead of rescanning

Hotplug events say which display they're for and whether the display
was connected or disconnected. Before, this info was ignored, and the
event just triggered a rescan of all displays. If a display was
disconnected and then reconnected quickly, the rescan would treat this
as a no-op or a device property change and wouldn't turn the display
on.

Now the display manager attempts to update its state with the change
the event describes. So a quick disconnect/connect cycle will cause
the display to be turned on since the display manager will have
updated its internal state to reflect the disconnect event, and will
treat the connect event as a new display rather than a device property
change.

Bug: 7491120
Change-Id: Ia83f7c96b7f16f4c1bed2a73e9b56b0bf7ee3984
Process all display events in order

Display events in each batch received from IPC were being processed in
reverse order, and stopped after the first vsync event (latest
chronologically) was handled. This makes perfect sense for vsync
events, but is broken for hotplug events.

Now we process them all in order, handling all except vsync as we see
them. For vsync events, only the last is reported.

Bug: 7491120
Change-Id: I448d139d21dc27128d75ca1d661de666fff51bcb