Caused a local reference table overflow, only when deleting a large number
of files in a single SQL transaction in the media provider.
Bug: 4093346
Change-Id: I10078a5d7537c2e577763d88e909e34321945a59
Signed-off-by: Mike Lockwood <lockwood@android.com>
Bug #4092053
The problem always existed but was made visible by partial invalidation.
When saving a layer, the renderer would try to postpone glClear()
operations until the next drawing command. This however does not work
since the clip might have changed. The fix is rather simple and
simply gets rid of this "optimization" (that turned out to be
usless anyway given how View issues saveLayer() calls.)
This change also fixes an issue with gradients (color stops where
not properly computed when using a null stops array) and optimizes
display lists rendering (quickly rejects larger portions of the
tree to avoid executing unnecessary code.)
Change-Id: I0f5b5f6e1220d41a09cc2fa84c212b0b4afd9c46
java.lang.SecurityException: Neither user 1209 nor current process
has android.permission.WAKE_LOCK.
Change-Id: I3e84f8795941744e697824a5e5b2e651f565b253
UsbDevice is now just an immutable parcelable object like UsbInterface and
UsbEndpoint.
All IO related functionality is now contained in UsbDeviceConnection
and UsbRequest.
Bug: 4067029
Change-Id: Ia84da0b512a697acc940eee0c3566711c62e1a68
Signed-off-by: Mike Lockwood <lockwood@android.com>
- In Connectivity service, start WiMAX service
- 4G icon display in StatusBarPolicy
- Add DHCP renew
- Add radio for WiMAX
Change-Id: Iffff012b270d80e84ec8fbd4486921a8adb847dd
Signed-off-by: TK MUN <tk.mun@samsung.com>
The new android_reboot() function is a nicer way to reboot.
It can optionally sync(2) and remount as read-only writable
filesystems. This fixes bug 3350709.
Change-Id: I792fa3f726f8d685a696f52cf760e731567ed8d4
This change fixes the stability problems experienced when using
a bluetooth headset supporting both A2DP and SCO. Problems occur
when starting the video chat at which time the A2DP output is being
stopped to start SCO. At that time, active AudioTracks are invalidated
by AudioFlinger so that a new AudioTrack binder interface can be
recreated by the client process on the new mixer thread with correct parameters.
The problem was that the process to restore the binder interface was not
protected against concurrent requests which caused 2 binder interfaces
to be created sometimes. This could lead to permanent client deadlock
if one of the client threads was waiting for a condition of the first
created binder interface while the second one was created (as the AudioFlinger
would only signal conditions on the last one created).
This concurrent request situation is more likely to happen when a client
uses the JAVA AudioTrack as the JNI implementation uses simultaneously the
native AudioTrack callback and write push mechanisms. By doing so, the code
that checks if the binder interface should be restored (in obtainBuffer()) is
much more likely to be called concurrently from two different threads.
The fix consists in protecting the critical binder interface restore phase
with a flag in the AudioTrack control block. The first thread acting upon the binder
interface restore request will raise the flag and the second thread will just wait for
a condition to be signaled when the restore process is complete.
Also protected all accesses to the AudioTrack control block by a mutex to prevent
access while the track is being destroyed and restored. If a mutex cannot be held
(e.g because we call a callback function), acquire a strong reference on the IAudioTrack
to prevent its destruction while the cblk is being accessed.
Modified AudioTrack JNI to use GetByteArrayElements() instead of
GetPrimitiveArrayCritical() when writing audio buffers. Entering a critical section would
cause the JNI to abort if a mediaserver crash occurs during a write due to the AudioSystem
callback being called during the critical section when media server process restarts.
Anyway with current JNI implementation, either versions do not copy data most of the times
and the criticial version does not guaranty no data copy.
The same modifications have been made to AudioRecord.
Change-Id: Idc5aa711a04c3eee180cdd03f44fe17f3c4dcb52
Bug #3461349
This change also fixes two bugs that prevented partial invalidates
from working with other views. Both bugs were in our EGL implementation:
they were preventing the caller from comparing the current context/surface
with another context/surface. This was causing HardwareRenderer to always
redraw the entire screen.
Change-Id: I33e096b304d4a0b7e6c8f92930f71d2ece9bebf5
Bug #3461349
Before this change, eglGetCurrent*() could not be used to compare
contexts, displays and surfaces at the Dalvik level.
Change-Id: I442037dae37bc357b64810ab10c779b5754e9153
It's legal to call unlinkToDeath() *after* receiving binderDied(),
as long as the recipient being unlinked was in fact linked
previously. Don't throw an exception in this case. (The
exception was going unhandled in the system process, bringing
down the runtime. That's bad.)
The change here is a bit subtle. In the new implementation, the
lifetime of a JavaDeathRecipient -- the fundamental bridge between
IBinder objects and the Dalvik/JNI world -- is tied to the
lifetime of the Dalvik-side BinderProxy object it's associated
with. That means it's inappropriate for the JavaDeathRecipient
to disappear [for purposes of being referenced from the Dalvik
side] just because the IBinder has sent out its obituaries, and
instead the JavaDeathRecipient objects are kept around until
the Dalvik-side client code actually drops its reference to the
BinderProxy.
This boils down to a one-line change: we no longer unpin the
JavaDeathRecipients and free them immediately in response to
binderDied().
The rest of the CL is #ifdefed-out debugging that is invaluable
when bugs crop up.
Bug 3513703
Change-Id: I743fa49669c9252f71dcabfd8dcf42ed729b70a5
Added some plumbing to enable the policy to intercept motion
events when the screen is off to handle wakeup if needed.
Added a basic concept of an external device to limit the scope
of the wakeup policy to external devices only. The wakeup policy
for internal devices should be based on explicit rules such as
policy flags in key layout files.
Moved isTouchEvent to native.
Ensure the dispatcher sends the right event type to userActivity
for non-touch pointer events like HOVER_MOVE and SCROLL.
Bug: 3193114
Change-Id: I15dbd48a16810dfaf226ff7ad117d46908ca4f86
There was an issue with stale recipient tracking when BinderProxy weak
references had been purged and a new proxy object allocated for a
still-live underlying IBinder. The death recipient bookkeeping has
now been reworked so that it's fundmentally tied to the BinderProxy
instances, not maintained as global state, to prevent this sort of
confusion entirely.
Bug 3499939
Change-Id: I75c5216b6d53b90868ac969e32c9725201e51be3
Also switch to using libcore's array bounds checking. (This variant had no
detail message and was missing the length check.)
Bug: http://code.google.com/p/android/issues/detail?id=15075
Change-Id: Icfc045bd59403b59f02d95c8514abf881d3996e5
There are two areas that have changed to eliminate the assumption that
local jobject references are both canonical and persistent:
1. JavaBBinderHolder no longer holds onto and reuses it parent object
reference per se. Since the underlying JavaBBinder object holds a
real global ref, this was redundant anyway. Now, for purposes of its
transient need to perform JNI operations, it simply uses the current
jobject ref(s) passed during method invocation, and no longer attempts
to hold these refs beyond the scope of a single invocation.
2. Binder obituaries no longer assume that a jobject reference to a
recipient will always compare == as a 32-bit value with any future
reference to the same object. The implementation now asks Dalvik
whether object references match.
This amended patch fixes the earlier bug around races between
remote binder death cleanup and local explicit unregistration of
VM-side death recipients.
Bug 2090115
Change-Id: I70bd788a80ea953632b1f466f385ab6b78ef2913
some of the conversion operators were not using the proper
pointer type when calling incStrong/decStrong, usually it
has no bad consequences, but for some implementation
of the ref-counted object it could lead to recording the wrong
owner id.
Change-Id: If574b9069b8a4cf6e0911a992c8f095aba799995
There are two areas that have changed to eliminate the assumption that
local jobject references are both canonical and persistent:
1. JavaBBinderHolder no longer holds onto and reuses it parent object
reference per se. Since the underlying JavaBBinder object holds a
real global ref, this was redundant anyway. Now, for purposes of its
transient need to perform JNI operations, it simply uses the current
jobject ref(s) passed during method invocation, and no longer attempts
to hold these refs beyond the scope of a single invocation.
2. Binder obituaries no longer assume that a jobject reference to a
recipient will always compare == as a 32-bit value with any future
reference to the same object. The implementation now asks Dalvik
whether object references match.
Bug 2090115
Change-Id: If62edd554d0a9fbb2d2977b0cbf8ad7cc8e2e68d
When extractAlpha() native method in Skia fails to allocate pixels,
it resets target bitmap. This change detects when such empty bitmap
is returned, and throws a OutOfMemory Java exception.
Depends on https://android-git.corp.google.com/g/97793
Bug: 3418381
Change-Id: I65a84998be089c49ed5005f6995bdc4f4d1669bc
NativeActivity created a pipe to wake up a Looper it's attached to, but
it failed to set the right options for the read part of the pipe. This
affects only the NativeActivity API call for AInputQueue_hasEvents
Change-Id: I02e5dad4e700f4c724b3187a4b7e0df931dd1eed
Background scanning (preferred network offload) allows us the
host to sleep while the dongle monitors the presence of any
preferred networks. This allows us for significant power savings
since the system does not have to wake up often to initiate
a scan
Bug: 3453021
Change-Id: I7c1dbfd0c3f717df81e4da6091c4c5657c9ec9ca
