Often, researchers have been warning us about the adverse effects of blue light on the eyes and even on the skin (in contrast to the effect UV rays have on homo sapiens giving them skin tans), which are the common areas of exposure.
For the denizens of the 21st century or rather the ‘millennials’, being constantly engaged with mobile phones is a common practice, which in turn provides a good enough source of blue light intake per day.
Even more of an issue for us computer scientists/engineers, with the blue light from the screens of digital devices we constantly use (phones/tablets and laptops) posing a serious threat to our health (such as eye strain, which in turn may lead to headaches) - if not now, in the long run. (chronic variants of eye/retinal problems)
To counter this to some extent, an android feature named ‘Night Light’ was introduced in Android 7.1.1, which reduces the amount of blue light emitted by the device display to better match the natural light with the user’s timezone, without affecting the visibility of your display. Android 8.0 introduced an additional feature that gave users more control over the intensity of the ‘Night Light’ effect. Android 10.0 introduces the COLOR_DISPLAY_SERVICE
system service, with a system API surface to give the system corresponding settings and a UI with more control and color transformations. (as Night Light, after all, is a color transformation in itself)
You can consider them to be a filter, with colors designed to reduce the blue light emission and prove to be slightly more comforting to the eyes, suitable for a sleepy trance. This, of course, is a software implementation. (Note that Night Light requires a Hardware Composer implementation that can apply the matrix passed to setColorTransform
function to perform tinting without impacting power, performance, and app compatibility)
You can consider an external approach with thin tempered glass that reduces blue light emission and also protects your device’s screen from scratches.
Examples of blue light filters for digital devices include Eyesafe, RetinaShield, Frabicon, and Cyxus.
Considering the default software implementation for android, lets have a look at its source code:
<!-- Control whether Night display is available. This should only be enabled
on devices with HWC 2 color transform support. -->
<bool name="config_nightDisplayAvailable">false</bool>
<!-- Default mode to control how Night display is automatically activated.
One of the following values (see NightDisplayController.java):
0 - AUTO_MODE_DISABLED
1 - AUTO_MODE_CUSTOM
2 - AUTO_MODE_TWILIGHT
-->
<integer name="config_defaultNightDisplayAutoMode">0</integer>
<!-- Default time when Night display is automatically activated.
Represented as milliseconds from midnight (e.g. 79200000 == 10pm). -->
<integer name="config_defaultNightDisplayCustomStartTime">79200000</integer>
<!-- Default time when Night display is automatically deactivated.
Represented as milliseconds from midnight (e.g. 21600000 == 6am). -->
<integer name="config_defaultNightDisplayCustomEndTime">21600000</integer>
<!-- Minimum color temperature, in Kelvin, supported by Night display. -->
<integer name="config_nightDisplayColorTemperatureMin">2596</integer>
<!-- Default color temperature, in Kelvin, to tint the screen when Night display is
activated. -->
<integer name="config_nightDisplayColorTemperatureDefault">2850</integer>
<!-- Maximum color temperature, in Kelvin, supported by Night display. -->
<integer name="config_nightDisplayColorTemperatureMax">4082</integer>
The code is divided between framework, system services, System UI, and Settings with the core functionality being controlled by ColorDisplayManager
and backed by ColorDisplayService
.
Device manufacturers can customize the color ramp based on the characteristics of the device’s display panel, including the white point and desired color.
One can change the color ramp without changing the base implementation by using a configuration overlay. This configuration is expressed as a quadratic equation for each of red, green and blue in the form vres = vat2 + vbt + vy-int
where t
is the temperature input in Kelvin, as specified in the range between config_nightDisplayColorTemperatureMin
and config_nightDisplayColorTemperatureMax
and va
, vb
and vy-int
are the a-coefficient, b-coefficient and y-intercept respectively for the given primary curve, as indicated below:
<string-array name="config_nightDisplayColorTemperatureCoefficientsNative">
<!-- R a-coefficient --> <item>0.0</item>
<!-- R b-coefficient --> <item>0.0</item>
<!-- R y-intercept --> <item>1.0</item>
<!-- G a-coefficient --> <item>-0.00000000962353339</item>
<!-- G b-coefficient --> <item>0.000153045476</item>
<!-- G y-intercept --> <item>0.390782778</item>
<!-- B a-coefficient --> <item>-0.0000000189359041</item>
<!-- B b-coefficient --> <item>0.000302412211</item>
<!-- B y-intercept --> <item>-0.198650895</item>
</string-array>
Because Night Light is a user-facing feature, users can control it as per requirement (varying the intensity as per need). There is a full implementation of the settings in the Android Open Source Project’s packages/apps/Settings
that device manufacturers can refer to for their Settings implementation. And yes, implementers must be aware of and handle Settings.ACTION_NIGHT_DISPLAY_SETTINGS
’s intent to expose these settings.
Anirban | 01/01/2020 |