ActivityManagerService lock and PowerManagerService.mLock can
be acquired in different threads in different orders.
registerReceiver() here tries to acquire ActivityManagerService
internally while holding mLock. A particular call from
WindowManagerService acquires these locks in reverse order.
This deadlock can be resolved by moving registerReceiver()
to another thread.
https://code.google.com/p/android/issues/detail?id=215254
Change-Id: I12cd610e61f212a3fb5e441f2c7a557c90afbda4
Signed-off-by: Shibin George <shibing@codeaurora.org>
SystemServiceMAnager.stopUser() acquires ActivityManagerService
lock first and then acquires MediaSessionService.mLock during
onStopUser(). MediaSessionService.onSwitchUser(), on the other
hand, acquires mLock first and ActivityManagerService lock next.
This is a potential deadlock situation which can be resolved by
moving getCurrentUser() out of synchronized block. This will
release mLock sooner and avoid the deadlock.
https://code.google.com/p/android/issues/detail?id=214469
Change-Id: Ieb4520d60af6ca38496ca933da0cd9ae096a9408
Signed-off-by: Shibin George <shibing@codeaurora.org>
- Use com.android.okhttp.Dns in place of com.android.okhttp.internal.Network
- Specify TimeUnit.MILLISECONDS for timeouts which 2.7.5 allows and
brings us closer to 3+
Change-Id: I95b5d72a94ebe1389f7c2e8d95903aa1aadd944b
This change reverts previous fix for b/27582395 and makes
AbstractStringBuffer an Appendable.
Bug: 28666126
Bug: 27582395
Change-Id: I4b1b554fb47f45459eec24801af4ec798fc3039b
While handling adjustVolume and finishReceiver at the same time,
system_server gets into deadlock situation where
ActivityManagerService lock and MediaSessionService lock are
getting acquired in reverse order. To fix this,
adjustSuggestedStreamVolume() is shifted to MediaSessionService's
Handler thread.
https://code.google.com/p/android/issues/detail?id=213014
Change-Id: I3125c890546c8ab7c4df530bb68ba87cd688f8ce
My logcat is packed with these dispatcher vsync pulse messages
that really don't seem to be describing an error case (though
maybe I'm wrong?).
So quiet it down a bit and set the loglevel to verbose.
Change-Id: Ic4359f64f9cecfc1ffe49275f5f63327ba1b6f1d
Signed-off-by: John Stutlz <john.stultz@linaro.org>
This library is built against the NDK, so it shouldn't be linking to
platform libraries. It should also be pulling <android/log.h> from the
NDK headers, so remove the system/core/include include directory.
Change-Id: Ie9d6514f43492401697907aee4df56bdbf4e1926
- If obex based profile explicitly sets GET with final flag, then
GET should always be sent as single packet request with final flag
set.
Change-Id: I82ff8295a239c4dbbfb4b3abfd358021820283cc
Align x offset and width to 32, y offset and height to 4.
It improves the font texture upload performance.
Change-Id: I967eeed90658f2ce1eb08cb2740d5dc34c72f40b
During shutdown of the Bluetooth stack, if a request to
enable Bluetooth is received, the request is processed immediately.
As a result, we don't let the Bluetooth service to shutdown cleanly,
and the Bluetooth process with the native backend doesn't go away.
This creates various issues in the native backend stack.
Now, after an enable request is received, if necessary we delay
acting on it, until the Bluetooth state is OFF.
Bug: 17723234
Change-Id: I55db4bbd4f45227aa49eae996dcc328f76557a9b
(cherry picked from commit e47ec14318f64c29bf16b5a6bb662bc19206d6b0)
It is related to Change: Id17bea8a6ca7132042b9bfefed398a715c139be7
Fix ANR because of bug of Visualizer.
If lpJniStorage was delete first, callback_data_lock become a invalid value.
At mReceiver.periodicCapture() in CaptureThread, it will lock callback_data_lock.
Thus, CaptureThread will wait a invalid memory forever and visualizer wait CaptureThread exiting and causing ANR.
Signed-off-by: ganxiaolin <ganxiaolin@xiaomi.com>
Native stack does not handle being put from OFF -> ON state without
doing a complete cleanup. Hence instead of going from start -> ON -> OFF
-> cleanup it goes start -> ON -> OFF ->ON -> ... usually leads to race
conditions down the road in native.
This patch is a workaround so that we can throw away the requests if we
are in currently "turning off" phase. The side-effect would be that user
will need to turn it ON again. The race happens when the turn OFF time
is longer but usually it is found to be close to order of seconds hence
the wait should be bounded.
Bug: b/28318203
Change-Id: I14f6633f31311e5b561e1dcbc8a9d6d2a5dd6fdc
NetworkPolicyManagerService.
if the multi user occurs switch and remove then to getPackagesForUid
the return value will got null,because the user remove is not synced
with the getPackagesForUid,so we must check the return value for
getPackagesForUid to avoid the crash.
https://code.google.com/p/android/issues/detail?id=211972
Change-Id: If921582da86dbe862f2dad337b0a8d1f20593c99
Signed-off-by: songjinshi <songjinshi@xiaomi.com>
