Fix layout of MultiWaveView and GlowPadView.

If the calculated size of the rings is much smaller than the measured
size (which is happening e.g. on mdpi 600x1024 tablets), the glow pad
appeared shifted to the right.
This happened due to the insets being calculated as difference of
available and needed size, and later on being added to the available
size. Example numbers (Nexus 4 with density forced to 160):
- computed size in onMeasure: 768x505
- scaled size in onMeasure: 505x505
- thus, insets are calculated as 131/0
- in onLayout, placementWidth (364) and max target width (108) are much
  smaller than width (768)
- thus, center is calculated as 131 + (768 / 2) = 515, thus shifted to
  the right

Fix that by not using width in the calculation, as the inset size
already takes it into consideration.

JIRA:CYAN-829
Change-Id: Ifc2a93214f812f554a8fed3243eed66aec9f00c9
Remove opaque check in GLRenderer when preparing dirty region.

Since preserved swap is enabled, we need to clear the color buffer
when the scissor rect is prepared for a new process. This prevents
garbage to be present from the previous process in the color buffer.

CRs-Fixed: 391492, 403067, 405916

Change-Id: I1f72a3dee2f5d58a984f4cd367c9f7bf08ab9d6a

Conflicts:

	libs/hwui/OpenGLRenderer.cpp

[PATCH] Remove opaque check in preparing dirty region

Since preserved swap is enabled, we need to clear the color buffer
when the scissor rect is prepared for a new rocess. This prevents
garbage to be present from the previous process in the color buffer.

(cherry picked from commit 2b5e584e2615852b68a69bb529c6926190246b64)

Change-Id: I92a4fa35e0746f12fcd736e21fd30d9c4b644a8a
CRs-Fixed: 391492, 403067, 405916

Conflicts:

	libs/hwui/OpenGLRenderer.cpp

Enable scissor when preparing dirty rect that is opaque

Now enabling scissor before setting it in the opaque case, previously was not doing so.

Change-Id: I1ea904cf01603096e423556090564291ab712d36
CRs-Fixed: 465346
Depends-on: 278453

Remove opaque check in preparing dirty region

Since preserve swap is enabled, we need to clear the color buffer
when the scissor rect is prepared for a new process. This prevents
garbage being present from the previous process in the color buffer.

CRs-Fixed: 465346
Change-Id: I98f2009748244751c4b56af8afbdfeb645c13230
Frameworks : FR translation

Patch set 2 : correction
Patch set 3 : correction => %%
Patch set 4 : correction

Change-Id: I9a5a3f38bc31c88ff71bb0ec62a4fea4a6fc1cbb
Merge "Frameworks : FR translation" into cm-10.1
Merge "Remove opaque check in GLRenderer when preparing dirty region." into cm-10.1
Merge "Fix layout of MultiWaveView and GlowPadView." into cm-10.1
merge changes from remotes/github/cm-10.1 into master
Frameworks & SystemUI - additional DC-HSPAP support

This commit adds some more informations about Dual-Carrier HSPAP
It allows displaying a "DC" icon on status bar for compatible devices
and add a "DCHSPAP" value in state phone
patch 1: add TelephonyManager to fix build
patch 2: modify ServiceState
patch 3: switch to cm_strings
patch 4: fix a mistake
patch 5: upload a new set of icons, a bit prettier than previous
patch 6: update icons (more opacity to match colors)
patch 7: removed drawable-sw*

here is a screenshot for example: http://imgur.com/mQ2du3l,PSyHoqC

Change-Id: I77d05e23c8ad3efdfeb19cf06ed92e7c57105ebe
TelephonyManager: hide NETWORK_TYPE_DCHSPAP

Change-Id: I77e6d537d5ebbe67bac26c6ef6d0dda498640ca0
merge changes from remotes/github/cm-10.1 into master
Pie controls: Tweaking UX for pie service (1/2)

With the introduction of pie service there is the need to
fine tune the parameters for activation again.

Patch Set #2:
* Base trigger thickness set to 10dp
* User settable activation sensitivity

Patch Set #4:
* Reverted #setSensitivity() in PieGestureTracker
* Added Sensitivity "Very High"

Change-Id: Ief7c1786467195f2ad52dcdb0efd3ad03a48834c
User defined colours for pie controls (1/2)

Although CyanogenMod's colour scheme is normally fixed and only
changed by themes, this commit allows the user to change some of
the colours of the pie.

The rationale behind this is as follows:
Normally UI controls both - foreground and background colour of
each UI element. In case of the pie controls this is not possible,
pie controls are possibly overlayed in all screens of the UI and
all custom installed applications. This makes it hard to come up
with a universal colour scheme for pie controls.
In other words the user perceived "average" background
colour *) varies from user to user and thus universal colours
for pie controls are hard to pick.

*) It showed, that the background of the home
screen is major factor to this. Due to the fact that the
background is user settable, the colour range here is almost
infinte.

This commit adds:
* A user can change the following colours from within the Settings
  application:
  Normal button background, Selected button background,
  Long pressed button background, Icon colour
* Each colour can be reseted to the system default colour.

There is a seperate commit for the Settings application.

Change-Id: I34975b02999303d4ee479918d6e22a95e940a6ef

Conflicts:
	core/java/android/provider/Settings.java
	packages/SystemUI/src/com/android/systemui/statusbar/policy/PieController.java