This interface can be used to listen for addition, removal, or
modification of DisplayGroups.
Bug: 138328918
Test: make
Change-Id: I3a2f39838ab00808816366d2484190b401aabed0
There are two categories of color modes: the standard color modes, which
are defined and implemented in AOSP, and a reserved range of vendor color
modes, which are defined and implemented by the vendor. Currently, there
is no way to distinguish between two vendor's color modes that use the
same value within the reserved range. This will allow OEMs to specify a
hint as to which vendor's color mode definitions were used on the
original device. If the hint from the restored device matches the hint
on the new device, the color mode from the restored device can still be
considered valid for the new device if it is within the vendor reserved
range. If it does not match, the restored device's color mode value is
invalid on the new device, and must be replaced by the default on the
new device.
Bug: 167449433
Test: builds
Change-Id: Ie5ac0a2d783e1ea703e0342f5cdb41dca07d04d4
For TV panel and source devices.
Bug: 169121289
Test: atest HdmiCecLocalDevicePlaybackTest and HdmiCecLocalDeviceTvTest
Change-Id: I6e870a35bcaf55153eaa2274c9f2d8b8f7bf1dda
* changes:
[CEC Configuration] Fix race condition with listeners
[2.0] Disable sending <User Control Pressed> in attempts to change the active source to a 2.0 device
[CEC Configuration] Add 'tv_wake_on_one_touch_play' option
Add the necessary APIs that will allow Camera2 clients to access
and work with existing CameraX extensions.
Bug: 170481080
Test: Camera CTS
Change-Id: Iaa22fea69ebe01599b3f2e66c1b46ca92015cdc5
This ports the Settings.Global.HDMI_CONTROL_AUTO_WAKEUP_ENABLED to
HdmiCecConfig.
Bug: 166433775
Test: atest HdmiCecLocalDeviceTvTest
Change-Id: I63c7cf35b9769da193e950f362f51a0f79898a5f
1) Adds biometrics.proto definition for BaseClientMonitor subtypes
2) Adds BiometricScheduler proto dump
When dumping the scheduler, the caller may request for the recent
operation queue to be cleared after dumping or not.
Note that we don't need BiometricScheduler.Operation#STATE_*
in the dump, since (for now) we just want to know what operations
have been run.
We can always add additional state, success/failure, etc in the
future if needed.
Bug: 159667191
Test: atest com.android.server.biometrics
Test: atest CtsBiometricsTestCases
Change-Id: I7d2350f00aaeef03ab7d74013b476af053240320
This CL changes the behavior of PM#goToSleep to instead turn off the
power for the default display group. PM#wakeUp turns on the default
display group.
If all display groups are turned off, the device will go to sleep. If
any display group is on, the device will remain interactive.
This results in no behavior change if there is a single display group.
However if there are multiple display groups then it will be possible to
interact with ones that are on while others are off.
Bug: 138328918
Bug: 170935083
Bug: 175919649
Test: atest PowerManagerServiceTest
Change-Id: I8b475c38886eda3e43d6e8da7e68102a25da1584
Sometimes we want to show a dialog, sometimes a notification, sometimes
nothing.
- Also some minor UI tuning to match mocks.
- Also suppress dialog while dialog is visible and shortly after. This
avoids a dialog directly after closing previous dialog.
Test: Triggered dialog. Needs exhaustive test of all
cases though.
Bug: 162549680
Change-Id: I52ccd22858969823d8670a9e345d3da994ec1c19
Read value whether HDMI CEC is enabled from HdmiCecConfig and cache it
in HdmiControlService. This changes the type from boolean to int.
Adapt the @hide listener for a change of this value to return integers
instead of booleans as well.
Bug: 171870477
Test: atest com.android.server.hdmi
Change-Id: I6275fe1b3e1ca62c210019e1df216f8731a0b5ab
Migrate HdmiControlManager#(get|is)HdmiCecVolumeControlEnabled to use
the new HdmiCecConfig.
This config is backed by an integer, the volume control enabled states
are migrated from boolean values to a new IntDef. Listeners also return
these integer values.
Bug: 172819080
Test: atest com.android.server.hdmi
Change-Id: I0e1fb46886f89f143bb830494ab23602301e3d8e
For each camera session, collect capture latency histogram for all streams.
Test: Camera CTS, and observe statsd output
Bug: 154159000
Change-Id: I7741371ca8540cdf9c9a47246c0ef0f0f82df32a
Enables SysUI to draw enroll/auth-specific affordances
If the UI diverges, we can consider enroll or auth specific
UdfpsView subclasses(?) but currently enrollment just shows
an extra circle.
Fixes: 177275693
Test: atest com.android.systemui.biometrics
Change-Id: I5b2aaf00c55279a81348ec7a5dc387b6e62751c0
The only public API (that I know!) that let touches pass-through is
FLAG_NOT_TOUCHABLE, so I've put the rules that relate to app-developers
there.
Please let me know if there are any other public APIs that makes a
window let touches pass-through. The other one I know of is
ViewTreeObserver.addOnComputeInternalInsetsListener() that let's you
specify the touchableRegion, but that's not public.
(The feature works regardless of the API used to make the window
pass-through)
The docs are a shorter version of the "Rules" section of
go/untrusted-touches.
Bug: 158002302
Fix: 173022596
Test: Build
Change-Id: Ic7ba68f03587112db2cc93128ac41cb09d443127
Test: Manually add a listener in another serviec and change state with
`adb shell cmd sensor_privacy enable 0 microphone`.
Bug: 162549680
Change-Id: I4a77bc2bba4405b2ba962e767005ca443a2d732f
For the spaceship mode this is purely an internal refactorization since
all the apis remain the same and the state is kept in sync across users.
For the individual controls there's new calls to set the state of the
toggle per user or per profile group.
Test: Manually change state with `adb shell cmd sensor_privacy enable 0
microphone`
Manually upgrade from old persistence to new persistence form
Manually check that the persisted state remains when rebooted.
Bug: 162549680
Change-Id: I0a5eac7a5c3beb272a456790d999a0282d77bf09
Test: Verified regular fingerprint enrollment correctly logged
enrollment.
Test: Verified that the find fingerprint sensor activity no longer
falsely reports a failed enrollment.
Bug: 175316123
Fingerprint enrollment shows a find sensor screen which makes a call to
FingerprintManager.enroll(), the purpose is to get the user to locate
the sensor. The consequence was that logging built into the framework
was incorrectly logging a failed enrollment after cancellation.
Change-Id: I2ec27120943e1ce3d70f5ca2f3221a4b3b571c39
