FingerprintDialog optional fields should not take up space when null
FingerprintDialog error messages should be delayed until dialog is dismissed
Fixes: 75281164
Test: manual test with FingerprintDialog apk
Change-Id: Iaa95fc8c95b7c9f5fc5d8563ea37fc1f6497fabd
* changes:
Camera: Complete transition from handlers to executors
Camera: Camera shouldn't throw 'RejectedExecutionException'
Revert "Revert "Camera: SessionConfiguration should use Executors""
It should be possible for clients to pass executors instead of
handlers in any method that accepts capture result listener.
Bug: 3767382
Test: Camera CTS
Change-Id: I605c001533e93e6294d265fcd4d3d5783c313b8a
The current model for setting up a functionfs
function is:
UsbDeviceManager#setCurrentFunctions() ->
intent is sent to MtpReceiver to write the descriptors ->
init/hal waits for descriptors to write, then pulls up gadget ->
Gadget is configured, a USB_STATE intent starts MtpServer
The main downside of this is a lack of reliability because
the Mtp process could be killed at any point. Normally, a
gadget is unbound if its control endpoint is closed. no_disconnect
works around this, but is still a little janky. In addition, the
extra intent delays the startup of the gadget.
With the new model, UsbDeviceManager writes the descriptors
on initialization. Since it is a system service, it won't be killed.
UsbDeviceManager#setCurrentFunctions() ->
init/hal pulls up gadget ->
Gadget is configured, a USB_STATE intent starts MtpServer
MtpServer calls UsbManager#getControlFd to get a dup of the control
endpoint.
Also modify permissions so system server can access mtp files.
Bug: 72877174
Test: Change usb configurations to ptp/mtp
Change-Id: Id17d2b5930f4e1f37ec1b4f00add9d594174ad49
After Treble's FLP merge into GNSS HAL, the FlpHardwareProvider is just
an empty shell. Removing FusedLocation and/or Flp + Hardware classes
altogether.
Bug: 35726697
Test: m -j
Test: Open Google Map and then walk around. The dot moves as I walk.
Change-Id: I7f413e38b57424e8ebb9d7d14d94f145a48d10f8
These APIs require a system permissions, hence SystemAPI.
As SoundTrigger is now partially SystemApi and partially internal API a
lot of @hide tags are needed to keep hiding the still internal classes,
fields and methods. As SoundTrigger is heavily used via reflection no
structural change to this class can be made.
The MANAGE_SOUND_TRIGGER permission should be visible to the apps as
the apps need to know which permission to request in their manifest.
If it wouldn't be exposed it would just be a magic string.
Test: built
Change-Id: Ic93d67639e2605c26c961acdd827c14cb0a68f47
Bug: 73829108, 71981721
Methods in camera manager that receive and invoke user supplied
callbacks should also be able to accept executors and invoke them
instead of using user handlers.
Bug: 73953366
Test: Camera CTS
Change-Id: I2f22ada463d7debb90beba3e31579cdb4df42506
Getter System API to match existing setter for
the bightness configurations.
Getter System API to read the default brightness
configuration.
Bug: 74105596
Test: atest BrightnessTest
Change-Id: If0a0effad6a4ba6da2e5391dd6bde91dc04bad9c
Executors should be used instead handlers in all camera2
framework code. Remove or refactor any code that still
uses them.
Bug: 73953366
Test: Camera CTS
Change-Id: Ica01d7df5b2e298ea7e11c17fe558bd003072854
This allows camera devices to correct geometric distortion in their
optics, when requested by the application.
The correction only applies to processed (YUV, JPEG, etc) outputs,
not RAW buffers, or the result metadata.
Test: New CTS test passes
Bug: 74434422
Change-Id: I4566713874a152eaed237e823b8d65de4bcab539
LENS_RADIAL_DISTORTION is inconsistently defined: in some places, it
is documented to operate on the range [-1...1], and in others, on a
range dependent on the camera lens's intrinsic calibration and focal
length.
Since fixing just the definition will not fix any existing devices
that define this value, deprecate the old key and add a new consistent
one to make sure applications only reference the consistent
definition.
Test: Adjusted camera CTS passes
Bug: 74641761
Change-Id: Ica7bcd0bc54baa0bdb1d388c4947431556643393
For seamless rotation to work in the brave new world we need the setting
of the display projection to occur in the same transaction as the
reconfiguration of the stack SurfaceControl. To understand this simply see
that the inverse rotation for seamless rotation happens at the
WindowStateAnimator level so if the stack bounds weren't updated to the new
rotation we would clip. This means: We need to use the pending transaction.
We also need to port the rotation animation to use the pending transaction
as it needs to perform transactions at the same time as setting the display
projection. A pleasant consequence is we can eliminate some "inTransaction"
code-paths that always seemed to be a bit of a wart.
Bug: 72038766
Test: Manual. go/wm-smoke.
Change-Id: I949fbe8150d452c1ef5c13e704ddf87269f824f3
In case the camera client registers a valid callback but the
respective handler looper exits a 'RejectedExecutionException'
could be thrown by the 'HandlerExecutor' implementation once it
detects that the 'post' method is failing. This exception is not
mentioned in the current camera API and deviates from the usual
behavior where the post status is ignored. To avoid possible
issues with camera clients a new camera specific handler executor
is used which will also ignore the 'post' method return value.
Bug: 74605221
Test: Camera CTS
Change-Id: I2d947ba9cebfc9b4b2a7c88ace6a4060ff7c175e
