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
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
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
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
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
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
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
Apps from different developers will now receive a different
ID for the same dynamic sensor. Additionally, all apps
will now receive a different/new ID for the same dynamic
sensor after a factory reset.
Bug: 28775590, 29547335
Change-Id: I15b48b974cbb1d53cc33dfdb7b9eb5f1b562190c
- Adds InputManager.setPulseEnabled().
- Adds a config overlay for the file controlling touch-to-pulse.
- Hooks up DreamManagerService with InputManager.setPulseEnabled().
Bug: 29253550
Change-Id: I4892311cc30e97d31f7be778930397fbe5c03945
Existing code assumed that ICameraDeviceCallbacks and
CameraDevice.StateCallback have the same error code values for matching
errors.
They do not.
Also remove duplicate error code definitions now present in the AIDL
file for ICameraDeviceCallbacks.
Bug: 29248704
Change-Id: I069e2b7ef3be7887634e128f1accb50b7558f3fd
Multiple CameraMetadataNative objects could be reading and writing
to the metadata marshaler registry simultaneously.
This can lead to an infinite loop in the HashMap in the worst case,
so add synchronization against this.
Bug: 29043079
Change-Id: Ic5e9e58a9333b99b4bea87bf790c9fbfadfbbea9
Allow surfaces to be deferred during session creation. Once the surfaces are ready,
the application can finish the deferred output configuration to be able to submit
requests with these surface targets.
Bug: 28323863
Change-Id: Id6634c3ef2ecc84422a88f63de0a19a0cb496e96
Revert added language about shading map being the full flat-field
correction; it's actually the same correction as applied to camera
device-processed data.
Also fix a few other wording issues in the lens shading documentation.
Bug: 18175853
Change-Id: I27691925e6496afe18f3506084d89f2523b5555d
am: c396f0f70e
* commit 'c396f0f70ef40ea0fb42a0872a13f4c4e9a6a5f0':
DO NOT MERGE Remove Pointer Capture API
Change-Id: I77cb742feacdd3b8af0cf33d4e7ab246f776417f
Adding a hidden API in UsbManager for system services to grant
permissions to a specific package for a USB device without showing a
user dialog.
Bug: 28760255
Change-Id: Ie68cfc784b7894e9db12ab61bab0f7e6bfa369e3
Since LocaleList needs to depend on android.os.Parcelable, we cannot let
that class belong to "android.util" package, which causes layering
violation.
Bug: 28819696
Change-Id: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
The underlying implementation needs to be completely rethought. If a
process crashed while you were in pointer capture mode, you were
pretty much stuck in it. If the mouse happened to move outside of
your bounds right before you called the API, you'd never actually get
an event (whatever it was hovering over would). There's no easy way
for the system to tell you when you enter or exit this mode because
it doesn't actually track who the current request is from.
These are all solvable, but not in the N time frame. Maybe next time.
Bug: 26830970
Change-Id: I03efd63c499b86dc278491ca3284566c1965581f
If there are no enrollment applications on the system, but someone still
makes a KeyphraseEnrollmentInfo and tries to print it, it would generate
a NPE on a map object. Instead of setting the map to null when we don't
find any enrollment applications, we can just set it to an empty map.
Bug:28622866
Change-Id: I023e6fd90effd3143c19817a0d6637a013bebc31
- Ensure that app to host events are not filtered out
- Populates the app handle appropriately for clients to reference the
nano app sending the event
Bug: 28273520
Bug: 28272149
Change-Id: I7373fc84abcadc2ab17109484f2d04b02a474593
Given recent reversal of "roll" definition (positive angles now
represent counter-clockwise rotation), updated the description for
this and the other orientation angles. Also updated explanatory text
and code samples within the "Position Sensors" page to reflect the
recent deprecation of STRING_TYPE_ORIENTATION.
Bug: 23822069
Change-Id: I083a55011ea41c4a6533b78ee38a32479310f4cf
