Fixes problem reading large thumbnails via PTP
Bug: 4065217
Change-Id: I643672512829c93ab0827091f39103dbb1918071
Signed-off-by: Mike Lockwood <lockwood@android.com>
Adding files outside $(LOCAL_PATH) is a bad idea. It generates output files
to an unexpected directory. In this case, it's
out/target/external/skia/src/images/SkImageDecoder_libjpeg.o
It's not in $(PRODUCT_OUT), which is not correct.
Worse, it makes the build system be unable to build different
architectures (arm and x86) simultaneously, since the output files
conflcit.
Seems we can just remove SkImageDecoder_libjpeg.cpp since it's
already in libskia.
Change-Id: Ia0ed72d8a6cbd3b2f3997b71dfdcf72fee50f5bb
o mainly use the defined class name rather than repeat the string each time
to reduce the typo chance.
o format the code also
Change-Id: I131c98f11335ff524d01a6791baa1b8c11013abc
* commit '75c95e9a6d5a91b660af62f72b5a3bac0f5c3811':
UsbManager: Hide APIs not needed for USB host or accessory support.
Remove MtpClient class from framework and public API
UsbDevice: Move IO related methods to new UsbDeviceConnection class
* commit '0eb7b697b7c180660647b5cd0cd7dd067f6b6abb':
UsbManager: Hide APIs not needed for USB host or accessory support.
Remove MtpClient class from framework and public API
UsbDevice: Move IO related methods to new UsbDeviceConnection class
* changes:
UsbManager: Hide APIs not needed for USB host or accessory support.
Remove MtpClient class from framework and public API
UsbDevice: Move IO related methods to new UsbDeviceConnection class
After reviewing this class I decided it would be best not to include it in the public API
since it adds no functionality that cannot be done using MtpDevice and other APIs directly.
So I am moving it to the CameraBrowser sample instead.
Also changed CameraBrowser to build against the SDK to ensure all the necessary APIs for
PTP support have been made public.
Bug: 4067029
Change-Id: I585b06104084953176d018ced08bba0cb4607490
Signed-off-by: Mike Lockwood <lockwood@android.com>
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>
Modifies Stagefright to verify that there is a hardware-protected path
to video sink for DRM content.
Change-Id: I18b8741390e803a05a88c7f180b860a24ba88a10
This patch fixs a crash bug caused by using a NULL DecryptHandle pointer.
Fix by using sp<DecryptHandle> instead.
Change-Id: Icbd59858385e8256125a615a3c82656b25319d44
* commit '18d8a0748d3c42a31799e5ce7c7f4c2fd63d1896':
MTP: Convert date created and modified values from seconds to milliseconds
Update USB accessory compatibility library to support new requestPermission API
UsbService: Don't require permissions for UsbManager.getCurrentAccessory()
* commit '564f12ebe409bead467eee04dfd719e97367e520':
MTP: Convert date created and modified values from seconds to milliseconds
Update USB accessory compatibility library to support new requestPermission API
UsbService: Don't require permissions for UsbManager.getCurrentAccessory()
* changes:
MTP: Convert date created and modified values from seconds to milliseconds
Update USB accessory compatibility library to support new requestPermission API
UsbService: Don't require permissions for UsbManager.getCurrentAccessory()
Use of this new datasource is now the default unless overwritten by
adb shell setprop media.stagefright.use-chromium false
Change-Id: I156a8eb9a1fff1cb537b4aec6cf3e8e6052be81e
* commit '093cf07f3c58a6553c415d750edba1a75b269f05':
Close USB dialogs if their corresponding accessory or device has disconnected
USB: Add API and dialog for apps to request permissions for USB devices and accessories
UsbService: Automatically use system apps by default if it is the only choice
New APIs:
UsbManager.hasPermission returns true if the caller has permission
for the given device or accessory
UsbManager.requestPermission poses a dialog to allow the user to give the caller
permission for the device or accessory.
Result is returned via a PendingIntent.
No dialog is displayed if the caller already has permission.
Also moved UsbResolverActivity to SystemUI package
BUG: 4069037
Change-Id: I93be769501a8776b49ac26e468af19f8fa2114c9
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
