You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Joe Bowser <bo...@gmail.com> on 2014/06/11 00:35:20 UTC
[Android] Battery Plugin API drains battery..What now???
Hey
After the battery tests, I looked at the battery plugin, and we need
to shelve the battery plugin until we get a new API. Worse yet, the
W3C API proposed is terrible and should never be implemented on
Android.
So, as we currently implement it, we set the battery to listen to the
batteryChange event, which is used to return the battery level, which
isn't actually a percent but some number that isn't consistent across
Android devices. This bug has been filed.
However, a more serious bug is the fact that every time this is
triggered, it takes about 1% of battery power. 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.
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 an 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 brings us to the W3C Battery API:
http://www.w3.org/TR/battery-status/
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.
Thoughts?
Joe
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Jesse <pu...@gmail.com>.
Windows Phone 8 has a similar subscription model.
Notifies when the percentage decreases by 1%.
http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.devices.power.battery.aspx
Joe + Josh
Given that the spec states:
The definition of how often the chargingtimechange, dischargingtimechange,
> and levelchange events are fired is left to the implementation.
Couldn't cordova-android-battery just choose to notify on a larger change
... say 5%?
@purplecabbage
risingj.com
On Wed, Jun 11, 2014 at 9:51 AM, Shazron <sh...@gmail.com> wrote:
> iOS by inspection subscribes to a battery change notification that is part
> of the System framework so theoretically it has minimal impact
>
> On Wednesday, June 11, 2014, Joe Bowser <bo...@gmail.com> wrote:
>
> > So, here's a couple of questions.
> >
> > 1. Do other platforms have battery problems when they're constantly
> > monitoring the level of the battery? Or is this just something the
> > Android implementation has problems with?
> > 2. If it's just Android, does it make sense for Android to just not
> > implement this spec and not have a battery plugin?
> >
> > I could test out iOS to see if this is also a problem, but I'm
> > thinking other people already ran into this by now, right?
> >
> > On Wed, Jun 11, 2014 at 8:30 AM, Josh Soref <jsoref@blackberry.com
> > <javascript:;>> wrote:
> > > Joe Bowser wrote:
> > >> 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.
> > >
> > > It should be an implementer, but Cordova is more or less an
> implementer.
> > >
> > > It's better for someone who actually works on Cordova (e.g. You) than
> for
> > > someone who is just a user of Cordova.
> > >
> > >> 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.
> > >
> > >
> http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0049.html
> > >
> > >
> > > Is the current thread, but you can start your own. If you want more
> > > information about how to do this, you can contact Frederick Hirsch (the
> > > chair of DAP) directly.
> > >
> >
>
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Shazron <sh...@gmail.com>.
iOS by inspection subscribes to a battery change notification that is part
of the System framework so theoretically it has minimal impact
On Wednesday, June 11, 2014, Joe Bowser <bo...@gmail.com> wrote:
> So, here's a couple of questions.
>
> 1. Do other platforms have battery problems when they're constantly
> monitoring the level of the battery? Or is this just something the
> Android implementation has problems with?
> 2. If it's just Android, does it make sense for Android to just not
> implement this spec and not have a battery plugin?
>
> I could test out iOS to see if this is also a problem, but I'm
> thinking other people already ran into this by now, right?
>
> On Wed, Jun 11, 2014 at 8:30 AM, Josh Soref <jsoref@blackberry.com
> <javascript:;>> wrote:
> > Joe Bowser wrote:
> >> 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.
> >
> > It should be an implementer, but Cordova is more or less an implementer.
> >
> > It's better for someone who actually works on Cordova (e.g. You) than for
> > someone who is just a user of Cordova.
> >
> >> 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.
> >
> > http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0049.html
> >
> >
> > Is the current thread, but you can start your own. If you want more
> > information about how to do this, you can contact Frederick Hirsch (the
> > chair of DAP) directly.
> >
>
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Josh Soref <js...@blackberry.com>.
Joe Bowser wrote:
>1. Do other platforms have battery problems when they're constantly
>monitoring the level of the battery? Or is this just something the
>Android implementation has problems with?
Good question, it'd definitely be helpful to have an answer.
But please don't let that answer hold up feedback to the DAP list [1].
(Don't let perfect be the enemy of good)
There's a narrow window in which you can provide feedback asking for big
changes, so please provide the feedback about what you've experienced now.
* This is slightly different from what I wrote to Marcos [2], because you
have the firsthand experience, and I don't want to be a proxy.
>2. If it's just Android, does it make sense for Android to just not
>implement this spec and not have a battery plugin?
No, if there's a serious problem implementing a spec, then that needs to
be sent to the spec authors.
>I could test out iOS to see if this is also a problem,
Please (ideally we'd have someone else volunteer, but, …)
> but I'm thinking other people already ran into this by now, right?
I suspect people don't actually pay attention to the impact of their code.
Certainly that's my experience from dealing w/ web authors.
They'll add stuff, determine that things happen, and move onto the next
thing.
Rarely do people actually verify that their changes haven't had other
negative impact.
Especially for checklist things, and IMO this is a checklist item.
[1] http://lists.w3.org/Archives/Public/public-device-apis/
[2]
http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0053.html
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Joe Bowser <bo...@gmail.com>.
So, here's a couple of questions.
1. Do other platforms have battery problems when they're constantly
monitoring the level of the battery? Or is this just something the
Android implementation has problems with?
2. If it's just Android, does it make sense for Android to just not
implement this spec and not have a battery plugin?
I could test out iOS to see if this is also a problem, but I'm
thinking other people already ran into this by now, right?
On Wed, Jun 11, 2014 at 8:30 AM, Josh Soref <js...@blackberry.com> wrote:
> Joe Bowser wrote:
>> 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.
>
> It should be an implementer, but Cordova is more or less an implementer.
>
> It's better for someone who actually works on Cordova (e.g. You) than for
> someone who is just a user of Cordova.
>
>> 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.
>
> http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0049.html
>
>
> Is the current thread, but you can start your own. If you want more
> information about how to do this, you can contact Frederick Hirsch (the
> chair of DAP) directly.
>
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Josh Soref <js...@blackberry.com>.
Joe Bowser wrote:
> 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.
It should be an implementer, but Cordova is more or less an implementer.
It's better for someone who actually works on Cordova (e.g. You) than for
someone who is just a user of Cordova.
> 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.
http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0049.html
Is the current thread, but you can start your own. If you want more
information about how to do this, you can contact Frederick Hirsch (the
chair of DAP) directly.
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Joe Bowser <bo...@gmail.com>.
Hey
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.
Joe
On Tue, Jun 10, 2014 at 4:27 PM, Josh Soref <js...@blackberry.com> 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 event,
>> which is used to return the battery level,
>> which isn't actually a percent but some number that isn't consistent across Android devices.
>> 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 an
>> 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:
>> http://www.w3.org/TR/battery-status/
>
>> 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?
>
> http://www.w3.org/2005/10/Process-20051014/tr.html#q74
>
> 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 endorsement.
> 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).
RE: [Android] Battery Plugin API drains battery..What now???
Posted by Josh Soref <js...@blackberry.com>.
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 event,
> which is used to return the battery level,
> which isn't actually a percent but some number that isn't consistent across Android devices.
> 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 an
> 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:
> http://www.w3.org/TR/battery-status/
> 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?
http://www.w3.org/2005/10/Process-20051014/tr.html#q74
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 endorsement.
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).
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Joe Bowser <bo...@gmail.com>.
On Wed, Jun 11, 2014 at 2:54 PM, Frederico Galvão
<fr...@pontoget.com.br> wrote:
> It may be a tad offtopic, but does that mean that every app/widged on
> Android suffer from the same issues, including the native ones? It's almost
> hard to believe, if it is so.
>
Yes and no. Nobody registers a receiver to ACTION_BATTERY_CHANGED,
because this will kill your battery. You can get the percentage any
time by doing this:
//It's null, so that we don't drain the battery every time we do this!
Intent batteryIntent = mCtx.registerReceiver(null, new
IntentFilter(Intent.ACTION_BATTERY_CHANGED));
int level = batteryIntent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1);
int scale = batteryIntent.getIntExtra(BatteryManager.EXTRA_SCALE, 100);
However, if we were to listen to when the Battery actually changes,
it'd be this code, which is bad. Let's assume ChargeNotifier is a
BroadcastReceiver:
batteryUpdateNotifier = new ChargeNotifier();
IntentFilter ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
registerReceiver(batteryUpdateNotifier, ifilter);
So, what most widgets do is listen to a receive event and grab the
battery levels once. Now if you keep registering receivers, you'll
lose battery like you do every operation, the question is what would
be acceptable? I honestly think that only when the battery is low and
critical. In fact, I don't care what percentage it is, and
BATTERY_LOW is good enough for me. I also don't care about mAh rates
of charging. I don't know why these extra attributes are added to the
spec when we shouldn't be pulling the level anyway.
>
> 2014-06-11 17:38 GMT-03:00 Joe Bowser <bo...@gmail.com>:
>
>> Just wanting to throw this out there, because I'm sure people are
>> wondering how I figured this out:
>>
>> https://github.com/infil00p/ChargeNotifier
>>
>> Here's some code for a Charge Notification service in Android. When
>> the battery is low, it does a post to the CouchDB instance. When I
>> did the first run, I discovered that if I left the tablets running
>> this code, they would be dead or near dead in an hour or less. Since
>> the point of the app was to get notifications to prevent devices from
>> dying (and being unusable), this was a disaster for the project.
>> After a while, I decided to shelve the project. However, given that
>> our current battery charger code drains the battery, the experience
>> here is coming in handy.
>>
>> On Wed, Jun 11, 2014 at 1:23 PM, Joe Bowser <bo...@gmail.com> wrote:
>> > On Wed, Jun 11, 2014 at 1:01 PM, Frederico Galvão
>> > <fr...@pontoget.com.br> wrote:
>> >> If two other platforms were able to implement this on a satisfactory
>> way, I
>> >> don't think this is an issue with the spec per se (although I'm sure a
>> >> better spec would help a lot, I agree). And considering there is a
>> native
>> >> battery charge tooltip on every Android device, I'd say there is a way
>> to
>> >> subscribe to those in a safer way. With that, wouldn't the Android dev
>> >> group/bug tracker be a better place for this feedback (to make it
>> easier to
>> >> use that safe route)?
>> >>
>> >
>> >
>> http://developer.android.com/training/monitoring-device-state/battery-monitoring.html
>> >
>> http://developer.android.com/reference/android/content/Intent.html#ACTION_BATTERY_CHANGED
>> >
>> > So, using this, you can tell whether your device is charging and how
>> > it's charging, but you can't get numbers without subscribing to the
>> > ACTION_BATTERY_CHANGED intent. If you have a receiver for this
>> > intent, it will fire constantly, and this will consume battery. Not
>> > only that, this is one of the few intents that you can't connect a
>> > receiver to using the Android Manifest, because of the fact that it's
>> > not intended to be used by any process other than the
>> > battery indicator.
>> >
>> > So, the question is what interval won't kill the battery? Honestly, I
>> > don't care about the battery at all unless it's low or critical, and
>> > Android already has other actions for that, so I'm fine with this not
>> > being triggered unless the battery is actually low. However, this
>> > spec requires that we calculate charging and discharging rate as well,
>> > which I think is extra information that we don't need.
>> >
>> > The big problem is that this BatteryManager object has read-only
>> > properties that we'd have to pre-populate. I really dislike this, and
>> > would like for this plugin to be entirely async if possible.
>> >
>> >>
>> >> 2014-06-11 15:48 GMT-03:00 Marcel Kinard <cm...@gmail.com>:
>> >>
>> >>> And document why the current implementation is not recommended for app
>> >>> developers to use, because people tend to use things that are
>> available.
>> >>> That’s the short term answer.
>> >>>
>> >>> The long term answer is to get help from jsoref and others to give
>> >>> feedback to the W3C that their spec is unimplementable on the platform
>> that
>> >>> is the most popular in the market. I’d like to think that with an API
>> >>> alignment, Cordova is the [early] implementor of W3C specs like this,
>> and
>> >>> we should be an invaluable proving ground and source of feedback for
>> these
>> >>> things. Whether or not the W3C can adjust in a timely manner is another
>> >>> question (and not ours to answer), but we should be giving them
>> technical
>> >>> feedback on our implementation experience.
>> >>>
>> >>> On Jun 10, 2014, at 6:54 PM, Brian LeRoux <b...@brian.io> wrote:
>> >>>
>> >>> > shelve!
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> *Frederico Galvão*
>> >>
>> >> Diretor de Tecnologia
>> >>
>> >> PontoGet Inovação Web
>> >>
>> >>
>> >> ( +55(62) 8131-5720
>> >>
>> >> * www.pontoget.com.br <http://www.pontoget.com/>
>>
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Frederico Galvão <fr...@pontoget.com.br>.
It may be a tad offtopic, but does that mean that every app/widged on
Android suffer from the same issues, including the native ones? It's almost
hard to believe, if it is so.
2014-06-11 17:38 GMT-03:00 Joe Bowser <bo...@gmail.com>:
> Just wanting to throw this out there, because I'm sure people are
> wondering how I figured this out:
>
> https://github.com/infil00p/ChargeNotifier
>
> Here's some code for a Charge Notification service in Android. When
> the battery is low, it does a post to the CouchDB instance. When I
> did the first run, I discovered that if I left the tablets running
> this code, they would be dead or near dead in an hour or less. Since
> the point of the app was to get notifications to prevent devices from
> dying (and being unusable), this was a disaster for the project.
> After a while, I decided to shelve the project. However, given that
> our current battery charger code drains the battery, the experience
> here is coming in handy.
>
> On Wed, Jun 11, 2014 at 1:23 PM, Joe Bowser <bo...@gmail.com> wrote:
> > On Wed, Jun 11, 2014 at 1:01 PM, Frederico Galvão
> > <fr...@pontoget.com.br> wrote:
> >> If two other platforms were able to implement this on a satisfactory
> way, I
> >> don't think this is an issue with the spec per se (although I'm sure a
> >> better spec would help a lot, I agree). And considering there is a
> native
> >> battery charge tooltip on every Android device, I'd say there is a way
> to
> >> subscribe to those in a safer way. With that, wouldn't the Android dev
> >> group/bug tracker be a better place for this feedback (to make it
> easier to
> >> use that safe route)?
> >>
> >
> >
> http://developer.android.com/training/monitoring-device-state/battery-monitoring.html
> >
> http://developer.android.com/reference/android/content/Intent.html#ACTION_BATTERY_CHANGED
> >
> > So, using this, you can tell whether your device is charging and how
> > it's charging, but you can't get numbers without subscribing to the
> > ACTION_BATTERY_CHANGED intent. If you have a receiver for this
> > intent, it will fire constantly, and this will consume battery. Not
> > only that, this is one of the few intents that you can't connect a
> > receiver to using the Android Manifest, because of the fact that it's
> > not intended to be used by any process other than the
> > battery indicator.
> >
> > So, the question is what interval won't kill the battery? Honestly, I
> > don't care about the battery at all unless it's low or critical, and
> > Android already has other actions for that, so I'm fine with this not
> > being triggered unless the battery is actually low. However, this
> > spec requires that we calculate charging and discharging rate as well,
> > which I think is extra information that we don't need.
> >
> > The big problem is that this BatteryManager object has read-only
> > properties that we'd have to pre-populate. I really dislike this, and
> > would like for this plugin to be entirely async if possible.
> >
> >>
> >> 2014-06-11 15:48 GMT-03:00 Marcel Kinard <cm...@gmail.com>:
> >>
> >>> And document why the current implementation is not recommended for app
> >>> developers to use, because people tend to use things that are
> available.
> >>> That’s the short term answer.
> >>>
> >>> The long term answer is to get help from jsoref and others to give
> >>> feedback to the W3C that their spec is unimplementable on the platform
> that
> >>> is the most popular in the market. I’d like to think that with an API
> >>> alignment, Cordova is the [early] implementor of W3C specs like this,
> and
> >>> we should be an invaluable proving ground and source of feedback for
> these
> >>> things. Whether or not the W3C can adjust in a timely manner is another
> >>> question (and not ours to answer), but we should be giving them
> technical
> >>> feedback on our implementation experience.
> >>>
> >>> On Jun 10, 2014, at 6:54 PM, Brian LeRoux <b...@brian.io> wrote:
> >>>
> >>> > shelve!
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> *Frederico Galvão*
> >>
> >> Diretor de Tecnologia
> >>
> >> PontoGet Inovação Web
> >>
> >>
> >> ( +55(62) 8131-5720
> >>
> >> * www.pontoget.com.br <http://www.pontoget.com/>
>
--
*Frederico Galvão*
Diretor de Tecnologia
PontoGet Inovação Web
( +55(62) 8131-5720
* www.pontoget.com.br <http://www.pontoget.com/>
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Joe Bowser <bo...@gmail.com>.
Just wanting to throw this out there, because I'm sure people are
wondering how I figured this out:
https://github.com/infil00p/ChargeNotifier
Here's some code for a Charge Notification service in Android. When
the battery is low, it does a post to the CouchDB instance. When I
did the first run, I discovered that if I left the tablets running
this code, they would be dead or near dead in an hour or less. Since
the point of the app was to get notifications to prevent devices from
dying (and being unusable), this was a disaster for the project.
After a while, I decided to shelve the project. However, given that
our current battery charger code drains the battery, the experience
here is coming in handy.
On Wed, Jun 11, 2014 at 1:23 PM, Joe Bowser <bo...@gmail.com> wrote:
> On Wed, Jun 11, 2014 at 1:01 PM, Frederico Galvão
> <fr...@pontoget.com.br> wrote:
>> If two other platforms were able to implement this on a satisfactory way, I
>> don't think this is an issue with the spec per se (although I'm sure a
>> better spec would help a lot, I agree). And considering there is a native
>> battery charge tooltip on every Android device, I'd say there is a way to
>> subscribe to those in a safer way. With that, wouldn't the Android dev
>> group/bug tracker be a better place for this feedback (to make it easier to
>> use that safe route)?
>>
>
> http://developer.android.com/training/monitoring-device-state/battery-monitoring.html
> http://developer.android.com/reference/android/content/Intent.html#ACTION_BATTERY_CHANGED
>
> So, using this, you can tell whether your device is charging and how
> it's charging, but you can't get numbers without subscribing to the
> ACTION_BATTERY_CHANGED intent. If you have a receiver for this
> intent, it will fire constantly, and this will consume battery. Not
> only that, this is one of the few intents that you can't connect a
> receiver to using the Android Manifest, because of the fact that it's
> not intended to be used by any process other than the
> battery indicator.
>
> So, the question is what interval won't kill the battery? Honestly, I
> don't care about the battery at all unless it's low or critical, and
> Android already has other actions for that, so I'm fine with this not
> being triggered unless the battery is actually low. However, this
> spec requires that we calculate charging and discharging rate as well,
> which I think is extra information that we don't need.
>
> The big problem is that this BatteryManager object has read-only
> properties that we'd have to pre-populate. I really dislike this, and
> would like for this plugin to be entirely async if possible.
>
>>
>> 2014-06-11 15:48 GMT-03:00 Marcel Kinard <cm...@gmail.com>:
>>
>>> And document why the current implementation is not recommended for app
>>> developers to use, because people tend to use things that are available.
>>> That’s the short term answer.
>>>
>>> The long term answer is to get help from jsoref and others to give
>>> feedback to the W3C that their spec is unimplementable on the platform that
>>> is the most popular in the market. I’d like to think that with an API
>>> alignment, Cordova is the [early] implementor of W3C specs like this, and
>>> we should be an invaluable proving ground and source of feedback for these
>>> things. Whether or not the W3C can adjust in a timely manner is another
>>> question (and not ours to answer), but we should be giving them technical
>>> feedback on our implementation experience.
>>>
>>> On Jun 10, 2014, at 6:54 PM, Brian LeRoux <b...@brian.io> wrote:
>>>
>>> > shelve!
>>>
>>>
>>
>>
>> --
>>
>> *Frederico Galvão*
>>
>> Diretor de Tecnologia
>>
>> PontoGet Inovação Web
>>
>>
>> ( +55(62) 8131-5720
>>
>> * www.pontoget.com.br <http://www.pontoget.com/>
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Joe Bowser <bo...@gmail.com>.
On Wed, Jun 11, 2014 at 1:01 PM, Frederico Galvão
<fr...@pontoget.com.br> wrote:
> If two other platforms were able to implement this on a satisfactory way, I
> don't think this is an issue with the spec per se (although I'm sure a
> better spec would help a lot, I agree). And considering there is a native
> battery charge tooltip on every Android device, I'd say there is a way to
> subscribe to those in a safer way. With that, wouldn't the Android dev
> group/bug tracker be a better place for this feedback (to make it easier to
> use that safe route)?
>
http://developer.android.com/training/monitoring-device-state/battery-monitoring.html
http://developer.android.com/reference/android/content/Intent.html#ACTION_BATTERY_CHANGED
So, using this, you can tell whether your device is charging and how
it's charging, but you can't get numbers without subscribing to the
ACTION_BATTERY_CHANGED intent. If you have a receiver for this
intent, it will fire constantly, and this will consume battery. Not
only that, this is one of the few intents that you can't connect a
receiver to using the Android Manifest, because of the fact that it's
not intended to be used by any process other than the
battery indicator.
So, the question is what interval won't kill the battery? Honestly, I
don't care about the battery at all unless it's low or critical, and
Android already has other actions for that, so I'm fine with this not
being triggered unless the battery is actually low. However, this
spec requires that we calculate charging and discharging rate as well,
which I think is extra information that we don't need.
The big problem is that this BatteryManager object has read-only
properties that we'd have to pre-populate. I really dislike this, and
would like for this plugin to be entirely async if possible.
>
> 2014-06-11 15:48 GMT-03:00 Marcel Kinard <cm...@gmail.com>:
>
>> And document why the current implementation is not recommended for app
>> developers to use, because people tend to use things that are available.
>> That’s the short term answer.
>>
>> The long term answer is to get help from jsoref and others to give
>> feedback to the W3C that their spec is unimplementable on the platform that
>> is the most popular in the market. I’d like to think that with an API
>> alignment, Cordova is the [early] implementor of W3C specs like this, and
>> we should be an invaluable proving ground and source of feedback for these
>> things. Whether or not the W3C can adjust in a timely manner is another
>> question (and not ours to answer), but we should be giving them technical
>> feedback on our implementation experience.
>>
>> On Jun 10, 2014, at 6:54 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>> > shelve!
>>
>>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Frederico Galvão <fr...@pontoget.com.br>.
If two other platforms were able to implement this on a satisfactory way, I
don't think this is an issue with the spec per se (although I'm sure a
better spec would help a lot, I agree). And considering there is a native
battery charge tooltip on every Android device, I'd say there is a way to
subscribe to those in a safer way. With that, wouldn't the Android dev
group/bug tracker be a better place for this feedback (to make it easier to
use that safe route)?
2014-06-11 15:48 GMT-03:00 Marcel Kinard <cm...@gmail.com>:
> And document why the current implementation is not recommended for app
> developers to use, because people tend to use things that are available.
> That’s the short term answer.
>
> The long term answer is to get help from jsoref and others to give
> feedback to the W3C that their spec is unimplementable on the platform that
> is the most popular in the market. I’d like to think that with an API
> alignment, Cordova is the [early] implementor of W3C specs like this, and
> we should be an invaluable proving ground and source of feedback for these
> things. Whether or not the W3C can adjust in a timely manner is another
> question (and not ours to answer), but we should be giving them technical
> feedback on our implementation experience.
>
> On Jun 10, 2014, at 6:54 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > shelve!
>
>
--
*Frederico Galvão*
Diretor de Tecnologia
PontoGet Inovação Web
( +55(62) 8131-5720
* www.pontoget.com.br <http://www.pontoget.com/>
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Marcel Kinard <cm...@gmail.com>.
And document why the current implementation is not recommended for app developers to use, because people tend to use things that are available. That’s the short term answer.
The long term answer is to get help from jsoref and others to give feedback to the W3C that their spec is unimplementable on the platform that is the most popular in the market. I’d like to think that with an API alignment, Cordova is the [early] implementor of W3C specs like this, and we should be an invaluable proving ground and source of feedback for these things. Whether or not the W3C can adjust in a timely manner is another question (and not ours to answer), but we should be giving them technical feedback on our implementation experience.
On Jun 10, 2014, at 6:54 PM, Brian LeRoux <b...@brian.io> wrote:
> shelve!
Re: [Android] Battery Plugin API drains battery..What now???
Posted by Brian LeRoux <b...@brian.io>.
shelve!
On Tue, Jun 10, 2014 at 3:35 PM, Joe Bowser <bo...@gmail.com> wrote:
> Hey
>
> After the battery tests, I looked at the battery plugin, and we need
> to shelve the battery plugin until we get a new API. Worse yet, the
> W3C API proposed is terrible and should never be implemented on
> Android.
>
> So, as we currently implement it, we set the battery to listen to the
> batteryChange event, which is used to return the battery level, which
> isn't actually a percent but some number that isn't consistent across
> Android devices. This bug has been filed.
>
> However, a more serious bug is the fact that every time this is
> triggered, it takes about 1% of battery power. 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.
>
> 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 an 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 brings us to the W3C Battery API:
> http://www.w3.org/TR/battery-status/
>
> 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.
>
> Thoughts?
>
> Joe
>