Gets a little more specific about thread behavior, and makes
pointed comments about not doing too much work in onCreate().
Change-Id: I682f0eb7d7559babee901ed26642751a6ba0a1ea
We can't use Parcel.writeValue() to write the ParcelFileDescriptor, otherwise
it leaks when returning the value to the caller (the flag gets lost). Change
the way DropBoxManager.Entry gets serialized so that it uses a bit of its own
flags value to track whether the data is a byte[] or a ParcelFileDescriptor.
Modify the dropbox unit test to add extensive checking of Entry serialization
and deserialization under various circumstances, and to include a regression
test to ensure that FD leaking doesn't happen.
Bug: 2847738
Change-Id: I4ccd17dd03ffab234340cd359e6f3510fdf81193
If the factory was obtained by calling getInsecure(), calls to
createSocket() should skip hostname verification (along with all of the
other skipped safety checks.)
This change slightly relaxes the too-strict checking that was introduced
in change 7fc93c36ae.
Bug: 2834174
Change-Id: Iab7ef861ad0ca727f82ee8cdb78b89b9e835740d
The problem was:
1. In handleShutter(), thread A in CameraService calls
registerBuffers(IMemoryHeap) and it's received by thread B
in system_server. [transaction 1]
2. While thread A is waiting for the reply, thread B calls
back to thread A to get the id of the heap
(IMemoryHeap.getHeapID). [transaction 2]
3. Thread A replies transaction 2 and is preemptied in kernel.
Thread B gets the reply and finishes registerBuffers and send
reply for transaction 1.
4. When thread A runs again, it gets the reply for transaction 1
and returns to handleShutter().
5. At this point the transaction buffer for transaction 2 (which
holds a reference to IMemoryHeap) is not freed because the
BC_FREE_BUFFER command is kept in thread A's local command
queue and not sent to the kernel.
6. Normally when thread A makes next transaction, the
BC_FREE_BUFFER command will be sent together (piggyback) with
the commands for that transaction. But in this case thread A
is a callback thread from camera driver, so it does not make
any binder calls afterwards, and the IMemoryHeap is never freed
(until the next time handleShutter is called).
Change-Id: I435a258187509bdbbaf353339eb9ea577610cbd2
Problem:
When the bluetooth device is removed, the AudioService clears all active SCO connections
and unlinks from the client application's binder interface death.
The problem is that the unlinking is done even if no more connections are active for a given client,
which throws a runtime exception that is not catched causing the system server to crash.
The fix consists in calling unlinkToDeath() in ScoClient.clearCount() only if the number of
active SCO connections for this client is not 0. The NoSuchElementException exception is also
catched when calling unlinkToDeath()
Change-Id: I7086424301fc63a5666da61c38169349d3e078f4
