On 09/29/2014 12:27 AM, Fabrice Desré wrote:
One issue is that the android HAL doesn't expose what the device LED supports - it's really best effort, see http://androidxref.com/4.4.4_r1/xref/hardware/libhardware/include/hardware/lights.h#92 So I think it would be quite hard to implement this 'colors' property. For instance the Flame has no color control at all.
Are we compelled to use the Android HAL layer for this? Both my Flame device (FxOS) and my Nexus 4 (Android) expose their usable LEDs in /sys/class/leds. They also include a bunch of LEDs we don't care about, as you point out. Could we just disable the android HAL here and take-over and require our board mapping/configuration to explicitly provide a mapping for us (while leveraging the existing linux kernel driver infrastructure for LEDs)? No mapping, no hasFeature().
It sounds like the Android HAL for LEDs is designed to service the existing Notifications API (check out http://developer.android.com/reference/android/app/Notification.html#ledARGB and the properties that follow it). Although we want to converge on Web APIs it's not clear the Android status quo is particularly what we want. As I understand it, the API is limited to specifying a single color and an "on" and "off" duration.
My personal use case when using Android on a Nexus 4 has been to watch my phone for ~5 seconds and see if it does a white LED pulse. If it does, I know I should probably check out what's up on the phone. It's useful, but there's not a lot of entropy.
I propose that we need to be able to convey the winner of a World Cup match by encoding the dominant colors of the winning country's flag. It turns out Germany's flag has black in it, so that's not great for my example, so let's go with 2010 where Spain apparently won. A linear-gradient-inspired style of "red 0%, yellow 25%, red 75%", for example could convey this with a fixed time interval. Or an arbitrary time interval.
Now, this is arguably a fancy API. But Jonas' root proposal is to be able to convey low battery/very low battery/charging and I'm not sure that is something worth actually surfacing an API that's exposed formally anywhere. If that's all we want, the chrome bits can just do their XPCOM/js-ctypes thing.
If we want an API, let's do it better. And I do think we can mash-up the "charging" use-case with the "notification" use-case. Assuming a user-attention interval of 5 seconds, we can do 3 seconds of charging indication (red through green) followed by a 2-second animation cycle that cycles through the gradient syntax to illustrate the most important thing going on on the phone, notification-wise.
Andrew _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
