ag/5398143
We exposed Power on/Power off/Device select/Connected device list
query from HdmiControlManager.
Test: local tested
Bug: 117775357
Change-Id: Iee495e7131f44282a60e83ad827faa1431a30389
* changes:
Adding HDMI_CEC_SWITCH_ENABLE Global property to enable/disable Routing Control feature.
Fix spelling errors in HdmiCecMessage.toString
More skeleton code for <RequestShortAuidoDescriptor>
Add a getPhysicalAddress api to hdmicontrolservice.
Set System Audio Mode on when switch to Audio Only source
Call HdmiCecLocalDeviceAudioSystem to report audio status.
Add a delay state into DeviceDiscoveryAction.
ag/5309322
This is helpful when other services need physical address to get the
index of the port according to the physical address reported from the
device connected(not necessarily directly) to the current device.
Test: local tested.
Change-Id: I224a16166e4dabccf81dc34eb479e469c29ac3a0
* changes:
Add launchDeviceDiscovery when devices just plugged into the current device or the current device just conneted to a TV.
Fix pathToPort logic in HdmiControlService
Update the power status of an existing hdmi device with TIF once receive Report Power Status or Active Source from the existing device.
Add HDMI device info into TIF once receive report Physical Address or Set Osd Name from a new device.
Change the pathToPort(int path) method in HdmiControlService to apply to not only TV device.
Modify on hotPlug logic for Audio devices
Add array and add/remove methods to track connected device info
Modify doManualPortSwitching logic in Audio System
Add HdmiSwitchClient and move isSwitch property to system ro property
Wake up device when device is in dozing but CEC power status is on.
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
VirtualDisplays are considered on if they have a surface and off if they don't.
This causes problems for displays that don't have a surface. Instead,
create a separate API to allow the client to request the surface be on
or off.
To ensure backwards compatibility for VirtualDisplays, set the display
to on or off when the surface is added or removed.
Change-Id: If9d8db94a66d6484ac492a53c1cd8fb7da851b88
Fixes: 119209373
Test: Created surfaceless virtual display that can be manually turned on or off
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
