See discussion at https://groups.google.com/forum/#!topic/mozilla.dev.b2g/Lrt-eE9WsQs
The api seems to work correctly, but my flame doesn't change its light color at all. Not sure if it's a hardware limitation or if I'm doing something wrong.
Let's try this on my Desire Z, this one has LEDs that can change their color :)
So, applied on Desire Z, ran from your webpage that does random stuff on the BATTERY indicator: I have my Desire Z with the battery charging mode LED (orange) :)
Enhancing the first WIP with the ability to make use of the flashing feature.
Making the notifications LED flashing when there are pending notifications to be read.
Several devices have a LED that allows to make the device buttons visible. We can drive them with this API. I just checked, Geeksphone Keon and Peak exposes both this buttons LED. Also, the Peak allows to drive red/green/blue colors (i.e., they are exposed at SysFS level).
On a ZTE Open C we can change the brightness of button-backlight with : adb shell "echo n > /sys/class/leds/button-backlight/brightness" where 0<= n < 40
Status update: this is working good enough for a hack, but we need to take some time and think about an API that is not just exposing how Android's light interface works.
Any input/suggestions for spinning up a new API on this topic ? Some more finding that I just came accross: - Flame has a "torch-light" driver exposing in SysFS ; I cannot find something similar on other devices - there's no access to flash light from the Android liblights' implementation on the Flame - there is no proper consistency regarding the available physical lights exposed - there is more or less consistency regarding the notifications means exposed in liblights: - this is dependant on each OEM - that's in <hardware/lights.h> - a set of #define LIGHT_ID_*, covering: backlight, keyboard, buttons, battery, notifications, attention, bluetooth and wifi - those last two are said not to be supported yet For the torch-light not exposed for the Flame, we can probably quite easily expose it ourselves. For the rest of the issues, we can maybe have a higher level API that makes use of liblight but not only. One question we will have to address is probably what do we expose: lights directly, or their use and let low-level code drive the proper lighting according to what we need to do?
It seems like it's hard to get access to the color capabilities of the LED. If so, maybe we can simply make this a compile time thing. I.e. create setting which contain the patterns for the various "modes", and then give this setting a default value at compile time. We already have code which allows distributions to set distribution-specific settings. Then have the system app code read this setting and pass the values from the settings to the API. As for an API for driving the tourch-light. Having an API which takes the same type of array as the vibration API seems like it'd get us pretty far. I.e. something like [timeon, timeoff, timeon, timeoff, ...]. But for the LED we'd automatically repeat it. You could then pass [Infinity] to turn on, and [0, Infinity] to turn off. That's a bit hacky though, so maybe having separate functions for turn-on and turn-off would be good. Not sure if I'm answering the asked question?
If we don't want to support colors, Jonas' suggestion makes sense to me.
Just tried the above patches on my Open C (v2.1) and it works! Thank you people. The led doesn't blink or change color but at least I can tell when I missed a call or sms. Hard to understand why this feature was/is not available by default. Another feature missing from v2.1 (but existing in 1.3) is the home button led lighting up when opening the phone. I can set it manually as mentioned above but it's permanent..
Attachment #8652543 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.