887634 - don't shut down on low battery if charging

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

Attachment: pull request 10654

The system app shuts down the system if the battery is critically low, even if the device is plugged in.  This makes it impossible to use a device with an empty battery, even if the device is plugged in and capable of being used on line power.

It also causes the desktop build of B2G for Linux to shut down on startup when a dead battery is present, which is the case for some of its users (who turn laptops with dead batteries into desktop computers).  See https://github.com/mozilla/r2d2b2g/issues/536 for some examples.

It seems like the system app should only shut down when the battery is critically low if it also isn't charging (i.e. connected to an external power source).  Here's a patch that implements that additional check.

@vingtetun: can you review this or suggest someone to do so?

Comment 1

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 768154 [details]
pull request 10654

Sounds good to me.

Comment 2

[Alexandre Poirot [:ochameau]]

master: ced5b77eeb1eab1decacf3d461ddcf7d01df6a4d

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Regardless of whatever determination the release managers make about Leo blocking status, I'd like to request uplift to v1-train to include this fix in the Simulator.

And the B2G Landing page says the way to do "all other landings for v1.x" is to "nominate for approval-gaia-v1 or approval-mozilla-b2g18" <https://wiki.mozilla.org/Release_Management/B2G_Landing#All_other_landings_for_v1.x_.28updated_3.2F27.29>.

But approval-gaia-v1 is not available to the patch, and approval-mozilla-b2g18 is "now for security issues only."  So how do I request approval to uplift this patch to v1-train?

Comment 4

[Wayne Chang [:wchang]]

Triage - Leo partners do not wish to take this fix at this stage.

Comment 5

[Alex Keybl [:akeybl]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #3)
> Regardless of whatever determination the release managers make about Leo
> blocking status, I'd like to request uplift to v1-train to include this fix
> in the Simulator.
> 
> And the B2G Landing page says the way to do "all other landings for v1.x" is
> to "nominate for approval-gaia-v1 or approval-mozilla-b2g18"
> <https://wiki.mozilla.org/Release_Management/
> B2G_Landing#All_other_landings_for_v1.x_.28updated_3.2F27.29>.
> 
> But approval-gaia-v1 is not available to the patch, and
> approval-mozilla-b2g18 is "now for security issues only."  So how do I
> request approval to uplift this patch to v1-train?

Will update that page, we're at critical blockers only so we can't take this fix till 1.2, apologies.

Comment 6

[Alex Keybl [:akeybl]]

(we should consider making the simulator builds off of separate repos that sync with our pre-release repos, in which case this wouldn't require approval/blocking status.)

Comment 7

[Myk Melez [:myk] [@mykmelez]]

(In reply to Alex Keybl [:akeybl] from comment #5)
> Will update that page, we're at critical blockers only so we can't take this
> fix till 1.2, apologies.

This may not be critical on devices, but it is critical for a subset of Simulator users, who can't use the Simulator at all without this fix (because their systems report battery status in a way that causes Gaia to shut down on startup due to this bug).


(In reply to Alex Keybl [:akeybl] from comment #6)
> (we should consider making the simulator builds off of separate repos that
> sync with our pre-release repos, in which case this wouldn't require
> approval/blocking status.)

We already do that, but fewer branches is less work and less chance of mistakes, which is why the Simulator team has been upstreaming all its Simulator-compatibility fixes (most of which also benefit B2G/Gaia on devices, as would this one).

Comment 8

[Alex Keybl [:akeybl]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> (In reply to Alex Keybl [:akeybl] from comment #6)
> > (we should consider making the simulator builds off of separate repos that
> > sync with our pre-release repos, in which case this wouldn't require
> > approval/blocking status.)
> 
> We already do that, but fewer branches is less work and less chance of
> mistakes, which is why the Simulator team has been upstreaming all its
> Simulator-compatibility fixes (most of which also benefit B2G/Gaia on
> devices, as would this one).

OK great, sounds like we can fix up the simulator nonetheless. In the future, let's upstream agree to uplift all low risk simulator fixes for the first 18 out of 24 weeks of development. Last few weeks we don't like to take unneeded change.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

(In reply to Alex Keybl [:akeybl] from comment #8)
> In the future, let's upstream agree to uplift all low risk simulator fixes for
> the first 18 out of 24 weeks of development.

At first glance, that seems reasonable, once both B2G/Gaia and the Simulator get into a regular release cadence, although I think we'll need to try it out to be sure, and others (f.e. mossop, cc:ed) should be part of this conversation.


> Last few weeks we don't like to take unneeded change.

Y'all and us both!

Comment 10

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

per b2g meeting just now, and yesterday's b2g-dev meeting, can we revisit this? 

Currently, to support 1.1 app developers, myk is required to manually generate a second, separate build, identical except for this additional patch. If this patch is landed on b2g-18, then these simulator builds can be generated automatically by RelEng. So long as we have external app developers focused on shipping v1.1 apps, and not focused on shipping v1.2 apps, getting this landed is v.helpful.

What testing can be done to address stability concerns raised in comments#5, allow this patch land and unblock automating this?

Comment 11

[Jason Smith [:jsmith]]

To unblock 1.2 I'll koi+. See comment 10 if we need to consider for v1-train.