Refactor code to avoid a return statement inside a finally block. Such
constructs interfere with exception propagation in non-obvious ways
and are therefore considered bad practice.
Bug: 32586420
Test: manual code walk
Meaning: Read/Write to correct area in buffer, set position correectly.
- Create a new method UsbRequest#enqueue that has correct behavior, deprecate
UsbRequest#queue.
- Move all description of the weird (legacy) UsbRequest#queue behavior to
this method.
Change-Id: Ibeed400b4ad2aa9d005ace345c7895a3dc4ba1ad
Fixes: 31050148
Test: Submitted alongside
onCaptureQueueEmpty indicates that the non-repeating
capture request queue of camera device is empty, and
is ready to process a new request.
Test: testMultipleCapture in PerformanceTest.java
Bug: 29006447
Change-Id: If245ff6abf352548ca13a10fcfbd1550b92c1224
This gets rid of an extraneous configuration change when going from
adb to adb + file transfer as previously the config would have been
reset once for functions and once for data unlocked.
It also simplifies some of the code.
Test: manually changing usb configurations
Change-Id: Ica10a195338b2189db13113f44657393db110bee
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
This is obviously just about describing a bad behavior. In the next step
these methods should be deprecated and replaced with versions that deal
with ByteBuffers appropriately.
Bug: 31050148
Test: Test that enshrines the documented behavior is submitted alongside
this change
Change-Id: If250a8bbd636784355e839a1638d52f3bbe9b83d
The static initializer for a pre-loaded framework class is run
no later than at zygote startup, which happens at device boot.
Which means that if the timezone later changes, DngCreator will use
an incorrect cached timezone until the next reboot. This is especially
evident in freshly wiped devices, where initial setup will typically
change the timezone.
Instead, read the timezone each time DngCreator is created, which is
also when we query the current time for constructing the timestamps.
Test: android.hardware.camera2.cts.DngCreatorTest#testSingleImageThumbnail
Bug: 31743060
Change-Id: I83a4eac762650e5f904f3b8fa779c094cef30562
The NanoApp.java class has a bug (b/30808791) where the API treats
app IDs as 32-bits, instead of 64-bits. We are too late in the
Android N release cycle to change this API.
We previously put in a hack to fix this only for Google nanoapps.
However, our GTS nanoapps need this to work, and there are other
partners who need this to work in the N timeframe. So we make
a more robust hack which parses the full 64-bit app ID out of
the header binary.
Test: Compiles and runs GTS
Bug: 31767599
Change-Id: Ic43f1f62c685fb99aac08d08767d1a67c329503f
- Do not allow negative length as inside of JNI this is interpreted as
unsigned value which lead to memory corruptions.
- Document behavior for uncommon but usable values of parameters
Test: Ran CTS verifier UBS device test
Change-Id: I0899a2831c6dd2617528a5e79ea21932f6a66c13
Converting the sensor timestamp to date/time requires checking
what the timebase of those timestamps is; getting it wrong will
create drift that increases with device uptime.
Test: android.hardware.camera2.cts.
DngCreatorTest#testSingleImageThumbnail
Bug: 30125412
Change-Id: Ia5db86012bc9e1c06463b8dc4434d3e063f62cf5
Otherwise a second thread might dequeue() it in between
native_queue_direct and mBuffer = buffer. If that happens the dequeue
operation does mBuffer.isDirect which triggers a NPE.
Fixes: 30914003
Change-Id: I3ca3b72db8f53a14be1c5f0e37f8924eba44b9bc
This is the previous behavior and there are users that just copy the fd
and then forget about the connection. In this case it is unsafe to close
the fd when finalizing.
Change-Id: I5cd76564e1e8ddbd61c829b34b0f43b9c699f094
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
To speed up camera startup, allow setting up a camera capture session
before all the output Surfaces are available (but their eventual sizes
and types are known). Also allow images to be captured to the
non-deferred outputs even before the deferred outputs are available.
This allows parallelizing of camera startup and UI layout.
Test: android.hardware.camera2.cts.SurfaceViewPreviewTest#testDeferrredSurfaces
passes
Bug: 31319716
Change-Id: I657efc39bb8cc2d4bf201e5d70807a227ef82dde
The native code uses mNativeContext=0 to indicate that is was already
closed and checks this properly. Hence let's leave the checking in the
native code.
We need to keep a reference in UsbRequest as otherwise the
UsbDeviceConnection might get finalized while a UsbRequest is in
progress. The UsbRequest itself makes sure that it is not garbage
collected while the I/O is in progress.
Also I added CloseGuards to make sure the classes are used properly and
fixed an error string in the native code.
Fixes: 31124312
Bug: 31021315
Change-Id: I96deb73957eba0e14e6b656988a2ae9b409bf55f
To workaround b/30808791 without changing the NanoApp API,
we make the assumption that if the most significant byte
of our four-byte app ID is a lower-case 'L', then this
is a Google Nanoapp and thus we should use "Googl" for
our vendor ID, and set the most significant four bytes
of our eight byte app ID accordingly.
Bug: 30922112
Change-Id: I155dff58cdda1ef36a68e6d25df1e9059b1252f1
- Setting config_UsbDeviceConnectionHandling_component leads into
launching specified Activity whenever USB device is connected.
- This allows external Activity to manage USB device based on
its own setup and settings.
- Device access can be passed to other app with permission update
by UsbManager.grantPermission.
- added UsbDeviceConnection.resetDevice() to reset USB device connected.
This is necessary to get device out from AOAP.
- Test requires installing UsbHostExternalManagmentTestApp and
AoapTestHost to USB host, and AoapTestDevice to USB Device.
bug: 26404209
Change-Id: I8e77ddc646c15454d9b2ecf1356924cf6351fc28
Our getNanoAppInstanceInfo() method returns incorrect information
for several fields in many cases. We're too late in the release
cycle to fix the core of this issue, but we can at least document
it so users aren't surprised.
Bug: 30944457
Change-Id: I9330c3b77d08c36befbe20258c6cc45dc640f103
There's no API to set mContextHubId, but testMatch() uses this.
We can't add API at this point of the release cycle, so instead
we default mContextHubId to HUB_ANY, which makes it always match.
Bug:30018518
Change-Id: I4e08afc65889dc109a4da1bd99a027345da865ca
