Adds an observer to HighBrightnessModeController to monitor the system's
thermal status and ensure HBM is off if the status is above the new
limit defined in the display-device-config file.
Also fixes a bug where AutomaticBrightnessController does not
automatically recalculate a value when HBM mode changes and the ambient
lux does not.
Bug: 179019497
Test: atest HighBrightnessModeControllerTest
Change-Id: I38a805671cee0f63e858b7ec0b6a45ca43df1737
Defines refresh-rate limits for high-brightness-mode in display-config
xml files. DisplayModeDirector listens to HBM status changes from
DisplayManager and applies the pre-defined refresh-rate limits when HBM
is enabled.
Test: Manual, verify a Refresh Rate vote when HBM is enabled, and a
null-vote when disabled.
Test: atest com.android.server.display
Bug: 181955334
Change-Id: Id642cbff96fca9ce79a50d6cd97e75cd6061ac74
Some sensors can limit the range of supported refresh rate when
enabled. This change adds a way to specify that limit withing the
display device config file.
Bug: 175793106
Test: Verify that when sensor is enabled, there is an additional
refresh rate vote for the rate specified in config file.
Test: atest DisplayModeDirectorTest, LocalDisplayAdapterTest
Change-Id: Id210c25fe56cd5353a2436b9b97f2ad01980e465
This change affects the proximity sensor used for phonecalls, for example, but not for aod.
Bug: 178385123
Test: manual
Change-Id: Id5333e6110ddb8ddfbfd4f720d14f26288bb1594
Add a field in display device configurations that allows sensors to be stored.
Read the sensor type and name through dpc.
Bug: 128782163
Test: manual
Change-Id: I4cd778fca085b398b21457104a6a58ad0dae46e2
Adds the ability to specify an XML configuration file to determine
how displays are laid out for specific device states.
Bug: 168208162
Bug: 170498827
Test: atest com.android.server.display
Change-Id: I488367ecca7a36e667b10a3b70eca3647d40455c
With this change, callers can set overrides for specific versions of an
app. The framework falls back to default version when the given version
doesn't have an override set.
Bug: 174043039
Test: atest FrameworksServicesTests:CompatConfigTest
Test: atest FrameworksServicesTests:PlatformCompatTest
Test: atest PlatformCompatGating
Change-Id: Ib5ff67e752a9c5ee94b6e1dd664d324ab5bf4542
Save the compat overrides in /data/misc/appcompat/compat_framework_overrides.xml
Test: atest CompatConfigTest
Bug: 145509340
Change-Id: I0673087c1b78addb20b03ba6299490c2d40e39ca
Allow brightness ramp speeds to differ based on whether the brightness is increasing or decreasing.
They already allow fast / slow ramp rates.
If all 4 values (fast up; fast down; slow up; slow down) are put in the DDC, these are used.
Otherwise, config.xml provides one value for fast and one for slow ramp rates, these are used for both increasing and decreasing values.
Bug: 156247142
Test: manual
Change-Id: If0920328e2bf16e3f8ebe6ea1b07a467e5c4e939
1) Loads configuration values from the display device config file
2) Passes those values through to AutomaticBrightnessController
3) Uses configuration in new HighBrightnessModeController class
to drive High Brightness mode via AutomaticBrightnessController.
Test: manual. Set HBM to enabled in display-config file.
Bug: 168210138
Change-Id: I4824bbc9d97cb668efc3bcaddb036d508a40fa87
With this CL the annotation is only digested, but has no behaviour
change yet. Eventually this annotation allows the annotated change id to
be overriden on non-debug builds
Bug: 174043039
Test: atest FrameworksServicesTests:PlatformCompatTest
Change-Id: Ibc1fce37085213b5a02155010189949e193f0882
This change adds the default brightness to the ddc, and a fallback to
config.xml when the ddc doesn't exist.
It adds the minimum and maximum brightness constrtaints to the display
device config - which are currently sourced from config.xml.
Bug: 147415200
Test: manual
Change-Id: Ibbfbbbd495048114befb3f867bd5f4e26916ca9e
On some devices, the system may not operate as expected and
specialized code may be necessary to work around these limitations
or "quirks". Add the notion of quirks to the config files so that
devices can be easily configured to operate around their
unexpected behavior.
As a first "quirk" to add, we specify if a display supports setting
brightness via the SourceControl.setBrighntess API.
Bug: 170954431
Test: manually check that brightness works
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/display
Change-Id: Ia3cedf9ec7a2457e27763e0c58020c1edfbae408
This adds nullable annotations to tags that can be null at runtime.
Fixes: 175130179
Test: Manual - view generated java API
Change-Id: If9d032a5eff452ddbaa28050b474051fd66db424
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
This converts the sensor type within the device state config file from
a raw int type to its fully qualified Sensor string type. For ex, a hinge
sensor that was previously identified with "36" would now be identified
with "android.sensor.hinge_angle".
Bug: 159401801
Test: atest DeviceStateProviderImplTest
Change-Id: I32ff9db11f68d602f7084d5308f0435bf418e522
This change adds support for toggling device states based on sensor
values. For ex, a device with a hinge angle sensor can specify device
states based on the current hinge angle.
Test: atest DeviceStateProviderImplTest
Test: manual - place config on device and verify device state changes
with hinge angle sensor
Bug: 159401800
Change-Id: I41372c252fdc4c9d4f0306283cf260f793271195
This change introduces the device_state_configuration.xml file schema
and updates DeviceStateProviderImpl to read the set of supported states
from the configuration file. The file schema and provider only support
the lid switch condition, support for hinge angle will be added in a
follow-up change.
Test: atest DeviceStateProviderImplTest
Test: manual - place config on device and verify device state changes
with lid switch
Bug: 159401800
Change-Id: I4472e23a5c8dbdacfe56aa2570eafa84033a7bfd
Change type of 'hdmi_cec_enabled' and 'system_audio_mode_muting' to integer.
Bug: 168020131
Test: atest HdmiCecConfig
Change-Id: Idc7056fbb7ff01459106bd292553f1ad2f0c4154
The schema will be used for system and OEM level configuration of CEC.
Bug: 166430550
Test: Ran 'make update-api' and inspected the current.txt
Change-Id: I2359a4957e2d8f99818b8c53c3914794a0b4fa85
Bug: 151896491
Test: presubmit check
Exempt-From-Owner-Approval: This CL renames suite name vts-core to vts.
It won't change test logic or behavior.
Change-Id: I79cddf5e4a65486b8f1286ea430360479ad2b93d
Code was previously a no-op, no changes to behavior.
Bug: 152319241
Test: Manual, make sure brightness still works.
Change-Id: I0c9ee872a0c07ffe7a407f21c419f468faae1003
Throw an exception if someone tries to add an
override for a logging only change. Incorporate the restriction in the
OverrideValidator.
Test: change one change to be logging only, flash device, adb shell
dumpsys platform_compat
Test: atest com.android.server.compat.CompatConfigTest
Test: atest com.android.server.compat.OverrideValidatorImplTest
Bug: 148009004
Change-Id: I379c63f8b5c54500d9066be9363a186efd55d200
VtsValidateDefaultPermissions is just the GTest of
vts_defaultPermissions_validate_test.
Bug: 142397658
Test: $atest vts_defaultPermissions_validate_test
Change-Id: I88de9b3b01957f3d76591f33b362bdedbf36acd2
Within the device-configuration file, a device can specify a
point along the brightness mapping as the beginning of high-brightness
mode. All points in the mapping beyond that range will be treated
as high-brightness-mode points. Normal brightness range will end
at the specified point.
Bug: 131813802
Test: Verify brightness works through the entire pre-HBM range, with and
without new specifier.
Change-Id: I4d9c6fab1c1f11e550ee33643673b004ee54dbfe
Adds a static display configuration file for specifying static display
configurations as a sustainable API.
Bug: 131813802
Test: Verify brightness changes work as expected. Verify changes going
through system to HAL conversion.
Exempt-From-Owner-Approval: I am new owner of lights, but OWNERS rights hasnt yet propogated.
Change-Id: I17922267f4695bc042d7c0687d4dcc10554e1b85
Capture the comment above a definition of a compat change and make it
the description.
Next: make sure existing changes use supported format (only /**
comments, only above the annotations), and use in developer UI.
Bug: 144927670
Test: atest com.android.server.compat.CompatConfigTest
Change-Id: Ib23f341baa171599654c351693e4b0ddf4b2515c
As decribed in go/xsdc-for-partners.
This defines the schema of the XML file generated by @ChangeId
annotation processor.
The schema requires unique ids.
Test: Used https://www.freeformatter.com/xml-validator-xsd.html to
validate an example config.
Bug: 138222363
Change-Id: Iaf37e049ddd483c4fd7d512475614476ac6606a5
On some devices, default-permissions.xml file is on the product
partition. Modify the test case so that VTS passes even if
default-permissions.xml doesn't exist.
According to the parser code, the xml file can exist in an odm
partition. So add the odm partition to the location.
Bug: 132048214
Test: m -j vts
Test: vts-tradefed run vts -m VtsValidateDefaultPermissions
Change-Id: Ia518a51129b8acb2de68ee2cd537b57ef6378b32
The vts_permission_validate_test and
vts_defaultPermissions_validate_test are added for checking xsd schema
validation.
Bug: 127435354
Test: vts-tradefed run vts -m VtsValidatePermission
Test: vts-tradefed run vts -m VtsValidateDefaultPermissions
Merged-In: Ib73dcbe4f9c20e0a957be4325d5cfc2b27c64b67
Change-Id: Ib73dcbe4f9c20e0a957be4325d5cfc2b27c64b67
(cherry picked from commit dc15dc8cc0bbaa10f31b3b8118594a559edd0296)
