Fixed cancel() not working correctly

The method handleMessage(Message msg) from mHandler variable was
not checking if the timer was cancelled, so
sendMessageDelayed(obtainMessage(MSG), delay) was keeping the
timer alive. The patch simply adds a boolean and checks if the
CountDownTimer was cancelled before calling
sendMessageDelayed(obtainMessage(MSG), delay)

bug: https://code.google.com/p/android/issues/detail?id=58668

Change-Id: Ic6bbb9d33a3616f8503db222513cc14ad2270cb8
Signed-off-by: jl1990 <jlcarrasco1990@gmail.com>
Release locked buffer when it fails to acquire graphics buffer

The JNI buffer in ImageReader_imageSetup is not released when
it fails to acquire graphics buffer. After all JNI buffers are
exhausted, ACQUIRE_MAX_IMAGES will be returned and leads to
error. The JNI buffer should be released when it fails to acquire
graphics buffer.

Change-Id: I3319a58ac44e36c8593b404672a685c4b589a735
[ActivityManager]: Fix the activity visibility state not sync between ActivityManager and WindowManager

Symptom:
When press Home key to home screen, user is able to see the activity's window shown on top of wallpaper and below launcher(widgets).

Root Cause:
The ensureActivitiesVisibleLocked() is called pretty often (for example when a new process bound).
If the top activity "B" was finishing, then the previous activity "A" should be visible.
Therefore, the activity "A" window will be set to visible and then launched activity "A", but it does not updates the visible state in ActivityRecord for "A".
There has a timing issue that if a new activity "C" is started, "C" becomes the new top activity and be resumed.
In that case, Activity "A" window will remain visible even if it is behind a full screen activity "C" because the ActivityRecord.visble of "A" is still false, so the window visibility won't be update.
So when user press home key and back to launcher, the surface of activity "A" will be composed on top of wallpaper.

Solution:
Updates ActivityRecord.visible to true for "A". After "C" is started, the "A" will be called WindowManagerService.setAppVisibility() to set invisible, then called onStop() when execute ensureActivitiesVisibleLocked() again.

Change-Id: I536ba04b95d8d274fea6d679a6493e620bc981e2
Telephony: Modify code to check that PUK code length is always 8.

As per 3GPP TS 31.101 Release 11 section 9.6, the number of digits
for UNBLOCK PIN (PUK) is always 8.

Change-Id: I4ea69fd8e2e8e96330d10a67b2d1f5a1859c1016
GlobalActions: Set the initial status of airplane mode toggle

Actually, the initial status of airplane mode toggle is set to false
when the power menu dialog is initialized.
This causes an issue if you set airplane mode and then reboot.
After the reboot, the dialog displays the wrong airplane mode status,
eg. "Airplane mode is not active", and if you toggle that option, a wrong
intent is sent again to put ON the airplane mode, instead of OFF, the
toggle (that is in transition state) will be set disabled.

This commit fixes this issue.

Change-Id: Id30355c1e090355645c437086c79ab59093c27a8
BroadcastQueue: fix class typo of next receiver

nextReceiver should be cast to ResolveInfo
instead of ActivityInfo since it's ResolveInfo
that is pushed into List r.receivers.
Otherwise nextReceiver will always be null
as there is no ActivityInfo in r.receivers.

Change-Id: Iea3a720e6d7296fedff318643a1b4f5b9fce900c
Signed-off-by: Leavitt Zhang <leavittz@nvidia.com>
Fix the issue that the top of fullscreen dialog is clipped away

The visibility of status bar comes from the top fullscreen window,
not from the focused window.
That has to be taken into account during the calculation of the
decor rect. You can use mTopIsFullscreen for this purpose.

Change-Id: I6159eb2ee389885cf5ab507157f9451841364d2f