STR: 1. Create an empty System app and replace the current System app (you can do so by replace the System app package w/ Template app -- remember to back up and remember to turn on necessary DevTools switches first -- see below) 2. Reboot the phone 3. Use DevTools to get |navigator.mozPower.screenBrightness| 4. Use DevTools to set |navigator.mozPower.screenBrightness = 0| 5. Use DevTools to set |navigator.mozPower.screenBrightness = 1| Actual: On step (3), |navigator.mozPower.screenBrightness| should return the current screen brightness but it returns 0, probably from [1], while the screen brightness is clearly not zero. Step (4) does not actually turn the screen brightness off Only step (5) does turn on up the screen brightness. [1] https://dxr.mozilla.org/mozilla-central/source/hal/gonk/GonkHal.cpp#810-812 Expected: step (3) should return the initial screen brightness. step (4) should allow the user to turn down the screen brightness. Note: Before replacing System app, you should ensure: * DevTools is turned on in Settings app. * Allow DevTools to debug certified app (`devtools.debugger.forbid-certified-apps`) is set to true. * Allow adb access even when lock screen is enabled (`marionette.defaultPrefs.enabled` should be true). * DevTools should be allowed to attach without user consent (`devtools.debugger.prompt-connection` should be false).

Dave, the related change was done in bug 1125084. While bug 1125084 prevent crashing the phone when attempt to read the uninitialized value (I guess?), 0 is not the correct number either. Is the screen brightness, at the time, is a constant set by Gonk? I think we should update the number here to match that? Thanks!

The API that android provides for working with "lights" is defined by the light_device_t structure, which looks like this: > struct light_device_t { > struct hw_device_t common; > > /** > * Set the provided lights to the provided values. > * > * Returns: 0 on succes, error code on failure. > */ > int (*set_light)(struct light_device_t* dev, > struct light_state_t const* state); > }; so there is no way to query the current value without first setting it to something. We cache the last value set and return that when querying the current value. So no matter what we do, the answer will essentially be wrong under some circumstance until you first set the value.

More mass-incompleting of FxOS bugs in the Device Interfaces component. Please update and let me know if any of these are still valid.