Keyguard: don't refresh ui when screen off

KeyguardStatusView is doing refresh all the time,
which cause high power when screen off.

Change-Id: Ifabdde4419a23e919cd52fe77e78ec3160575af1

Conflicts:
	packages/Keyguard/src/com/android/keyguard/KeyguardStatusView.java
StorageManager: only register MountService listener when needed

When other service get StorageManager, StorageManager will register a
listener in MountService, which won't be unregistered.

So change the policy to be:
1. when other service needs to register listener in StorageManager,
StorageManager will register listener in MountService.
2. When other service needs to unreg0ster listener in StorageManager,
if there is no more other listeners in StorageManager, StorageManager
will unregister listener in MountService

Change-Id: Ie59ad96279ac3b51f7a606fcfbbde0c130cf61dc
Author: Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: Bing Deng <bingx.deng@intel.com>
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 30943
Animate Recents on High-End devices

This adds back the translucent background and animations
on high-end devices with more than sufficient RAM, so that
it does not feel so weird when launching recents screen.

Change-Id: I32d6b359ed374126827af03ecf4854ab2b949920
Display: Dirty region propagation

Pass Dirty region values from HW renderer to Surface Texture.

Change-Id: Ibd121ed398a1319d3daf26f9fd39a03323bba666
WifiController: fix high perf lock sometimes not respected

When the device screen is turned off, the state is DeviceActive for
15 minutes. In this time, high perf lock is not respected and
Wi-Fi power-saving mode will be turned on because screen is off.

Fix by adding a new DeviceActiveHighPerfState.

Change-Id: I71074beec4d41286dea0861107d7931da205aca2
JIRA: CYAN-2860
Prevent nullPointerException by updateBondedBluetoothDevices

In some very rare cases difficult to identify, it seems that the
IBluetooth.getBondedDevices() returns a Set with a null element.

This patch will prevent calling getBondState() if the device is null to
avoid a nullPointerException.

Change-Id: I9bcad60c37e03c77ec39227e5c947c002a3ae2c7
Orig-Change-Id: I8845f0e6b8fdcda679bc71e2b5c33fd4a52f3ac5
Signed-off-by: Patrick Combes <patrick.combes@intel.com>
Reviewed-on: http://android.intel.com:8080/116592
Reviewed-by: Bondier, CedricX <cedricx.bondier@intel.com>
Reviewed-by: Chen, HuaqiangX <huaqiangx.chen@intel.com>
Reviewed-by: Yao, Yong <yong.yao@intel.com>
Reviewed-by: Aquilone, RaffaeleX <raffaelex.aquilone@intel.com>
Tested-by: Lestienne, ChristopheX <christophex.lestienne@intel.com>
Reviewed-by: buildbot <buildbot@intel.com>
Tested-by: buildbot <buildbot@intel.com>
Signed-off-by: Jian Luo <jian.luo@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 90085
Solve three memory leaks related to PatchCache

A Patch can be fairly large, holding bitmap data, but
is also frequently leaked which adds to the severity.
The feature is used in many important processes such
as Home, SystemUI and Chrome.

The following leaks are solved:

1. The Patch itself was not always freed.
PatchCache::removeDeferred() can mark patches to be
cared for by PatchCache::clearGarbage(). But
mCache.remove() would only destroy the container
and the pointer, not the Patch object itself.

2. The vertices stored in the Patch at Patch::createMesh()
would always leak. The empty/default destructor in Patch
would not properly destroy "vertices" since it's just a
pointer.

3. A BufferBlock that's added to the mFreeBlocks
in PatchCache could leak. The leak happened when a
patch later needed the entire free block, because the
object was removed from the list but never deleted
in PatchCache::setupMesh().

Change-Id: I41e60824479230b67426fc546d3dbff294c8891f