Closed Bug 959195 Opened 10 years ago Closed 10 years ago

FOTA updates should check remaining battery

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
2.0 S3 (6june)

People

(Reporter: gerard-majax, Assigned: gerard-majax)

References

Details

(Whiteboard: [systemsfe])

Attachments

(2 files)

Currently, we allow booting into recovery and applying FOTA even with very low battery. This is quite risky.

We should not let user apply FOTA updates in this case. I've been able to do this with a Peak and less than 5% of battery.
I guess we need some UX for this.
Flags: needinfo?(firefoxos-ux-bugzilla)
Flagging Mike to direct to whomever is best/available on System here.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(mtsai)
Flagging Neo to help on this issue.
Flags: needinfo?(mtsai) → needinfo?(nhsieh)
"we allow booting into recovery and applying FOTA even with very low battery" .  
So for users, the first step is swipe down the status bar and click the update notification, right ? Or can we just press some hardware key to booting into recovery mode like other android phone ? (Ex. Power+Volumn key) 

Another questions is, If user connect charger with mobile phone in low battery mode, is that safe enough to update the firmware ? Is it should use battery power only ?

If user enter FOTA mode from idle mode, I think we can inform or disable update notification function when device is low battery. But we can not stop user use hardware key enter recovery mode, except we can change recovery mode UI... (But I guess that is controlled by ODM).
Flags: needinfo?(nhsieh) → needinfo?(lissyx+mozillians)
(In reply to Neo Hsieh from comment #4)
> "we allow booting into recovery and applying FOTA even with very low
> battery" .  
> So for users, the first step is swipe down the status bar and click the
> update notification, right ? Or can we just press some hardware key to
> booting into recovery mode like other android phone ? (Ex. Power+Volumn key) 
> 
> Another questions is, If user connect charger with mobile phone in low
> battery mode, is that safe enough to update the firmware ? Is it should use
> battery power only ?
> 
> If user enter FOTA mode from idle mode, I think we can inform or disable
> update notification function when device is low battery. But we can not stop
> user use hardware key enter recovery mode, except we can change recovery
> mode UI... (But I guess that is controlled by ODM).

We are only talking about OTA/FOTA applied from Gecko, yes. Not when the users enters into recovery by hand.
Flags: needinfo?(lissyx+mozillians)
I'm unsure whether the recovery mode allows to charge the device or not.
Whiteboard: [systemsfe]
So, what should we do?
Flags: needinfo?(firefoxos-ux-bugzilla)
Flagging Omega on hardware related UI here.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(ofeng)
ni? new UX owner Jenny.
Flags: needinfo?(jelee)
For current implementation, when FOTA is downloaded, there is a dialog:

System Update Ready
---------------------
Install update now?

[Later] [Install Now]

We can change to, when FOTA is downloaded, check the battery level, if it's >= 50%, go for the above dialog; otherwise (< 50%), go for the following dialog:

System Update Ready
---------------------
You need at least 50% battery level to install the update.

[OK]

User can charge the battery and tap the notification to show the first dialog again.
Flags: needinfo?(ofeng)
Flags: needinfo?(jelee)
Let's do this.
Status: NEW → ASSIGNED
Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(lissyx+mozillians)
Target Milestone: --- → 2.0 S3 (6june)
Attached is a link to the github pull request addressing the issue. Unit tests are okay locally, I still need to test this on device though.
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Attached image 2014-06-04-13-36-26.png
Screenshot on device, forcing battery level at 30%.
Comment on attachment 8434067 [details]
2014-06-04-13-36-26.png

Jenny, the attached screenshot shows how the UI looks to the user.
Attachment #8434067 - Flags: ui-review?(jelee)
Comment on attachment 8433387 [details] [review]
Link to Github https://github.com/mozilla-b2g/gaia/pull/19940

Etienne, since you did quite a lot of things on this file, I'm flagging you for review.
Attachment #8433387 - Flags: review?(etienne)
Comment on attachment 8434067 [details]
2014-06-04-13-36-26.png

Message title should be in English? Tks!
Attachment #8434067 - Flags: ui-review?(jelee) → ui-review+
(In reply to Jenny Lee from comment #16)
> Comment on attachment 8434067 [details]
> 2014-06-04-13-36-26.png
> 
> Message title should be in English? Tks!

Of course, I tested it on my Flame which was running in French locale. I'm re-using the previous system update string, so it's fine.
Comment on attachment 8433387 [details] [review]
Link to Github https://github.com/mozilla-b2g/gaia/pull/19940

The code is perfect, nothing to say there :)

But shouldn't we let the user start the update if the phone is plugged in?
Attachment #8433387 - Flags: review?(etienne) → review+
(In reply to Etienne Segonzac (:etienne) from comment #18)
> Comment on attachment 8433387 [details] [review]
> Link to Github https://github.com/mozilla-b2g/gaia/pull/19940
> 
> The code is perfect, nothing to say there :)
> 
> But shouldn't we let the user start the update if the phone is plugged in?

That would be a UX decision. However, the behavior of Android device is to forbid even if the device is plugged in.

Jenny, do you have an opinion? Or should we just land as is?
Flags: needinfo?(jelee)
(In reply to Alexandre LISSY :gerard-majax from comment #19)
> That would be a UX decision. However, the behavior of Android device is to
> forbid even if the device is plugged in.
> 
> Jenny, do you have an opinion? Or should we just land as is?

We can't know for sure if the device will still be plugged in after the installation starts, so, just to be safe, let's keep the current behavior. Tks!
Flags: needinfo?(jelee)
https://github.com/mozilla-b2g/gaia/commit/c4a591b15bc0ddcc6e7262a3d11fa975aa9beedb
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Blocks: 1102959
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: