bootanim: Don't cache textures if they're expected to use a lot of VRAM

bootanimation cached all the textures generated until the animation
was completed.
For Hi-res animations with lots of frames (like the new CM9 anim on
xhdpi devices), this implied using large amounts of video RAM, more
than most devices actually have available, causing the animation to
stall (and in some cases, gralloc to lock up); so if an animation is
expected to use a lot of RAM (rough estimation based on frame size
and number of frames), disable cache entirely and generate the textures
on demand

Change-Id: I157e5cdde2aab1d82d980d77cbedd9f127c83a1d
bootanimation: performance enhancements

This patch implements two simple performance enhancements, which
might benefit devices. They are completely opt-in by setting
the following variables.

  * TARGET_BOOTANIMATION_PRELOAD: will preload the bootanimation
    zip to memory; this is handy on devices where the storage
    might be slow. By preloading it, we get quick access to the
    zip file, and the animation doesn't stutter.

  * TARGET_BOOTANIMATION_TEXTURE_CACHE: allows maintainers to
    force texture cache on/off.

Also fixes the sign warnings related to int / size_t comparison

Change-Id: Ie92d1b0aa90b43ba39c368a2a33657a60c3a64b5
move weather images to framework-res

- decreases size of systemui
- allows for access throughout the system without
      duplication

Change-Id: I06e90d39d365587ee15bf1b566ec81b39f79d3b0
telephony: when building apn list, use preferred apn if it can handle requested type

GsmDataConnectionTracker::setupData() does not consult TelephonyProvider when it
picks an APN for mms. It just uses apnContext.getNextWaitingApn() which picks the
first one in the list. On AT&T it picks wap.cingular, which is wrong for LTE.

Since the data connection is made properly, setupData() stops scanning and never
tries the correct APN (pta). The result is sending of the mms just hangs.

This change causes GsmDataConnectionTracker::buildWaitingApns() to first try the
currently active APN if it can handle the type of APN being requested, then it
tried the preferred APN and then the rest of the APN's, in that order.

This fixes the MMS problem since the correct APN (pta) is chosen.

Change-Id: I076b88d42f59241cf468d678ad0e628d0f2d9e8d
Merge "telephony: when building apn list, use preferred apn if it can handle requested type" into ics
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
libmedia: build with AudioParameter if needed

Usage:
BOARD_USES_LIBMEDIA_WITH_AUDIOPARAMETER := true

Change-Id: I4d33afcf2af200f70120ee9b9ee03c8830712686
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
Aligning native Parcel implementation to Java.

The Java implementation of writing the RPC response header
calculates the length of the header including the 4 bytes
specifying the header length but the native implementation
excludes the 4 bytes specifying the length from the header
length.
The native implementation has been aligned to the Java impl.

Change-Id: I325bf272a63152d8fded4cf4e51a906b5a9bfe19
telephony: support for setting add. audioparams for incall audio

Change-Id: Ic6f72fba542e1421631826d9bcd86340064c942b
Merge remote branch 'aokp/ics' into ics