Prevent erroneous calls to OnCheckedChangedListener

This change updates the CheckedStateTracker so that it only
updates the RadioGroup's checkedId when a RadioButton is
checked. Previously, the CheckedStateTracker would call
setCheckedId() even if it was responding to an uncheck
event (e.g. when calling clearCheck() to uncheck all radio
buttons). This would in turn cause a bogus call to the
RadioGroup's OnCheckedChangedListener, falsely indicating
to the listener that the unchecked RadioButton had just
been checked.

This issue is reported on b.android.com: Issue 4785

Change-Id: Ida4d4be478db38b8972359055119b5e6d285c20e
Signed-off-by: Scott Weber <scott.d.weber@gmail.com>
frameworks: Fix interface monitoring failure

On supplicant restart condition monitoring ifname
is getting removed from hash map. Due to which
the monitoring is getting failed after restarting
of the supplicant.

So dont remove the ifname from Hash map in
WifiMonitor on supplicant connection fail case.

Bug 67606

Change-Id: If972151ebc9b7f312be583dc8562ca24677e8dc0
Removed android.debug.JNITest from preloaded-classes

android.debug.JNITest class no longer exists in this
project. This patch updates preloaded-classes accordingly
to avoid spurious warning during boot.

Change-Id: Ia4a5a1858f6c87fbc594a623adb95454334361ea
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Fixes ViewLocationHolder.compareTo(), guarantees transitive property across comparisons.

I have an application that crashes whenever accessibility is on. The crash happens when the views on the activity are sorted; the sorting algorithm is a merge sort that tests as it merges, when it finds non-transitive comparisons (e.g., A>B, B>C, but !(A>C)), then it throws an exception. The current ViewLocationHolder.compareTo() does not guarantee transitivity.

My patch simplifies the comparison, and also changes it to guarantee that A>B and B>C will always mean A>C. I believe that it keeps the intent of the original sort order.

Change-Id: I375837241edb6b9b8ccb7a167731398f3af5a2b2
Avoid calling into DiscardData() twice when ReadJpegFile() fails

If ReadJpegFile() fails, DiscardData() will be called before return
from ReadJpegFile(). So we shouldn't call it again outside.

Change-Id: I8b340f485052c86874081a4a1ef39e425cd3b81d
Signed-off-by: Du, Changbin <changbinx.du@intel.com>
Avoid SystemUI crash due to NPE

BaseStatusBar.createNotificationViews() returns null
when it reports handleNotificationError(), leading to
a forced crash of the misbehaving app. However, it
should not add a null object of Notification.Entry
since it will also crash SystemUI (crashing at compare).

Change-Id: I86678c8024e931420b0fbab1f36b330e7e75d581
DO NOT MERGE - [ActivityManager] Ensure consistency behavior when a background activity brings another existed activity to front.

Symptom: ANR occurs on previous activity.
Root Cause:
In KK, when a background activity starts another existed background activity (bring to front),
if current focused stack is not the same as the stack of target starting activity,
it will still resume the top of target stack, even the top activity on the target stack may not the same as target activity.
And it will result incorrect focus, press back key will send to previous stack's top then popup ANR on previous activity:
"Reason: Waiting because no window has focus but there is a focused application".

By original code comment, it looks 'bring to front' should not happen in this issue case.
// If the target task is not in the front, then we need
// to bring it to the front...  except...  well, with
// SINGLE_TASK_LAUNCH it's not entirely clear.  We'd like
// to have the same behavior as if a new instance was
// being started, which means not bringing it to the front
// if the caller is not itself in the front.

If the caller and target are in the same stask, it will just deliver new intent without changing task order (the same behavior as JellyBean).
So the patch concept is just to avoid to use target stack to resume top when caller and target are in different stack.

Solution: Do not allow to resume another stack top if non-top activity try to bring existed activity to front.
It may not be a good solution, just a reminder for the issue case.

Reproduce steps:
Assume A, B, C are different app tasks.
When the application stack is like:
  Top C
      B
      A

 #Case 1: Home is foreground
  A starts B with NEW_TASK, C will resume, focus still stays at Home, and window order does not update.
  Then press back key or volumn key will result ANR on Home.

 #Case 2: App is foreground (Resumed activity is C)
  A starts Home, Home will resume, focus still stays at C, and window order does did not update.
  Then press back key or volumn key will result ANR on C.

Change-Id: If05070123b248e2335791e43a4d4ddee6db11d84
Cast CallMethod's size_t parameters to jint

This will avoid problems caused by automatic type
promotion of parameters when passed to a variadic function.

Change-Id: I9340cf4bc3afcb84ebb2843d2aaa1e832b0df7f4
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Fix RenderScriptGL setSurfaceTexture problem

