Test: manual.
Set up work profile and open an app that's only installed
there. This should change the user ID without triggering a
system-wide global switch, in which case the application info
would be null and cause the system service to crash.
In the current implementation, this shouldn't happen, and in
fact the foreground app should be properly inferred regardless
of the user. This can be visible by enabled and checking the
AutomaticBrightnessController logs with:
adb shell cmd display ab-logging-enable
adb logcat | grep AutomaticBrightnessController
Fixes: 122107873
Change-Id: I8161414a766c494ab0efadaa20fe6fcdf5067948
For display white balance and grayscale
Bug: 111215474
Test: atest FrameworksServicesTest:ColorDisplayServiceTest
Change-Id: I5c7b6543665e520b4e167ac8e6719f337018f172
This is needed by making the setup wizard use only system-api.
Test: Built, switched USB port state
Change-Id: I8e56859a5b36e7de91691522a34f7d6f62dcbb20
Fixes: 115301401
Smart screen brightness learns the user brightness preferences from
user interactions with the brightness slider, but doesn't take into
account the foreground app's package name or category.
This CL adds:
- A BrightnessCorrection class,
- A mapping of package names and categories to brightness corrections
in the BrightnessConfiguration,
- Tracking of the foreground app's package name and category in the
AutomaticBrightnessController,
- Brightness correction depending on the foreground app's package
name and category in the BrightnessMappingStrategy.
Test: manual - force turbo app to learn brightness preferences for
specific packages/categories and see that they are applied.
To make sure package/category switches are handled correctly,
you can actually hardcode corrections and simulate edge cases
such as rapid switches, multiple windows, etc.
Fixes: 111425369
Change-Id: Ic9516c75dbf63ea21f0ae780f9c35e8c85dbbe5b
Initial prototype disabling location/sensors and enabling airplane mode.
Camera/Mic will come in a followup.
Test: manual
Bug: 110842805
Change-Id: I26132fcc9ffea83e3e78a0e54882d23c99ee590c
Mandatory reprocessable stream combinations must include
at least one input stream and one ZSL output with the same
format and size.
Bug: 111593096
Test: Camera CTS
Change-Id: I4bdfb8b540ccce583b01ea200d8c7e252dd72b12
Generate static mandatory stream combinations according
to the camera device capabilities.
Bug: 111593096
Test: Camera CTS
Change-Id: I18014575090baa61785f213afded46a857928bc8
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
