Because not all MTP devices support getPartialObject, we need to check
supported operation of MTP devices. The CL adds operationsSupported
field to MtpDeviceInfo class.
BUG=26147375
Change-Id: Iaad968fb4497a5ad11bf6489097abea99c3cbac7
Moving forward, all client file access really needs to be going
through explicit APIs like openFileDescriptor(), since that allows
the provider to better protect its underlying files.
This change also changes several classes to use the AutoClosable
pattern, which enables try-with-resources usage. Older release()
methods are deprecated in favor of close().
Uniformly apply CloseGuard across several classes, using
AtomicBoolean to avoid double-freeing, and fix several resource
leaks and bugs related to MediaScanner allocation. Switch
MediaScanner and friends to use public API instead of raw AIDL calls.
Bug: 22958127
Change-Id: Id722379f72c9e4b80d8b72550d7ce90e5e2bc786
* Hook up the native allocation registration with ImageWriter, such that GC
can get some hint when clean up the large memory object.
* Close all pending images when closing ImageReader. This could avoid native
mem leaks for some bad app practice. For example, some apps may hold images
in background service when activity is paused/destroyed, which could cause
huge native memory leaks even ImageReader is closed.
* make Image close thread safe: it is possible the clients close the image
in listener thread and the client main thread.
* Some minor code refactor to reduce the code duplication.
Bug: 25088440
Change-Id: I37d22b52aeb8d2521bf9c702b0f54c05905473e0
Errno values have been hard-coded inside java code. On the native side
however, bionic's errno.h is used (through utils/Errors.h). Some of
the numbers are architecture dependent (EOPNOTSUPP, ETIMEDOUT...).
This causes Camera app to crash on MIPS devices. There is a check for
expected errors, in CameraBinderDecorator.throwOnError, but the error
(EOPNOTSUPP) is not recognized and an exception is thrown.
Change-Id: I8bcac8f1ced50c76614f566a6e624967a18a25e1
Sample decoding still occurs in SoundPoolThread
without holding the SoundPool lock.
Bug: 25781119
Change-Id: I11fde005aa9cf5438e0390a0d2dfe0ec1dd282e8
(cherry picked from commit 0275a982abecee683f16c827d405eafe51fb67ae)
An upcoming change will remove "synchronized" from the API docs. This change
documents those cases where the guarantees can be determined from code
inspection.
Bug: 25767152
Change-Id: I75083ce01513ed315222304fe3f34190d40748cb
Remove dead code related to media button event receiver and
remote control display, now handled by MediaSession*
Change-Id: I4bd621240ddddf4df079df8d551c72b232c3301d
Ignore setWakeMode based on system property.
Wakelocks essential for playback will be held by audioflinger.
Change-Id: I413cd873bf21e1e999dbf89a27802fbe1b6022c7
Signed-off-by: Sridhar Vashist <svashist@motorola.com>
When the wall clock is adjusted to the broadcast time, the duration
measurement in ITvInputSessionWrapper may go wrong. To avoid this, use
System.nanoTime() that doesn't depend on the wall clock.
Bug: 25370822
Change-Id: I2ddb968b5e146500429b82979fe48262bf335993
Actually, this implementation is more what we want for ephemeral
apps. I am realizing the two are not really the same thing. :(
For this implementation, we now keep track of how long a uid has
been in the background, and after a certain amount of time
(currently 1 minute) we mark it as "idle". Any packages associated
with that uid are then no longer allowed to run in the background.
This means, until the app next goes in the foreground:
- No manifest broadcast receivers in the app will execute.
- No services can be started (binding services is still okay,
as this is outside dependencies on the app that should still
be represented).
- All alarms for the app are cancelled and no more can be set.
- All jobs for the app are cancelled and no more can be scheduled.
- All syncs for the app are cancelled and no more can be requested.
Change-Id: If53714ca4beed35faf2e89f916ce9eaaabd9290d