rsnContextSetSurfaceTexture() has no implementation in rs-jni, use nContextSetSurface() in setSurfaceTexture().

Change-Id: I066432575c9e74f21ea3a3776628b572b6e31377
Signed-off-by: Xiaofei Wan <xiaofei.wan@intel.com>
Handle NullPointerException

When clearClientLocked() is called twice in a row,
(ex. When Spooler Service is killed by LMK, it is called by unbindLocked() and onServiceDisconnected())
it could cause NullPointerException.
So add 'catch' clause to handle it.

Change-Id: I60540c35f09ffe309836b207d2d354ef77b00ff0
hwui: fix projection uniform caching.

The previous caching would only consider a change in the
actual matrix to figure out that the projection matrix
uniform needs to be updated. This would not work if the
requested projection matrix is identical, but only the
offsetting would change.

The fix now considers changes in the requested offsetting.

Change-Id: I49848de99a4ef80f43d9ca8437aa8403759c7d28
Use default visibility for Snapshot::getLocalClip.

The method is in libhwui.so but used by libandroid_runtime.so
(via android_view_GLES20Canvas.cpp). If the compiler decides not to
inline this method, the linker won't be able to resolve the dependency
when it has hidden visibility.

The problem is found when testing GCC 4.9.

Change-Id: I3b4d096c7767f0bef0796886dfb2c5ba2ecff48c
frameworks: Rquests permission for accessing downloaded files

Allowing systemUI to share downloaded files with RecntsPanelView
via granted permission request ACCESS_ALL_DOWNLOADS.

Change-Id: If7a137639ed69c43cf7736756abe0f1b98442010
ImagerReader: Return the buffer to queue if it fails to lock

Return the buffer to the queue when failing to lock it with the
error ACQUIRE_NO_BUFFERS, which acquireNextImage of
ImageReader will return null. Otherwise, there is no chance to return
the buffer back later since the caller can't get the new SurfaceImage
object.

Change-Id: I774e91d52f3e10c8d2dd88d835505da79086c5b2
[ActivityManager] Reduce report ANR on wrong activity.

Symptom: ANR report on wrong activity.

Root Cause:
  KK changed resume behavior that will not update focus when only resume,
if the activity blocked, it may report ANR on previous focus.
  By original concept, it will try to correct the ANR target,
but the stack of waiting(waitingVisible=true) activity may
different with current top stack.
  If it gets key dispatch timeout, mResumedActivity and mPausingActivity
of its stack will be null becuase it is not top stack.
Then it is unable to change ANR target to the real no response activity.

Solution:
 Use focused stack to get the real culprit.

Reproduce steps:
1.Launch an Activity X from launcher, press home key.
2.Launch X from launcher again, X blocks(sleeps 15sec) in onResume, press back key in the beginning of blocking duration.
3.ANR dialog shows launcher is no response.

Change-Id: I99416ad91e349096f995990f2240a97616fbaf28
mSurface was reset and lost initialization.

mSurface got reset and lost initialization when the developer call
setSurfaceTexture() in onSurfaceTextureAvailable().

Change-Id: If07260e3897e99b96e7a9d86ee5bc1528fb30ab4
Signed-off-by: ChaoJun Xue <xdtq47@motorola.com>
Fix a system crash due to orphan HandlerThreads

In SeekBarVolumizer class a HandlerThread is
instantiated that is not halted after the object
is garbage collected. The final consumer of
this class is volumes adjustment dialog in Settings.
If the user invoke the dialog several times, many pipes
are opened in Settings process that it finally exceeds
the maximum permitted number and the system crashes.

Change-Id: Ifd777365b5779f5db92c605413eb0254a53c8b00
Fix crash when saving cropped Wallpaper for non loaded photo

If attempt to save cropped Wallpaper in WallpaperCropper prior
to having an image loaded and displayed the application will
crash for user.

Crashing due to attempting to figure out cropped bounds for
not yet loaded image. Attempting to access image source prior
to being loaded triggers a NullPointerException. This due to
source not yet being set.

Solved by blocking attempts to save cropped image as wallpaper
until source image has been loaded.

Change-Id: Ie4011cef6da0c1fa4a8bc742cece85a0283bb5f6
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>
Sometimes property service is slow to respond.

Upon boot-up, telephony service will update the system property for
timezone and send out broadcast.The property service won’t handle
the update immediately if the init process was doing something
time-consuming. Meanwhile StatusBar(one broadcast register) may get
the outdated value by reading from system property, because the
update is not handled yet. Then wrong time will be displayed on
status bar.

Change-Id: Ic29b7940b58e01651da4e0bafa7a88b902164bd0
Signed-off-by: Gao,KunX <kunx.gao@intel.com>
Signed-off-by: Guobin Zhang <guobin.zhang@intel.com>