fb: actually fix LTE toggle (1/2)

I accidentally pushed the LTE toggle patch although it was not ready.
Whatever here the fix for it. This commit does:

- do not assume that on boot ITelephony service is already up. This
  results in a FC on boot up
- handle like before most things in LTETile itself and call only
  the toggle action to prevend above mentioned
- I thought about it to give as parameter current network state
  to the toggle method to prevend to fetch 2 times the actual mode
  (saves 4 lines of code). But based on the idea that we maybe later
  use other shortcuts as well we will not do it.
- cleanup & codestyle

Sorry again

cheers

kufi

Change-Id: I33a694358cc47973c4a75dccae15ccc7062fdc22
Merge "fb: actually fix LTE toggle (1/2)" into kk
core: fix arithmetic on a pointer to void

Use char* instead of void* for this
pointer arithmetic. Fixes the following:

error: arithmetic on a pointer to void
buf = buf + offset;
      ~~~ ^

Change-Id: I6cfc92c9240fda66a52e780cda7820fdba76914a
fb: notification transparency (1/2)

this add back notification transparency...compared to 4.3
it controlls as well the notification icon backgound transparency
which felt in the past dissplaced. As well codecleanup of the old
implementation.

largeIcon support I did not add due that google does not support it
as well at current status...it is only a placeholder in
NotificationData

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java

Change-Id: Ic5bb8998f64cac573d70005fad909104accc9e96
Camera Key description

Change-Id: Ic9a22448c16428fc2f311ea813aa2ec5f27493db
Missing break in switch statement

Change-Id: I462c0c5fec96a850032266b04419ec409ad02174
LockScreen: allow long-press actions from hardware keys (1/2)

Allow following actions with button long-presses on lockscreen:
- toggle flashlight (if available)
- play/pause/next/previous track selection
- toggle silent mode

Allow customizing of back, menu, and home buttons. Search
button events are completely ignored on the lockscreen.

Auto-detect hardware keys, only show appropriate menu
options based on the actual hardware keys available on the
device (or completely hide if there are no hardware keys).

Based largely on Danny Baumann's work from gingerbread.

Ported from CM10
Change-Id: Iff32736d00ca5d4122f64a6a861bbb0a1de9cca9

Fix home/menu unlock with long press hardware key
- Forward port of commit 2a572ee
Change-Id: Ic2eb85542f8052fe1662244fe5e72ba12a98608b

Keyguard: Fix for home wake/unlock
sometimes device is waking and unlocking during the same keypress.
Change-Id: I72ea7611d39aac0cd03dfd5aa7036aeef7600140

Use sticky broadcast to convey torch state (1/2).
It doesn't really make sense to store the (non-persistent) state of the
torch in a (persistent) setting. As the torch is sending a broadcast
anyway, make that broadcast sticky and use it to convey the state.

Also unify the torch constants (actions, extras, activity names) at a
common place.
Change-Id: If845bef27cc79990794aa748dce18cfea3bac1f5

Fix Home/Menu/Back keys' unlock
Change-Id: Ibd3842b6ad8e037a2a9f8eb581e7c55900017b0f

LockScreen: allow hardware key longpress to put device to sleep
Change-Id: I54260e21c462bcabd9b6383e22f44d644630b4d3
Camera button support (1/2)

Add new bitmask for Camera button and "hasCamera" boolean.
For those devices that have dedicated Camera key
(like Sony ZL/ZR/Z1/...)
Change-Id: I1a6681664f9f3fd3f30221ba10b082cb5f8cafca

Camera button support: make it actually work
Previous commits were merged so fast that I didn't even
added the code that actually DOES launch the camera.
Let me fix that.
Change-Id: I4fcb3c46e5fd50e273dcf19fd3eb35a3f9d979e0

Camera button support: useful features & bugfixes (1/2)
Screw the remapping, let's make something more useful!
Replaced the code to actually launch Camera app, not just fire the shutter.
I won't remove it: it's cool to have an option to double-click Home for Camera.
Added:
  * Camera wake (with button half-press) and unlock options
  * "Peek": releasing the half-pressed Camera button will
    turn the screen back off
  * Camera playback control

Change-Id: Id49e09e20d81cd80d9800ab8ab0f200d44485a09
Remove 'Allow custom buttons' checkbox (1/2)

Let hardware buttons be rebound by default.

Change-Id: Ib4fcae7d93dc63d53490442d7ff44678583b0d9c
Framework: Add option to always show battery status on lockscreen (1/2)

Based on the feature by burnsra in CM7
Authored by Blunden
Tweaked by DvTonder
Change-Id: I642da4dcd82a776a74d77031d37acc76f97b25af

lockscreen battery status: add off option (2/2)
Change-Id: Ie10015865f161e783dc394d467e456d51dc9fbbc
Merge "core: fix arithmetic on a pointer to void" into kk
Merge "Camera Key description" into kk
Merge "Missing break in switch statement" into kk
Merge "LockScreen: allow long-press actions from hardware keys (1/2)" into kk
Merge "Camera button support (1/2)" into kk
Merge "Remove 'Allow custom buttons' checkbox (1/2)" into kk
Merge "Framework: Add option to always show battery status on lockscreen (1/2)" into kk
XmlUtils#readThisMapXml should handle null keys.

Both readThisValueXml & writeThisValueXml have been
implemented to handle values with "null" names.

Change readThisMapXml to allow such names as well, and
map them to the null key in the resulting HashMap.
readThisListXml and readThisSetXml already support
null names.

bug: https://code.google.com/p/android/issues/detail?id=63463

Change-Id: I1c93976656e45e7733113eb67d29b6bad5d25f1f
Fix appwidgets not updating

Previously there was a bug where if an appwidget's update caused a
TransactionTooLargeException then the AppWidgetServiceImpl.Host's
callbacks were completely disabled, for all widgets.

The fix still allows a DeadObjectException or other RemoteException
to disable the host callbacks, as that would be caused by a bad host.

Fixes issue 28216 on the public tracker
https://code.google.com/p/android/issues/detail?id=28216

Change-Id: I5c5d5939d7211ed23cca69e6674de730b51b0f3e
Signed-off-by: Kevin Barry <kevin@teslacoilsw.com>
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