Parallel shutdown

Decrease shutdown time by doing some shutdown tasks in parallel.

There are two threads executing during the shut down: the ShutdownThread
and a separate thread for the radio shutdown. However, the execution is
done in serial, as the ShutdownThread immediately joins on the radio
thread.

This commit will move the shutdown of the radio to the beginning of
shutdown and execute it in parallel to the shutdown of the rest of the
system.

The flow of the two threads during shutdown is now:

Radio Thread
  * Start shutdown of the radio
  * Wait for radio off or time out
  * Notify that the radio is done
ShutdownThread
  * Broadcast ACTION_SHUTDOWN as a parallel broadcast. (The receivers
    will get as much time to handle onReceive as it takes execute the
    rest of the tasks in the shut down flow. If they are not done in
    that time, we don't care.)
  * Shutdown ActivityManager
  * Shutdown MountService
  * Wait for MountService and radio to notify done
  * Vibrate
  * Low level shutdown

Change-Id: Ifdd8a9c75337fd9d00148a0d2b9917e10fa60634
(cherry picked from commit 4c07102a531edab0abfaebf1ff1be19a95ffe615)
fix WRITE_SETTINGS to be "dangerous"

(see http://www.fireeye.com/blog/technical/2014/04/occupy_your_icons_silently_on_android.html for an explanation why this is dangerous)

Change-Id: I8f938dc4f528aa2ccbca3d4cec235feb0299c0bd
(cherry picked from commit 81b33e3b580f005849773b74b63dfdb3fc503610)
Fix setSurfaceTexture to handle surface caching

Changed the TextureView.setSurfaceTexture to apply the
existing listener to the surface provided in the method.
This is done to allow surface caching to work.
Whenever a new SurfaceTexture gets created, its listener is
created as well, so when the setSurfaceTexture is called
we should be attaching the listener to the new surface.

Change-Id: I4c1a704c587e977ab7a6b1fe3a7d3e0d20d00218
CRs-Fixed: 639136
(cherry picked from commit b54a0af965947445c122f3acf085286e0e9d3daa)
Fix very long app_name crash.

http://ibrahimbalic.com/2014/android-os-memory-corruption-bug/ found an stack overflow bug.
The very long app_name make libandroid_runtime allocate a very large array on stack, the stack may overflow to other data areas in this situation.
This patch allocate large array on heap instead of on stack to avoid segment fault when doing memcpy.

Change-Id: I99999569b852d43a9c7a6eb1fa80e9f1a1f4e2b2
(cherry picked from commit d682ddf244653a9107f6fe6a4f228d9e136925ab)