telephony: Smdk4210RIL: clean up processUnsolicited

Remove full overload of processUnsolicited and have it work with the
requests unknown by the RIL superclass. Pass everything else upwards,
unmodified.

Change-Id: I129120995c17b45c17dd50b77f281de352c20ae2
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
Updated Hebrew Translation

Change-Id: I34a6231613de8a52b646059c13f92d0124da8847
Fix translator's misreading.

Changed => Muutettu
Charged => Ladattu

Change-Id: Ifca9bdd55cc48b4481c5f05acaf59bf67fd3724c
fixed external BT gps date/time issue reported by Jason Lynch

Change-Id: Ibcd2ef50c536e99bce8f406525599987484f99cc
fix uri typo

Change-Id: I7ef9a98f5fcba4d156256e4a8cbc24d58df0c549
Hide the Automatic brightness button on tablets when there's no support

Change-Id: Ib715a4703af6d91e1496bbfa2fe1aa31c1a1cbba
libstagefright: Set session id to one for LPA playback

-ALSA HAL needs to differentiate between LPA and Tunnel mode
 playback for setting the correct routing path.
-The session id for LPA playback is set to one.

CRs-Fixed: 352002
(cherry picked from commit 5382f7f8feb609dfecae961641b0b5b0b6218371)

Change-Id: Id8b88ad838ce307b907444d4c5b9e25c3c3a19f3
libstagefright: Fix for seek before end of clip issue

- When the clip is seeked to just before the end of the clip,
  the control skips to next track instead of the remaining part
  of the clip being played.
- When the clip is seeked, in LPAPlayerALSA, fillBuffer() is
  called which sets mReachedEOS to true when the last buffer
  is reached. AwesomePlayer on the other hand calls
  onCheckAudioStatus() after seek complete which in turn
  checks if reachedEOS() returns true in LPAPlayerALSA and
  calls postStreamDoneEvent(). Currently, reachedEOS() returns
  mReachedEOS which is incorrect because there still are
  buffers to be written to the DSP.
- Before postAudioEOS() is called, mReachedOutputEOS is set to
  true and is returned by reachedEOS().

CRs-Fixed: 339602 359591
(cherry picked from commit fe2345716be459f38088df2af79b53b1acf71d36)

Change-Id: I1334c8b0ab1e1d6cc386cc770c73ddc50af25c2e
libstagefirght: Fix for data loss in A2DP playback with repeat mode

- Data loss is observed in A2DP at the starting of
  second playback with current song repeat mode
-When the file EOS reaches Awesomeplayer calls seek to zero and
 pause the LPAplayer till A2DP thread sent all the data to A2DP.
 Since decoderThread not aware that LPAPlayer in pause state it
 keeps on calling fill buffer.But A2DPThread will be blocked till
 LPAplayer resumes from pause.So buffers which fillbuffer returned
 in pause state are not sent to A2DP and these buffer will be
 over written.
-Added the condition to avoid fillbuffer in decoderThread when
 the LPAplayer is in pause state.

CRs-fixed: 351079
(cherry picked from commit b2ecd5f5b39e3fbee3f73f533897b0d14624244a)

Change-Id: Ib424a5f5794f91df4cad4fbbd7ab27faffcc4ba2
libstagefirght: Fix for music skip in LPA A2DP case

-Portion of music repeating twice after disconnecting and
 connecting A2DP
-When A2DP disconnects, timeplayed will be updated with the data
 sent to A2DP. But Decoder thread already has some decoded data
 which is not sent to A2DP.Here if A2DP connects back decoder
 thread calls fillbuffer with the  time played position.
 Because of this fillbuffer getting some of the decoded data
 which is already decoded earlier.
-To address this issue when the A2DP disconnect and connect happens
 clearing all the buffer which are there in response queue.

CRs-Fixed: 356571
(cherry picked from commit b52619bdc157646278fce30ceb84057370f030c1)

Conflicts:

	media/libstagefright/LPAPlayer.cpp

Change-Id: I98578d4470021757625ad1203682da4bb45cd055
frameworks/base: Fix for LPA volume sequence reversal

