Fix build after battery merge
Rework thumbnail handling

Since ids of media file are usually not continuous, the original file of thumbnail are
sparse. When there are big numbers files on ex\
ternal storage, the size of this file will be horrible.
Ex, when the id is 20000, then the .thumbnails/.thumbdata3-xx file will be 50000*10k = 488.28M.
Can refer http://stackoverflow.com/questions/12396715/android-huge-thumbdata4-file-in-dcim-folder
Because after 4.0, MediaProvider will scan any files, this will be a big problem. So I modify MiniThumbFile.java to avoid this.
According to the id, we now produce an index file. In this index file, one id will use BYTES_PER_MINTHUMB_INDEX(8) bytes in offset (i\
d+1)*BYTES_PER_MINTHUMB_INDEX. The data of these 8 bytes is the index of thumbnail file. The first BYTES_PER_MINTHUMB_INDEX bytes kee\
p next available index. And when you need insert a thumbnail, the index increase by 1. In this way, the block data in thumbnail file \
will be continuous. And thus unnecessary zero paddings will not be saved.

Change-Id: I66005dd69b0a5c8f4353bd7a8225d163a654fd2d
frameworks: squash of leak & race fixes

commit 5c837244a550308a6b8fadf95275d50f6bf3b202
Author: Daniel 2 Olofsson <daniel2.olofsson@sonymobile.com>
Date:   Mon Jun 10 14:49:14 2013 +0200

    Fixed race condition in Spinner.DialogPopup on null reference.

    NullPointerException is triggered when DialogPopup is
    dismissed due to object mPopup being null when not showing.
    Race condition is triggered when dialog is dismissed before
    touch event to dismiss dialog has been processed properly.

    Fixed by adding a null check prior to accessing mPopup object.

    Change-Id: I3c4fe9c279d92a7103fb4f68189d1d42beedc606

commit 4950d85c29bed35c0874858d094d5a0f628f1e54
Author: Pawel Augustyn <pawel.augustyn@sonymobile.com>
Date:   Mon Jul 16 11:23:54 2012 +0200

    Fix for native leaks in YuvToJpegEncoder.cpp

    Objects allocated by Get<object>ArrayElements function,
    should be released. Add a fix to release this objects
    in error cases.

    Change-Id: Idf834523d93bb2dfd6b872e3b2179b7f1bba38f3

commit 463ac945502552ab0c06ae00c987d3c400161fe3
Author: Michal Szynkaruk <michal.szynkaruk@sonymobile.com>
Date:   Wed Jun 26 11:28:36 2013 +0200

    Fix for MemoryLeak in InputMethodService

    Problem: when onConfigrationChanged is called many times,
    mInsetsComputer is added many times to the list.
    Solution: check before if specific listener is already
    in the arraylist.

    Change-Id: Ic730395120d6dc8585628c142b2e161c42317f30

commit 5167ab57b2a1dbee38a5303e4b490a04b9dff950
Author: Pavan Kumar S <pavan.kumar.s@intel.com>
Date:   Fri Aug 3 12:03:01 2012 +0530

    [BatteryStatsImpl] Avoid memory corruption due to Parcel Recycling

    While processing batterystatsfile, in present code there is a race where a parcel
    might be recycled while it is being written to disk in another thread.

    The write process is done in 2 steps:
    - write into a Parcel (memory block)
    - then write this Parcel to disk using Journaled API.
    The Journaled API ensures robustness against file-system issues due to power cut.
    The writing is done in batch using a thread running commitPendingDataToDisk().
    This function writes the parcel to disk but this parcel is a global variable
    initialized by writeLocked(). If the writing takes too long time and two write
    threads are launched, the parcel is freed by the second writeLocked() call;
    which could cause the memory corruption.

    Hence, change global Parcel variable by a Parcel parameter to commitPendingDataToDisk()
    and only this function will be allowed to recycle the parcel.

    Change-Id: Ie86ee0a66434b7107264c79f68411196c7505a34
    Signed-off-by: Pavan Kumar S <pavan.kumar.s@intel.com>
    Author: Pavan Kumar S <pavan.kumar.s@intel.com>
    Signed-off-by: Shuo Gao <shuo.gao@intel.com>
    Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
    Signed-off-by: Jack Ren <jack.ren@intel.com>
    Author-tracking-BZ: 47466 19426

commit ab625310c19573caf5cdcf4c6ef573bbfbc8a26b
Author: Vairavan Srinivasan <vairav@codeaurora.org>
Date:   Mon Jun 6 13:42:54 2011 -0700

    frameworks/base: Fix for the race in Wallpaperservice

    Wallpaperservice has a race among message handler of
    DO_DETACH and service's onDestroy. In certain cases,
    the engine kept track in mActiveEngines is removed by
    message handler of DO_DETACH and service's onDestroy
    doesn't get a entry in mActivieEngines and isn't able
    to invoke detach. This keeps the broadcast receiver,
    mReceiver active and is unregistered by the framework
    and a corresponding leak is reported.

      Later, the message handler of DO_DETACH continues
    and invokes detach on mEngine, which attempts to
    unregister mReceiver and framework throws an exception
    "Receiver not registered: android.service.wallpaper.
    WallpaperService$Engine$1@40874580" and causes the
    framework to reboot.

      In case of system_server, WindownManagerPolicy and
    android.server.ServerThread contest for access of
    shared members, mActiveEngines and mEgine. Fix is to
    protect the critical section via synchronized block.

    Change-Id: Ice79cb8344fb54bcc6e9f76f4b143daac2608d7b

    Conflicts:
    	core/java/android/service/wallpaper/WallpaperService.java

Change-Id: Ib24d04673c5fff21533f7f00456df658cdbc6288