are not error logs from non-DRMed content's point of view.
- Add more mutex lock to avoid crash by multi-thread calls.
- Fix for bug 4050039
Change-Id: I52fed22069f0cda6c4ac6a5363469168c797a33b
* 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()
...addHistoryRecordLocked(BatteryStatsImpl.java:1210)
It was doing a bunch of stuff without holding a lock!
Change-Id: Ie5b56514370e0bfc87ba7737d75e01df0859817e
Permission check should only happen in openAccessory()
Otherwise an application will not be able to check for the current accessory
and ask for permissions (if it is a suitable match for the application)
BUG: 4069037
Change-Id: If5b44ebda2e8077598d96629163cc74aa336589e
Signed-off-by: Mike Lockwood <lockwood@android.com>
If the user approves an application to access a USB device or accessory
without choosing it as the default application, then permission is granted
only until the device or accessory is disconnected.
Only applications chosen as the default choice have permissions assigned persistently.
BUG: 4061035
Change-Id: Ic4f6271a91b2fc56bbeef82c579e26d88c63ae56
Signed-off-by: Mike Lockwood <lockwood@android.com>
The flag mIsHandlingMultiTouch was used to remove the out of order
touchMove events. After the fix b/3307761, it is no more needed.
Change-Id: I4d03131e2a22c53cc79c4105e39f078f1bea88ca
* changes:
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
consistent with the "up" indicator
Make sure that the "home" affordance in the action bar always occupies
the same amount of space regardless of whether or not the "up"
indicator is visible. This means centering the application icon/logo
in the remaining space after the "up" indicator has been added.
Change-Id: I3c81cfe8255546d4dd676af913895713baba4f13
Persist the setting of wifi override in airplane mode
so that it can be restored on reboot
Bug: 3250824
Change-Id: I2af38c282ba55fc150fd9ef783d43600f0d4260f
This fix ensures captured thumbnails in portrait mode have the
same resolution as those in landscape by fixing the horizontal
resolution and vertical resolution of the target image.
The returned image is now always the same size and matches
the landscape screen exactly. In portrait mode, it grabs
the upper portion of the screen based on the vertical dimension
of the target image.
Change-Id: I203c39843f2f21ca28f6ef0dffec308ce5cb39fb
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
If only one app is installed that supports a USB device or accessory
and that app is in the system partition, then use that activity by default
and rather than displaying the USB app chooser dialog.
BUG: 4060064
Change-Id: I49bf22a439e9676039b6f612c9bb622ab426066c
Signed-off-by: Mike Lockwood <lockwood@android.com>
This change makes Context initialization wait properly for all threads to be
available before leaving initContext(). This prevents a case where ~Context()
gets called before all created threads have started/finished their work. This
was triggered/discovered by running some very short-lived tests in CTS.
BUG=4064203
Change-Id: I1dd6f43fa7942c53881008e857df864e2395202e
This change adds a new 'method' to the ANativeWindow interface to check
whether buffers queued to the window will be sent directly to the system
window compositor.
Change-Id: I4d4b199e328c110b68b250029aea650f03c8724d
Bug: 3495535
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