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
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
Most notably, the loadNanoApp() claimed it was returning the
nano app instance handle on success, when it actually was just
returning 0 on success.
Bug: 30475803
Change-Id: I436255f0103a743a02f40c41ee4c6f653d007d89
Our logs would show us loading apps twice, when in reality we
load them once, and then update our caches with the app
version later.
There are other issues around how this code works (for example,
b/30970527), but this is an appropriate approach at this
stage of the release.
Bug: 30836667
Change-Id: I2e2a65bc8a2ef4d1703df0a0586a8ed251607af7
When fetching system services early during boot, if the underlying
binder interface hasn't been published yet, we end up caching a
manager class that is broken for the remainder of the process
lifetime, and innocent downstream callers end up using the broken
cached manager.
Fix this by using an explicit exception to quickly abort manager
creation when the underlying binder is missing. The exception is
only used to skip the remainder of the manager creation, and it
doesn't actually crash the process.
Bug: 28634953
Change-Id: I0cb62261e6d6833660704b93a11185aa11a2ac97
On close/abort calls, which are more likely to run in parallel
with CameraDevice APIs.
Bug: 30742426
Change-Id: I6550283d1026373d48bb730164e65b25c7037bab
This fixes a bug where it was possible to authenticate the wrong user.
We now bind the userId when we start authentication and confirm it when
authentication completes.
Fixes bug 30744668
Change-Id: I346d92c301414ed81e11fa9c171584c7ae4341c2
Also, standardize on a set of possible modes for the displays to
enter and separate the configuration of the color mode from the
configuration of the display mode.
Bug: 29044347
Change-Id: I6af0a7d1f11bc72d4cefc380f115c1fb00788864
Add state for loading/unloading nanoApps.
Pass on OS response to ContextHubService clients.
Fix Build Breakage due to uninitalized variables.
Bug: 29193948
Change-Id: Ibebecf704bb3ad2583e110f1fcf05400a53b1b4c
Add state for loading/unloading nanoApps.
Pass on OS response to ContextHubService clients.
Bug: 29193948
Change-Id: I700f3bdbb8e84413455751dec02a812a639421b3
Trusted services may open a camera device on behalf of some client
of theirs; such services need to forward the UID of their client to
the camera service for validation of permissions, etc.
Add a variant of openCamera that makes this simple, only accessible
to unbundled services for now. Only services explicitly trusted
by the camera service can pass an argument other than USE_CALLING_UID
to this method.
Bug: 27616192
Change-Id: Idb06112201b805a8b5c979b5f0761fec1c6994a3
