FileInputStream is not closed in "UserManager.java : readUserList()"

Change-Id: I50f54c70c8b6bc808fa59ce589b0480780cc811b
Wipe the user data out in any case.

When the external storage is not mounted, the android system won't
wipe out the user data (i.e. "/data") if wipeData() is called with
the flag WIPE_EXTERNAL_STORAGE.

We think that the user data should be wiped out in any options and
also wipeData(int) method currently supports also for a external
storage. So we will also change the API reference comment.

If we should care about backward compatibility of this method behavior
with the option WIPE_EXTERNAL_STORAGE, then we would add an another
bitmask something like a ALWAYS_RESET.

Change-Id: Id7bf673c722bacc0480d32e46553b9a348513879
stagefright aacenc: Fix reading out of bounds in pow2_xy

This fixes cases where x was a large number, causing fPart to
exceed the 32 bit signed integer range (while fitting in an
unsigned 32 bit integer), making the table index a negative
number.

Change-Id: I674047db65f89148a93d218c138b42cd8305f80e
Lid switch state is incorrect

InputManager#getSwitchState() returns AKEY_STATE_UP(0=OPEN)
and AKEY_STATE_DOWN(1=CLOSE).
mLidOpen is opposite from a real lid status.

Change-Id: I40aa4e0defb95d82b6144ff6b7514f721bf9030f
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>