CloseGuard instances are allocated in constructors and usually
assigned to final fields. This implies they're non-null in finalizers
except in the case where the constructor throws. We add a null check
to make sure we can continue cleaning up other state in the finalizer
(if applicable).
Also, this change decouples closeguard warnings in constructors
from other state based logic. This because the logic there is usually
duplicated with the call to close().
NOTE: This change is not a "complete" fix. Many of these finalizers
are broken in the case where <init> throws. The only objective of
this change is to make such errors more obvious.
Note that some of these classes don't have CTS tests.
Test: make, CtsMediaTestCases.
Bug: 35609098
Change-Id: I24d9e0215f80e44914dba8ab99b6312fd6ed1fc0
The USB data transfer is disabled we should not allow access MTP devices (e.g.
usb sticks). We have two ways of accessing them: Either by mounting them
or by creating a MTPDevice in an app.
Of course an app could implement implement their own MTPDevice
implementation. In this case we cannot enforce the policy without
completely suppressing all MTP USB devices which would be too
restrictive.
Note: When the policy is set we do _not_ disconnect already connected
MTP devices
Fixes: 31472955
Change-Id: I6080c48c49657102774b2b3b4d89ff030245a266
Previously MtpDevice#readEvent does not have throws IOException at its
definition, though internal JNI functions throws it.
BUG=28254719
Change-Id: I4e6cf8003d168b7e732c4b4eb2eafe52a12442c2
* MtpEvent: Remove public constructor since properties cannot be set
directly.
* MtpEvent: Move event constants from MtpConstants to MtpEvent class.
* getPartialObject64: the byte[] must have indices of Integer.MAX_VALUE
at most. Document as such.
* sendObjectInfo: what happens if the transfer doesn’t succeed? How is
the app notified? If there is a reason for the failure communicated,
how does the app find this out? Add docs.
* Add isOperationSupported(int) and isEventSupported(int) helpers.
Change-Id: Ifd80016d2ddd3b66d5c45f6da76b6133f0c9a617
Fixes: 28146379
In the MTP spec, the object size is stored in MtpObjectInfo as unsigned
32-bit integer and fetched by the getObjectInfo operation. For the
objects that are more than 4GB, the object size is provided as one of
extra properties, which are fetched by different operation.
The CL adds to getObjectSizeLong hidden method to Java MtpDevice class
so that client code can obtain 4GB+ object size.
BUG=27805369
Change-Id: I8a5b85c8db39734f00e49709c61b271eb48ff33d
long.
To represents full range of 32-bit unsigned integer, we should use
jlong instead of jint.
BUG=26284424
Change-Id: Id3fa9e3daa778c204ab8e38f821d454c709c317a
The existing APIs required to copy all bytes to memory, which will fail in
case of very large files, like movies.
Bug: 22908937
Change-Id: I23bdcbdbf08b7c1b1017591799bbb94e53249a57
For storing pointers, long is used in MTP classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I67805547251722e7b77611d47d0bb632a64d3e6d
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.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>
This replaces the previous ContentProvider based interface
Change-Id: I4cea2544854adb9fdcc04345e4d73d8ef05380f3
Signed-off-by: Mike Lockwood <lockwood@android.com>
