Previously, getAuthenticatorId() simply returns the authenticator id
corresponding to the currently active user in FingerprintService.
However, this can cause bugs when, for example, KeyStore calls the
method before storing a fingerprint-bound key for a non-current user. In
such cases, the authenticator id of the calling user is desired, which
is not necessarily the same as the "current user" in FingerprintService.
This CL ensures the FingerprintService always returns the authenticator
id of the calling user.
Bug: 33459191
Test: manual
Change-Id: Ia9d6b869d16bd37f45358ba839cd12901ebc1076
Merged-In: I35c5a3a7082cffb8941eeaa219c8e20948ad41a9
add equals judgement for cts case: android.hardware.camera2.cts.CaptureRequestTest -m testSceneModes
scene-mode (auto) is not single string in some platform, the source is from getCameraCharacteristics
which contains multiple characters. so previous code == is not correct.
Test: make
Test: run android.hardware.camera2.cts.CaptureRequestTest -m testSceneModes
Change-Id: Ie5ffeeebd0d0c237c80768a4a8217bc04e52a173
Bug: 31602449
Test: verified adaptive brightness no longer varies with twilight with
"brightness_use_twilight" set to "1".
Merged-In: I6b5f7310020b2128c2b292414a205b6052270a0a
Change-Id: Ife9bf6d0f76df791cb7e6a22505d9f551da19731
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.
Bug: 31814300
Test: manually changing usb configurations
Change-Id: Ica10a195338b2189db13113f44657393db110bee
(cherry picked from commit 7a396be6d5)
This change saves and loads a different brightness setting when the user
goes in and out of VR Mode.
Bug: 30984614
Change-Id: If3c3e81b592e0c6fd037e5783559683e5cb58379
Change the name used by the contexthub service. Specifically, this
change switches from using the "ContexthubService.CONTEXTHUB_SERVICE"
constant to using the "Context.CONTEXTHUB_SERVICE" constant- which is in
line with the other Android services.
Merged-In: I18ae73ed0fda2f938e3233670dc52b5692d321ae
Test: GTS tests pass.
Change-Id: I18ae73ed0fda2f938e3233670dc52b5692d321ae
This change saves and loads a different brightness setting when the user
goes in and out of VR Mode.
Bug: 30984614
Merged-In: Ie5578bbd6ea346f0eb34fe4abbfd604a5d7c0c93
Change-Id: Ie5578bbd6ea346f0eb34fe4abbfd604a5d7c0c93
Functionfs requires MtpServer to write descriptors before the device can be
configured. This adds a new configure call that will occur only when
functions are changed (new argument added to updateUsbStateBroadcast for this)
and be called after sys.usb.config is changed but before the waitForState
call to ensure compatibility with configfs devices.
Bug: 30976142
Change-Id: I7e94a5847d3b19c0fd75139e1b15a3f2a1cea01d
Test: Manual
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
(cherry picked from commit 7a396be6d5)
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
This CL makes the default TYPE_DYNAMIC_SENSOR_META sensor a wake-up
type.
Test: m cts-verifier
Test: Run "Dynamic Sensor Discovery Test" with a sensor HAL that
support dynamic sensor discovery (e.g. contexthub + ag/1189124)
Bug: 31068976
Change-Id: I2e6320b1e1e34a8c22677be3e6e318c149e1bb26
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