- LPA volume is sometimes reversed while doing volume Up&DOwn.
- Two different threads are trying to set volume, one by invoking
  setSessionVolume() and other by invoking setStreamVolume().
  But currently only setStreamVolume() is mutex protected. This
  is leading to race condition and volume set second is getting
  applied first.
- Fix is to acquire mutex in setSessionVolume() before setting
  volume.

CRs-Fixed: 360973
Change-Id: I02ac979bf83c4f3589deb5c83ae816179735aa2b
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
Fix off-by-one error when filtering application UIDs

A filtering check in writeLPr() mistakenly includes the first application UID
(10000) with the result that the package with UID 10000 is missing from
packages.list. This patch fix the error.

Change-Id: I3651beb346290db8e09317391b95a77aed1946b6
Signed-off-by: Magnus Eriksson <eriksson.mag@gmail.com>
Prevent empty overflow popup when there are no overflow items.

On a device with a hardware menu key, an empty overflow window can be displayed
if there are no items in said overflow menu. This leads to the next user touch
being swallowed in the action of dismissing the invisible window.

Change-Id: I9191e4b2e1ed4888e4bc7261e8b3f095a272a9b5
Issue: Foreground activity performs [Resume] and [Pause] when any process died in sleep mode.

Step to Reproduce
1)	Turn off device’s screen. (Sleep mode)
2)	Kill any process.
A.	Engineer Version: kill [PID]
B.	User Version: am force-stop [Package Name]
3)	Foreground activity proceed [Resume] and [Pause] consecutively.

Reason: Since ICS version, activity goes to stopped status when screen turns off.
stopIfSleepingLocked( ) makes activity to stopped status but, pauseIfSleepingLocked( ) was used in GB
and, activity keep paused status and, this problem did not occur.
This change give effect to resuming activity when any process was killed.
Because, resume is proceed without exception for activity status.
The exception only filtered for [ActivityState.PAUSED] in sleep or shutdown mode.
and, resume complete flow when activity status was [ActivityState.STOPPED].

Solution for this issue:
We think that exception’s condition have to change if stopped activity status is intended in sleep mode.
According to activity life cycle, activity can not resume from stop status.

Also check [ActivityState.STOPPING]. :)

Change-Id: Icca3366ac30ffa3b18f6e2393e4d7309089ef26a
Fix for too many binder calls in packagemanager

The packagemanager uses a ParceledListSlice to send back its lists
of installed packages and apps. The list slice has a method append
which, in addition to adding the item to the list, also returns true
if the list has passed a size limit (about 1/4 of the total possible
IPC parcel size) to let the caller know that he should send the
slice. However, when used by the pm, it has an extra ! that makes it
send whenever it ISN'T over this limit instead (and conversely, not
send if it is under). This causes a lot more calls than needed since
it sends tiny one item slices instead of larger ones. This patch
removes the extra ! making it behave correctly.

Change-Id: I8db46d380a25406b55f3214aee1505e81949acc5
Distance max set incorrectly

The distance max used in the MotionRange is calculated
incorrectly.

Looks like a copy-and-paste error.

Change-Id: I2b6daab088df0fb69e05682b67ca33524ff35987
Fix potential NPE when saving fragment state.

If a fragment's saved view state is null and the user
visible hint is true then the `result` bundle will have
never been initialized to a value resulting in a
`NullPointerException`.

Mirrors support library change I8ba585bc6b9298841490d64bc22a8219cd261adb.

Change-Id: Iabd5ac293d2ece3771da9ef257479eca0dcd523c
Do not dispatch context selection events to non-visible fragments.

When used in a `ViewPager`, fragments that are present on the adjacent,
cached pages will receive context selection dispatches which, depending
on your fragment contents, can be difficult to determine whether or not
the event truly originated from your view.

By using the visible hint we restrict dispatching to only those fragments
which are marked as being visible. Since the fragment pager adapter
updates this setting properly most implementations will be afforded this
fix without any change required. If the user is implementing their own
adapter they likely already understand the implications of these cached
fragments and the reponsibility for updating the boolean falls to them.

Mirrors support library change Ie6a72c1c82c2784774373670007b6f5948fe16da

Change-Id: I1bc6f74e26660ef4a3c20419c077e37992412e94