VR Virtual display was getting letterboxing for apps that
had a fixed orientation in the manifest.
Bug: 62670868
Test: Run orientation locked app, observe requested orientation in VR
testCreateVirtualDisplayRotatesWithContent to verify propagation.
Change-Id: I10eb4f6e54404aa7b66471ab5dc929a4baa49432
Came of bunch of bugs, for instance b/62912250 where some app is
forcing the port role. Logging which package is doing this
Change-Id: I234db3292326d247c82723989b46160fcbd59c10
Use CameraDeviceImpl#mInterfaceLock for all device/session locking
Test: CTS/stress testing camera open/close
Bug: 62767980
Change-Id: I4e57e9e1d4548c3f9ae85799b742bebed9a0e451
User tag is not part of native metadata, and need carry over explicitly.
Test: Camera CTS
Bug: 33761753
Change-Id: Ic58783fc204ce71e073f71d0fa50d4d961f4e7ce
Retrieving list of methods in every invoke() call is very expensive.
Caching the list inside the constructor prevents several unnecessary
calls to Class.getMethods().
Test: Run camera2 CTS
Bug: 62490715
Change-Id: Ib2a93af0f364b055df2eab9bd7870730428429ad
We've seen some @SystemApi methods protected with non-system
permissions, so give Doclava the platform AndroidManifest.xml so it
can parse the actual permission protection levels to look for APIs
that are letting in non-system apps.
Also document more @SystemApi permissions.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api
Bug: 62263906
Change-Id: Ie0f0a5fb0033817bcc95060f2183a52ae4ae7b06
Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.
Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
Bug: 38509779
Bug: 32295793
Setting to null causes problem seen in b/38509779
Using weakreference will cause problems if the application
declares AuthenticationClient as a weak reference as well and would
very likely break a lot of existing apps.
Test: manual
Change-Id: Iedbdd76f3a402b766ce8a799bf76324d1164a0ec
Turns out this never worked. 😱
- Add missing oncaptureBufferLost proxy method
- To avoid this issue in the future, change CameraDeviceImpl.CaptureCallback to be
an interface instead of an abstract class; now all implementers _must_ implement
all the methods
- For the short-circuit local callback when no callback is provided by the user,
implement all no-ops explicitly.
Test: Camera CTS continues to pass; manual testing with injected buffer drops
Bug: 62004599
Change-Id: I7732903dbc00e80084162e067de66b5db6cee74c
The onRemoved() callback from fingerprint daemon provides a "remaining"
parameter which contains the number of fingerprint templates yet to be
removed in the current removal operation. This is especially useful when
a group is removed, as remaining == 0 indicates the end of the group
removal.
In this CL, we wire up FingerprintManager so that the "remaining"
parameter gets passed to RemovalCallback#onRemovalSucceeded(). This
would allow clients like Settings to make use of the information.
Bug: 37938345
Test: manual, both with and without work profile
Change-Id: Idf46ef42e1d178cd3dc267aaf4219f03e27be766
Fingerprint currently locks out for 30s after every 5 failed attempts.
This change makes it so that in addition to the above,
PIN/pattern/password will be required after 20 failed attempts.
Fixes: 35954316
Test: manual
Change-Id: I3aeb0e5b5b4d5011555f60fbe6cc2c1ce702a670
This CL adds:
1) Adds uniqueId (protected via system/sig permission) to virtual
displays.
2) Add support for N virtual display viewports into inputflinger.
3) Set the virtual display's viewports in inputflinger if it has the
uniqueId value set to non-null. (a) Moving the new viewport from java to
native inputflinger and (b) adding "uniqueId" value to viewports makes
up the great majority of this change.
4) From the inputflinger side, we also read in a new value from the
input device configuration files called 'touch.displayId'.
5) When touch.displayId and the virtual display's uniqueId match,
inputflinger links the two.
Test: Start VR and ensure that the virtual viewport shows up when running
'adb shell dump input". Run a VR app, and ensure that the virtual input
device is associated with the new virtual viewport.
Test: com.android.server.display.DisplayManagerServiceTest
Bug: 36051620
Change-Id: Ic2117eb8e19f7f3c59687160591f8bc6692c1f12
Merged-In: Ic2117eb8e19f7f3c59687160591f8bc6692c1f12
Fixes: 38197608
Test: 1) enroll a finger
2) enter keyguard, touch sensor with an unenrolled finger
3) touch sensor with enrolled finger
4) phone should enter keyguard
5) do this test from screen off as well
Change-Id: I1c7b060888128b4a6b492fd6a7a8ebc85d2b3353
This CL adds :
1) Adds uniqueId (protected via system/sig permission) to virtual
displays.
2) Add support for N virtual display viewports into inputflinger.
3) Set the virtual display's viewports in inputflinger if it has the
uniqueId value set to non-null. (a) Moving the new viewport from java to
native inputflinger and (b) adding "uniqueId" value to viewports makes
up the great majority of this change.
4) From the inputflinger side, we also read in a new value from the
input device configuration files called 'touch.displayId'.
5) When touch.displayId and the virtual display's uniqueId match,
inputflinger links the two.
Test: Start VR and ensure that the virtual viewport shows up when running
'adb shell dump input". Run a VR app, and ensure that the virtual input
device is associated with the new virtual viewport.
Test: com.android.server.display.DisplayManagerServiceTest
Bug: 36051620
Change-Id: Id728d6e7292feaa1d8de7660bc6a2ec90fa1ff3c
This CL adds:
1) Adds uniqueId (protected via system/sig permission) to virtual
displays.
2) Add support for N virtual display viewports into inputflinger.
3) Set the virtual display's viewports in inputflinger if it has the
uniqueId value set to non-null. (a) Moving the new viewport from java to
native inputflinger and (b) adding "uniqueId" value to viewports makes
up the great majority of this change.
4) From the inputflinger side, we also read in a new value from the
input device configuration files called 'touch.displayId'.
5) When touch.displayId and the virtual display's uniqueId match,
inputflinger links the two.
Test: Start VR and ensure that the virtual viewport shows up when running
'adb shell dump input". Run a VR app, and ensure that the virtual input
device is associated with the new virtual viewport.
Test: com.android.server.display.DisplayManagerServiceTest
Bug: 36051620
Change-Id: Ic2117eb8e19f7f3c59687160591f8bc6692c1f12
Activity contexts include override configurations in their resources
associated with the primary display. There currently is no way to
specify overrides for another display from the same context. As a
result, getting metrics for other displays will reflect the metrics
of the context's display.
This change provides the application context when we create a display
if the display id does not match the display associated with the
context.
Change-Id: I68a7b609ead6d7cc652d36e7e8af432700af8efa
Fixes:37923030
Test: cts-tradefed run cts-dev --module CtsDisplayTestCases --test android.display.cts.DisplayTest#testActivityContextGetMetrics
