Add calls to SurfaceControl JNI interface that allow
the DisplayManager to drive color histogram functionality.
Fixes: 112756444
Test: Boot
Test: additional test in 'atest FrameworksServicesTests:DisplayManagerServiceTest'
Change-Id: Ifa46dab53b09db62da79ad82e9687d9155ddc6da
* changes:
3/n: For passive modalities, add plumbing for "try again"
2/n: Multi-modal support for BiometricPrompt
1/n: Move BiometricDialog management to BiometricService
When "try again" is showing, authentication is canceled internally.
BiometricService caches the client's info so that authentication can
be restarted when "try again" is pressed. Because authentication
is not running when "try again" is showing, BiometricService also needs
to have a TaskStackListener so that BP can be dismissed and an error can
be sent to the client when the app loses focus.
IBiometricServiceReceiver has been split into two. One for BiometricPrompt
to receive messages from BiometricService, and another for BiometricService
to receive messages from SystemUI/<Biometric>Services.
When we get locked out, don't send the last onAuthenticationFailed
to the client, since "Authentication failed" will be shown briefly
and be replaced by "Device locked out" which is janky
Bug: 111461540
Test: Tested with requireConfirmation enabled/disabled
Test: Tested onConfigurationChange corner cases, e.g. when "try again"
or "confirm" buttons are showing, rotate the device. Buttons
persist correctly and don't appear when unexpected
Test: Tested task stack corner cases, e.g. when "try again" is showing,
press home button. BP dismisses and client receives ERROR_CANCELED
Test: BiometricPromptDemo receives all callbacks
Change-Id: I62126708ce8db8b358c666a07aa7c39607642c9d
DisplayViewport now contains the information about the physical port
that the corresponding display is connected to (for example, HDMI1,
HDMI2, etc).
This information is needed in order to determine which input device is
associated with which display.
Add a new config file to vendor directory that will contain the actual
associations.
Bug: 116239493
Test: atest ConfigurationProcessorTest
Change-Id: I679203747753803e9635a4eaf74287ce7e69dc3f
- Make a better distinction between surface bounds and buffer size by renaming setSize to
setBufferSize and removing setSize for all buffer-less surfaces.
- Adds an error check in SurfaceControl to ensure buffer size is only set for buffer-less surfaces.
- Updates color fade surface to use passed in transaction object.
Bug:114413815
Test: go/wm-smoke
Test: atest FrameworksServicesTests:DimmerTests
Test: atest FrameworksServicesTests:SurfaceAnimatorTest
Change-Id: I88bd1452d6b3b3009e73e26986027d6a5a9efebc
Part 2 of decoupling BiometricDialog lifecycle from AuthenticationClient
lifecycle. This change introduces cookies which are used to keep track
of clients within BiometricService and <Biometric>Services. This allows
1) Much easier support for BiometricPrompt to authenticate using more than
one modality
2) Much easier to support "continue" button on BiometricPrompt for passive
modalities, which should be pressed before authentication continues
Bug: 111461540
Test: BiometricPromptDemo works, error messages are propagated to clients
Test: Keyguard/Settings smoke test
Test: ConfirmDeviceCredentials works
Change-Id: Iaa246488fb027c3397a3191841524b389145b281
The BiometricDialog management was done in AuthenticationClient, but
this is not great for the following reasons
1) The dialog lifecycle should not be 1:1 tied to the client monitor,
since this restricts flexibility
2) Devices with multiple biometrics implemented on BiometricDialog
will require extra work. Moving the dialog management up one layer
should solve this limitation
BiometricService now sends both its own receiver and the client's receiver
to the appropriate <Biometric>Service. When the client is actually started
by the <Biometric>Service, it will forward the client's (BiometricPrompt's)
receiver to BiometricService. Lifecycle management is currently still in
<Biometric>Service since the platform still uses <Biometric>Service
directly. AuthenticationClient for BP is now started with the wrapper
receiver, which allows BiometricService to handle messages before deciding
if it should forward the message to the client.
Moving lifecycle management to BiometricService is currently not a great
idea since framework doesn't always go through BiometricService.
Also merged IBiometricPromptReceiver with IBiometricServiceReceiver
Bug: 111461540
Test: Negative button works (error received by demo app)
Test: Cancelling via back or tapping gray area works (error received
by demo app), and hardware is no longer authenticating
Test: Dismissing BP via negative button or gray area returns only a single
error and is not followed by ERROR_CANCELED (as expected)
Test: Error messages are delayed when BP is showing, not delayed
when BP is not showing (pre-auth check errors e.g. no hardware)
Test: Lockout works
Test: Lockout counter resets upon successful auth
Test: Keys are unlocked properly for both implicit and explicit modes
TODO: Figure out multi-modal BiometricService / <Biometric>Service
synchronization. Likely we keep the bundle in BiometricService
and send random numbers (identifier) to <Biometric>Service. When
each <Biometric>Service is ready, it should return the number. Once
BiometricService receives all identifiers, it can then notify
all <Biometric>Service to start authenticating.
Change-Id: I2b6fa57ed3c3cbccc7b0be30279f80fa46a8e917
Exposes APIs related to new PendingIntent-based APIs of
ContextHubManager, allowing the creation of persistent
ContextHubClients.
Bug: 117612105
Test: Compile only
Change-Id: Iaddbc4685285ffa8186b867def21fbbff370756c
Add any missing annotations to the public interface
as per API guidelines.
Bug: 120072446
Test: Camera CTS
Change-Id: I802635d9caafb0f76377ee094cf605f24288a566
Cts test case: testAbandonRepeatingRequestSurface is
used to test the GPU for the ability of detecting the
interrupt release of surface. It may have a dequeue buffer
action in eglMakeCurrent, so it would return error
"EGL_BAD_NATIVE_WINDOW" after surfaceflinger has been
disconnected. In this case, the test can be passed
only when we catch the errors thrown from GPU when calling
eglMakeCurrent, or the test would be interrupted by
the error exception.
Bug: 72750260
Test: manual, ran the cts test case
android.hardware.camera2.cts.RobustnessTest#testAbandonRepeatingRequestSurface
Change-Id: I79bacdd3c0382a79786f8eb689eb4f89c830ddcc
Camera clients must be able to query and ensure that
a specific "SessionConfiguration" is supported at
camera runtime. The queries must run significantly
faster than creating a capture session and should
be without any SW or HW side effects.
Bug: 111593096
Test: Camera CTS
Change-Id: I49149519164f1e74f2c0539872cc5065cc606ef6
No functional change, just reordering things in internal methods to be
consistent with the API definition. Also fixes stale javadoc.
Bug: 117612105
Test: Compile only
Change-Id: I455d3d5c8f1d5077dbacfa96ad1c71da27559b8e
* changes:
Avoid automatically closing of persistent ContextHubClients
Implements updated PendingIntent APIs
Refactors ContextHubClientManager/Broker classes
Only send messages to CHRE if client is registered
Updates PendingIntent-based service APIs
Previously, we automatically closed the connection when the
resource was GC'd (process died), but for PendingIntent clients
we need to preserve the client endpoint.
Bug: 117612105
Test: Compile only
Change-Id: I6a6cffdeb980073b4ae5ad51c0d91df422e86fc4
Modifies the APIs such that ContextHubClient can be generated by
either the ContextHubClientCallback or the PendingIntent (exclusive or),
for simplicity. ContextHubClients can be regenerated through the
createClient() API, while maintaining the original host endpoint ID.
Also removes the API implementation based on the original design.
Bug: 117612105
Test: Compile only
Change-Id: Ic62aa8695eee3d68722163934de76e77c1f0bc0c
This is analogous to one of the FingerprintManager internal APIs. A
signature permission is required if a user wants to authenticate
using a different userId
Bug: 119296586
Test: BiometricPromptDemo still works for primary and work profile
Change-Id: I16383a588833ccf673d62ed1fc580c412beb4929
- Add new Color Filter Array enum.
- Clarify doc for Bayer pattern related metadata.
- Add DngCreator support for monochrome camera raw.
Test: Camera CTS
Test: Capture a monochrome DNG image and inspect with LightRoom
Bug: 70216652
Change-Id: I329f224e3763dd5c777815a3cbb9dd7bd198c038
- Using DisplaySettings class for storing the display settings.
- Define flags in WindowManager.
- Have direct IWindowManager APIs to set and change display settings at
runtime.
- Mark TODO to original usage of the flags.
- Add test case of DisplaySettings.
- Expose some APIs for CTS usage.
Bug: 114338689
Test: atest DisplayWindowSettingsTests
Test: atest CtsApacheHttpLegacy27ApiSignatureTestCases
Change-Id: I64ed14866d45cd5817fc3c895b6110c79c37b0ad
The flags for the network firewall, screen brightness adjustment, and
data saver are essentially to decide whether to turn on these features
or not, so having them be *_disabled is confusing for someone to read.
These flags differ from others such as animation_disabled or
vibration_disabled, which are actually turning off features instead of
enabling them. I'm updating the internal variable names and adding
documentation to make the behavior clearer. I haven't changed the flag
names themselves since that could make things a little more difficult if
someone wants to set flags later on.
Bug: 117126975
Test: atest com.android.server.power.BatterySaverPolicyTest
Change-Id: If3fa220f9f62117eac39b54bf771a9cc17bcc911
Devices that have no biometric hardware should still get the
BIOMETRIC_ERROR_HW_NOT_PRESENT error. Currently they get the
BIOMETRIC_ERROR_HW_UNAVAILABLE error which is slightly wrong.
Fixes: 119109074
Test: Builds
Change-Id: I32134a35fd2844bc6a4a64ded9695ae596496ef2
