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
FIX Null Pointer Exception on dialog cancel

Null Pointer Exception occurs because mWebViewCore instance
is made to null while calling destroyJava(). When
1.webview hosting activity goest to background, without calling webview onPause().
2. If app is launched again (having launchmode:singletask ) and another activity (not  webview hosting) comes on top top.
3. It destorys the previous activity holding webview which internally tries to cancel the dialog, but webviewcore instance is null.
Null pointer exception is raised.

Change-Id: Idbcd30d0b0d4a35819444bbaa5c73cced8bb35a3
Signed-off-by: Amit Kumar <amitkecian@gmail.com>
Audio continue to played even if paused manually

Currently, audio will resume playing after a phone call
or notification even if the user had manually paused playback.

This patch addresses that by introducing a new player state
to distinguish the user pausing playback and the browser
losing audio focus for some other reason. Audio will only
 resume if the browser temporarily lost audio focus and
not when the user has manually paused playback.

Change-Id: I9e8beaedb0fcc5afe920068297ed9c387eab2ac8
Signed-off-by: Roger Chen <cxr514033970@gmail.com>
update preloaded-classes

Remove some preloaded-classes and fix typo for deleting log messages
as the followings during booting.

W/Zygote  (  163): Class not found for preloading: android.bluetooth.
BluetoothAudioGateway
W/Zygote  (  163): Class not found for preloading: android.bluetooth.
HeadsetBase
W/Zygote  (  163): Class not found for preloading: undroid.content.Ab
stractThreadedSyncAdapter$SyncThread

Change-Id: Id02e0cccaeb150f48e12d67b2d691df828842e4c
Revert "Add CPU boosting hooks"

This reverts commit a6722f31f91d3559353028777eedbe692ee9947e.

Revert "power: Add CPU boosting interface"

This reverts commit 0a8c0b61f69b3b41836228fa6cf81446f186069e.

Conflicts:
	core/java/android/os/IPowerManager.aidl
	services/java/com/android/server/power/PowerManagerService.java
	tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgePowerManager.java
Allow purging of asset bitmaps

It seems that neither CM9 nor CM10.x includes the actual framework-side
code to facilitate user-controllable bitmap purging. Odd, since the
CyanogenMod Settings app in both CM9/CM10.x includes the option.

Backported from original Gingerbread commit:
http://review.cyanogenmod.org/#/c/3908

Original description:

Allow the system to reclaim more free RAM when needed on 'low' memory devices
(e.g. Droid/Milestone) that are struggling with 2.3. This option enabled
efectively restores the froyo way of forcePurgeable BitmapFactory asset
handling.

Change-Id: I6a3b8a05b7be9c214a8548d6c6d1621e6533a1e0