Rename existing test database to MtpSqliteDatabase
This is the first step in transitioning to using the media provider database
Change-Id: I5f36c854c6e76a79137c267b000a52ced803776c
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'c4be155a540695c42bcd6589604f86d300f4548f'
* commit 'c4be155a540695c42bcd6589604f86d300f4548f':
Add an option to ALooper::start that allows it to call back into java or not.
Merge commit '2cfd8198cc4e1dcdcae52ae8a0c86b871c87a27e' into gingerbread-plus-aosp
* commit '2cfd8198cc4e1dcdcae52ae8a0c86b871c87a27e':
Add an option to ALooper::start that allows it to call back into java or not.
the touch incon url instead. The DownloadTouchIcon class will handle the case that
this file does not exist on the server.
Change-Id: I8ab8fd65b571584d7b648af72c568f0b01c2dcaf
Merge commit 'd15d0e9fd33109f60bd30b26bae782f2fe5531a4'
* commit 'd15d0e9fd33109f60bd30b26bae782f2fe5531a4':
Flush binder buffer after setting raw heap to avoid leaking a reference.
Merge commit '3ef6ebe874022c4ec8fbb00067833a6f636c1e2f' into gingerbread-plus-aosp
* commit '3ef6ebe874022c4ec8fbb00067833a6f636c1e2f':
Flush binder buffer after setting raw heap to avoid leaking a reference.
Merge commit '7df7447112371fb5e46f6084b55ac2ccdfde139d' into gingerbread
* commit '7df7447112371fb5e46f6084b55ac2ccdfde139d':
Flush binder buffer after setting raw heap to avoid leaking a reference.
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
Merge commit '5c57e03d3dbd474deb73f51b564c4fb929a2a816'
* commit '5c57e03d3dbd474deb73f51b564c4fb929a2a816':
Log full exception when failing to inflate notification view
Merge commit '6ffd9ff07733a855daeda75416cea88e7456e9d6' into gingerbread-plus-aosp
* commit '6ffd9ff07733a855daeda75416cea88e7456e9d6':
Log full exception when failing to inflate notification view
Merge commit '39c921c6e5316696d8c61d1ee465f9b5f894c4ed'
* commit '39c921c6e5316696d8c61d1ee465f9b5f894c4ed':
Get to the point of being able to do native drawing.
Merge commit '8ae5a8e7c04c7b204b739dfcd5da9e2e0f83e1eb' into gingerbread-plus-aosp
* commit '8ae5a8e7c04c7b204b739dfcd5da9e2e0f83e1eb':
Get to the point of being able to do native drawing.
The texture cache was previously checking the number of stored textures. This was
not very useful as this could easily lead to an abuse of memory. The new cache
instead tracks the total size occupied in RAM by the cached textures. When a new
texture is generated, older textures are kicked out as needed.
Change-Id: Ib27142f4a018d5bf84774c1fb6f45a67a85f20bc
When inflating a notification's view fails, include the exception in
the log message. Without this exception all we get is "couldn't
inflate view for notification <package>/<id>", which isn't very
helpful for tracking down the particular error in the view.
This exception used to be included in the log message, but it was
removed in 005847b03b2 -- any particular reason why?
Change-Id: I623b9e4c8291e4c035f26380e5f22ad6b65176a7
Also improve the documentation to make it a little less unclear what this
is all about. In particular, explain why the original submitter's complaint
about "zero" never being used in English, is expected behavior.
Bug: 2663392
Change-Id: Iade3b4f5c549ce01a95fd0e7e5c6ea394178eda3
