- Update documentation for new arbitration behavior.
- Ensure an appropriate error is thrown when calling
open while an existing, higher-priority user holds
the camera device.
Bug: 19186859
Change-Id: I486193c14b7fd5dc6ce30c1b7471669c009d64b3
FingerprintManager internally creates a Handler which needs to be
bound to a Looper thread. Prior to this CL the Handler was bound to
the Looper of the current thread. This caused issues:
* Different instances of FingerprintManager could be bound to
different Looper threads.
* Callbacks from FingerprintManager were invoked on arbitrary
threads (or not at all if the Looper was there but wasn't running).
* FingerprintManager couldn't be obtained by apps on most non-main
threads leading to java.lang.RuntimeException: Can't create handler
inside thread that has not called Looper.prepare().
This CL fixes the issue by binding the FingerprintManager's Handler to
the Looper running on the main thread.
Bug: 20725228
Change-Id: I4a0382d6e11df9f23b8db9f0deec77369af31b5e
Write samples of the old and new state to the binary event log whenever
the user modifies the auto-brightness adjustment. We wait a few seconds
before logging to ensure that the user is satisfied with the adjustment.
Bug: 19786916
Change-Id: I41402decd1034d0839aa0f47495bc00907ab9c08
- Works around HAL issues where preview must be
explicitely stopped after takePicture call before
the surface can be reset.
Bug: 20553124
Change-Id: I403d8c09dfee0cd192d4831376f9f8ed3d6ba444
Add a session ID to CaptureResult to indicate the session where
the result comes from. When creating a reprocess capture request
with a capture result, the session ID will be carried over to
the reprocess capture request. Reprocess capture request's session
ID will be used to validate that it matches the session ID when
submitting the reprocess capture request to a session.
Bug: 20263212
Change-Id: I024c1a28ecf0a43909a0ed3814a11360c318417f
The DisplayEventReceiver and SensorManager event queue both get
leaked when the Looper thread they are attached to dies because
the Java object holds a strong reference to its native peer and
meanwhile the native peer holds a strong reference to the Java
object through JNI.
Fixed the issue by indirecting through a weak reference as was
done for InputEventReceiver some time ago.
Bug: 12455729
Change-Id: I3d80a2a190192d1a2981bf5ae0cad30f0f7688a5
- Define DEPTH_OUTPUT capability and its requirements.
- Add DEPTH_IS_EXCLUSIVE to support devices that cannot produce color and depth
for the same capture.
Change-Id: I6e511b7b8625907d9fc751fe8a73a443edeeb2ab
For camera devices that support very high resolutions, add
a level that allows for those resolutions to operate at lower
capture rates, while ensuring that a reasonable resolution is
still available for high-rate capture.
Change-Id: I4a0d904504ac8a976bd02fba89b238048d55a268
- Make isHardwareAvailable public
- Add hasEnrolledFingerprints so apps can check whether to show
fingerprint UI or not.
Change-Id: Iaefd5e9e68bf3bee8305574dc1477ea9bc72b30a
Normally, buffers for camera output Surfaces are allocated as
needed. This minimizes memory overhead and time to first frame.
However, if allocation takes a long time, as it can do for full-resolution
output buffers, full frame rate may not be maintainable with the added
allocation overhead.
The prepare() method allows an application to indicate that buffers for
a given output Surface should be preallocated by the camera device.
Once the allocation is complete, the onSurfacePrepared callback is invoked.
The application may then use the prepared Surface without concerns about
allocation-caused delays.
Change-Id: I4f616dc87dd4346f408cf1ea37d48a642ceb57da
New FLP HAL implementations will explicitly return their capabilities,
but old versions won't (the implicit capability in old versions was
GNNS). Ensure that the getCapabilities feature of GeofenceHardware
will return GNNS for old binaries, so GmsCore doesn't have to worry
about versioning.
Change-Id: I4b1c942b0d68d87bfbb18b8c06fd9d8b8f68efa6
Retain compatibility with implementations compiled
against old headers or left unchanged from LMP.
Change-Id: I3f7cfaaf0cba8697c312940a805b053c6040caa6
Currently GmsCore has to guess how many locations to retrieve
based on requested frequency and then demux the output looking
for timestamps (that aren't monotonically increasing). This
capability gives GmsCore a more graceful solution.
Change-Id: Ie1d71615f699bc0d3c63f8b80aa7b40b9971cf96
Add reprocess API and implementation to support creating reprocess
capture sessions, reprocess requests, and receiving reprocess capture
results.
Change-Id: I4c1c02f41d1712f65e729ea3ba09592a27ffe86d