Don't let apps disable the SIM PIN entry screen.

As the user (who controls the app behaviour after all) likely doesn't
see the PIN screen as a lock screen (he likely wants telephony) and the
PIN screen is not shown on a timer-driven basis, it should be treated
specially.

Change-Id: I8d48ab5f097bc926f67eab5835d9b5f1e581db15
Send out USER_PRESENT broadcast on screen on if lockscreen is disabled.

This makes sure to turn off the notification LED on screen on when the
lockscreen is disabled by lockscreen toggle tile.

Change-Id: Ibf2fdcd912a2719d973a253aaf3752add7a22e00
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
Avoid AsyncTask ThreadPool leak in RecentTaskLoaser

In MTBF test, if “Press KEYCODE_HOME” is simulated quickly and frequently,
ThreadPool overflow would be triggered, which would crash systemui.

When pressing hardware KEYCODE_HOME on the phone repeatedly, upon key down,
systemui will preload recent task list; upon key up, it will cancel the
request for preloading. During preloading, two AsyncTasks (mTaskLoader
and mThumbnailLoader) will be started. Both of them will use
executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR) to run.

Cancel predloading means we don't need mTaskLoader and mThumbnailLoader
any more, so we'd better use cancel(true) to interrupt these two AsyncTasks
and catch this InterruptedException to return directly.

If we use cancel(false) it won't interrupt these two AsyncTasks and
mThumbnailLoader may be blocked in blocking queue "tasksWaitingForThumbnails"
whcih will cause ThreadPool overflow.
There is situation that mThumbnailLoader’s thread runs before mTaskLoader’s.
Just at this moment, cancelPreloadingRecentTasksList tries to cancel
both mTaskLoader and mThumbnailLoader. Then mTaskLoader was cancelled
directly as it didn't start, mThumbnailLoader could not stop and blocks
on "tasksWaitingForThumbnails" forever. At last, many AsyncTasks for
mThumbnailLoader are not cancelled but left in waited state.

Change-Id: I62bef320a62f28a442117f7d2c8160ea49e1a1fe
Signed-off-by: jshe32X<jianchunx.shen@intel.com>
Signed-off-by: Guobin Zhang<guobin.zhang@intel.com>
[1/2] Base: DownloadManager: add support pause/resume/stop notifications

Add pause, resume and stop functions to make user can pause, resume and stop downloads by manual in downloads application.

Change-Id: I82ffff5a539448faab8933e2b47591199bf24cb9