cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: [Android] Battery Plugin API drains battery..What now???
Date Wed, 11 Jun 2014 15:03:34 GMT

So, last call for this is on Friday! Josh, can anyone directly
involved send in the -1 to this spec, or do you have to be involved
somehow.  Otherwise, there's no way that Cordova can implement this on
Android, and we'll be stuck with a plugin that has to be divergent.


On Tue, Jun 10, 2014 at 4:27 PM, Josh Soref <> wrote:
> Joe wrote:
>> After the battery tests, I looked at the battery plugin, and we need to shelve the
battery plugin until we get a new API.
> Sounds good to me.
>> Worse yet, the W3C API proposed is terrible and should never be implemented on Android.
> I was involved, but agree.
>> So, as we currently implement it, we set the battery to listen to the batteryChange
>> which is used to return the battery level,
>> which isn't actually a percent but some number that isn't consistent across Android
>> This bug has been filed.
> Awesome.
>> However, a more serious bug is the fact that every time this is triggered, it takes
about 1% of battery power.
> This is more or less what I expected (feared, warned about)
>>  I've played with this event in the past on a side project, and it's killed batteries
on my devices in less than an hour.
> I wish you had been able to send this feedback when I was working on this stuff...
>> So, the proper way you monitor for battery events is by monitoring for certain events
>> by adding an events receiver in the AndroidManifest.xml file, and letting that fire
>> event depending on whether there's a callbackContext assigned to it.
>> The problem is that we should only monitor certain manifests,
>> and get the values when those events happen.
>>  We can support getting the value of the battery on demand,
>> but we should discourage our users from doing this.
> This was my main point. Roughly I saw:
> * You can't do anything remotely useful w/ the battery information. You don't know how
much time you have before:
> 1. Your device loses network connectivity
> 2. Your user drops your device and the battery flies out / the device falls into a body
of water
> 3. Your device panics
> 4. Your application crashes
> 5. Your device decides to terminate your application because it needs memory
> * I expected it to be expensive (and a heisenbug, in that the act of observing [monitoring]
it changes it)
> * The only practical use I've seen for this is to create a battery widget, which was
not a good UC in my mind
>> This brings us to the W3C Battery API:
>> To me, this is unimplementable without killing the battery,
>> since this appears to work similarly to our device API in that we'd have to populate
this on an interval,
>> and that interval on Android is how fast you want your battery to die.
>> So, how do we want to approach this?
>> I have no idea why the W3C wrote a specification that is near impossible to implement.
> It was written because "app authors" demanded it.
>> Thoughts?
> 7.1.2 Maturity Levels of the Recommendation Track
> Candidate Recommendation (CR)
>     A Candidate Recommendation is a document that W3C believes has been widely reviewed
and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation
to gather implementation experience.
> Proposed Recommendation (PR)
>     A Proposed Recommendation is a mature technical report that, after wide review for
technical soundness and implementability, W3C has sent to the W3C Advisory Committee for final
> W3C Recommendation (REC)
>     A W3C Recommendation is a specification or set of guidelines that, after extensive
consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends
the wide deployment of its Recommendations. Note: W3C Recommendations are similar to the standards
published by other organizations.
> 7.1.3 Maturity Level When Ending Work on a Technical Report
> Working Group Note
>     A Working Group Note is published by a chartered Working Group to indicate that work
has ended on a particular topic. A Working Group MAY publish a Working Group Note with or
without its prior publication as a Working Draft.
> CR is the stage where implementers are supposed to be giving feedback. Put on an implementer
hat (Cordova) and send feedback explaining your concerns. Ideally this feedback is precisely
what is needed to get this proposal to die as a CR (dead proposals are republished as NOTES
with an explanation that people should not use/implement them).
> I'll be glad to offer support in this area (not wearing my corporate hat).

View raw message