Force the screen-on after phone calls, ignore proximity sensor

Proximity workaround for device specific settings, this is required
on phone with a case hiding the proximity sensor, or buggy sensors.

From Quarx2k <agent00791@gmail.com> (gingerbread)

Change-Id: I5b6174d5f19ef601dd503b4dadafb3defbf2bb00
Add NT_MODE's for NETWORK_MODE's 8 and 10

as defined in RILConstants.java

The RIL in newer motorola phones is set to 10 as default.
Signed-off-by: dhacker29 <davidhackerdvm@gmail.com>

Change-Id: Ic80a9d984be40a5f921204e8997943b44c52d421
Frameworks: tablet powerwidget management (1/2)

Settings: http://review.cyanogenmod.com/#/c/16842/

Adds basic powerwidget management for tablet devices
Allows to setup up to 6 different toggles, or remove all of them

patchset 2: remove whitespaces and tabs
patchset 3: remove some other tabs left
patchset 4: some other tabs were hidden
patchset 5: *changed strings for consistency with phone powerwidget
            *added license header on some files
patchset 6: remove WIP tag

Change-Id: I2e643401aaac0146857abe8c2d2dbc652d28e666
Lockscreen weather German translation

Patch set 1 - Add strings introduced with http://review.cyanogenmod.com/#/c/16982/1
Patch set 2 - Append \u2026

Change-Id: Ia78748a3c03b26bbedd4e40c9ec690b98170cf84
Update Russian Translation-Weather-No data-CM9
telephony: support for setting add. audioparams for incall audio

Change-Id: Ic6f72fba542e1421631826d9bcd86340064c942b
Previous fix was incorrect.
Timestamp doesn't contain date info, therefore we need to construct it
and adjust it if daylight savings applies.

Change-Id: I931ff0f2ba93ab8172f2cbc69926aba1eab2778a
Input: Fix some Applications ANR issue in monkey test

Issue Description:
When do monkey test on some applications, there is big probability get ANR issue. one example is as following:
    adb shell monkey -p com.google.android.street -v 500000

Root Cause:
situation 1. InputDispatcher Thread calls findTouchedWindowTargetsLocked routine, there is a AMOTION_EVENT_ACTION_DOWN event
             and it can find a splittable touched window for this event , then mTouchState.split set to true.

situation 2. WMS Thread calls setInputWindows routine and all TouchedWindows associated with mTouchState are removed ,
             mTouchState.split status still keep true.

situation 3. InputDispatcher Thread calls findTouchedWindowTargetsLocked routine, there is a AMOTION_EVENT_ACTION_POINTER_DOWN event
             and it can find found touched window, exit window loop in following code :
                  if (windowInfo->visible) {
                    if (! (flags & InputWindowInfo::FLAG_NOT_TOUCHABLE)) {
                        isTouchModal = (flags & (InputWindowInfo::FLAG_NOT_FOCUSABLE
                                | InputWindowInfo::FLAG_NOT_TOUCH_MODAL)) == 0;
                        if (isTouchModal || windowInfo->touchableRegionContainsPoint(x, y)) {
                            if (! screenWasOff
                                    || (flags & InputWindowInfo::FLAG_TOUCHABLE_WHEN_WAKING)) {
                                newTouchedWindowHandle = windowHandle;
                            }
                            break; // found touched window, exit window loop
                        }
                    }

situation 4. The following code will have problem after situation 3 in below conditions:
             newTouchedWindowHandle doesn't support split , isSplit is true ( last time touched window is splittable )
             mTempTouchState.getFirstForegroundWindowHandle will always return NULL due to situation 2

            // Figure out whether splitting will be allowed for this window.
            if (newTouchedWindowHandle != NULL
                    && newTouchedWindowHandle->getInfo()->supportsSplitTouch()) {
                // New window supports splitting.
                isSplit = true;
            } else if (isSplit) {
                // New window does not support splitting but we have already split events.
                // Assign the pointer to the first foreground window we find.
                // (May be NULL which is why we put this code block before the next check.)
                newTouchedWindowHandle = mTempTouchState.getFirstForegroundWindowHandle();
            }

            The window says it does not want to support splitting, so the touches should go to one of the previously split windows except
            that there are none, which result to "goto Unresponsive" in findtouchedWindowTargetsLocked routine.
            This is not the correct behavior because the user did actually touch something.

situation 5. InputDispatcher Thread will call dispatchOnce repeated to try to dispatch this AMOTION_EVENT_ACTION_POINTER_DOWN event,
             then ANR timeout ( 5000ms ) will be exceeded after several times "goto Unresponsive"in findtouchedWindowTargetsLocked routine.

Solution:
In situation 4 we should drop the touch. If the newly touched window was splittable then we wouldn't drop the touch.
It's only when the newly touched window was not splittable where we will drop the touch.

Change-Id: Iab2c06ce0597ac77eb886ccd9d84646c86723bdb
Author: Jeffrey Brown <jeffbrown@android.com>
Author: Erjun Ding <erjunx.ding@intel.com>
Author: Zhenghua Wang <zhenghua.wang@intel.com>
Author: Jack Ren <jack.ren@intel.com>
Author: Bruce Beare <bruce.j.beare@intel.com>

Conflicts:

	services/input/InputDispatcher.cpp