Closed Bug 1055964 Opened 10 years ago Closed 10 years ago

[System][Updates] When an update is canceled because battery level is too low, we should be able to resume

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.0 affected, b2g-v2.1 unaffected, b2g-v2.2 unaffected)

RESOLVED WORKSFORME
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- unaffected
b2g-v2.2 --- unaffected

People

(Reporter: julienw, Unassigned)

Details

STR:
1. have less than 50% battery
2. have a system update available
3. start the system update download (tap "update available" in the notification panel and accept it)
4. wait until it's downloaded

=> The "Battery too low" message is displayed.
=> The "system update" notification is removed. If we have other available updates (for applications), we can display it, but the available system update is not displayed in this panel.
=> Only way to make it appear again is to click "check update now" in the Settings app. Then we can _download_ it again, we can clearly see it's not cached.

I also thing that the 50% threshold for the "low battery" message could be lowered, but that's another subject.

[Blocking Requested - why for this release]:
* System updates are important. This happened twice in 1 week to me (granted I have one new available update every day).
* data usage is important
* the fix is likely small and non-risky
Triage discussed and concluded that the issue shouldn't block if it's not a regression. I'm concerned about worst case scenario like an urgent security release pushed out through OEM update that's deployed over 1.5G connections. But we still wouldn't hold back 2.0 for that at this point.

If this is a regression, we can immediately block. Please renominate if that's the case.
blocking-b2g: 2.0? → backlog
I'm quite sure this is a regression: I never saw the "low battery" message before v2.0. I might be wrong though.
blocking-b2g: backlog → 2.0?
QA Wanted for branch checks.
Keywords: qawanted
It could be related with bug 1034735. If after downloading the update, battery is under 25% then system won't allow to install it. But it seems not a regression to me as if you see the code you could check how, before the patch it is doing the same but for a fixed threshold of 50%.

May be it is an unexpected side effect but not a regression.
QA Contact: aalldredge
I am having some trouble getting this to reproduce, could I get some additional information on this issue? What build did you discover this issue on?
Flags: needinfo?(felash)
This is in a v2.0 nightly from about the date I reported the issue. I can try to reproduce on a newer v2.0 nightly (not now because my battery is high :) ).
Flags: needinfo?(felash)
:AdamA, can we help get this tested today, this has been sitting in the 2.0? queue for a while now, and triage was waiting on QA confirmation for it being a regression before making a call.
Flags: needinfo?(aalldredge)
I was unable to reproduce this issue. When I download the OTA it will uncompress and then show the "low battery" message. When the low battery message is dismissed the user can open the notification center and it says there is an update available. The user is prompted to download the update but the update is still stored so choosing to download the update immediately shows the "Low Battery" message. Restarting the phone at this point causes the phone to become updated because the update is stored on the device.

I tried this on 2 different builds around the time the bug was written as per comment 6.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140819000201
Gaia: 3df0c5f1ee3e208d1e8cbfe399baf1095e673c4f
Gecko: ef6277f356d9
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Repro rate: 0/5

BuildID: 20140820000201
Gaia: 88db39a0826086024631049d83ae6aa397f0918d
Gecko: 2092ac87eceb
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0.

Repro rate: 0/5

Comments:
I tried to reproduce this issue in both 512mb and 319mb but this result was the same in both configurations.
Flags: needinfo?(aalldredge) → needinfo?(bbajaj)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
I think I know what is different for my setup: I have _another_ update for an app. Since this update never works for this application (the offline manifest has an error), I uncheck the update for this app and then accept the system update.

Then the system update downloads, then uncompresses, then asks if it should be applied now. That's when the bug happens: I accept to update now, and then I have the "low battery" warning, and then I have the issue outlined in comment 0.

I hope you'll be able to reproduce now. I'm also removing the blocking request because it's probably happening since ages and it's more edge-casy.
blocking-b2g: 2.0? → ---
(In reply to Adam Alldredge [:AdamA] from comment #8)
> I was unable to reproduce this issue. When I download the OTA it will
> uncompress and then show the "low battery" message. When the low battery
> message is dismissed the user can open the notification center and it says
> there is an update available. The user is prompted to download the update
> but the update is still stored so choosing to download the update
> immediately shows the "Low Battery" message. Restarting the phone at this
> point causes the phone to become updated because the update is stored on the
> device.
> 
> I tried this on 2 different builds around the time the bug was written as
> per comment 6.
> 
> Environmental Variables:
> Device: Flame 2.0
> BuildID: 20140819000201
> Gaia: 3df0c5f1ee3e208d1e8cbfe399baf1095e673c4f
> Gecko: ef6277f356d9
> Version: 32.0 (2.0) 
> Firmware Version: v123
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> 
> Repro rate: 0/5
> 
> BuildID: 20140820000201
> Gaia: 88db39a0826086024631049d83ae6aa397f0918d
> Gecko: 2092ac87eceb
> Version: 32.0 (2.0) 
> Firmware Version: v123
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0.
> 
> Repro rate: 0/5
> 
> Comments:
> I tried to reproduce this issue in both 512mb and 319mb but this result was
> the same in both configurations.

Thanks, I agree with comment #9 for non-blocking in 2.0.
Flags: needinfo?(bbajaj)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
It can not be reproduced in latest maser V2.2. I have tried with same setting as described(have _another_ update for an app). Below is the test case
=> The "Battery too low" message is displayed.
=> The system update notification is not removed.
=> Tap on the system update and then tap download
=> It shows message about low battery.
=> Recharge the device and try again.
=> The system update install correctly. So it seems that the update file(.mar) is cached.

Environmental Variables:
Device: Keon V2.2
BuildID: 20141008012326
Gaia: 68b8bc9
Gecko: 652c5d4
Version: 35.0a1
Battery level: 16%
It can not be reproduced in Firefox OS V2.1. I have tried with same setting as described(have _another_ update for an app). The test case is same as above.

Environmental Variables:
Device: Keon V2.1
BuildID: 20141008125311
Gaia: d71f8804
Gecko: f4d4a81
Version: 34.0a2
After all, I have tried in Firefox OS 2.0 with same setting as described(have _another_ update for an app) and It can be reproduce there! The test case is as following.
=> The "Battery too low" message is displayed.
=> The system update notification is not removed.
=> Tap on the system update and then tap download
=> It shows message about low battery.
=> Recharge the device and try again.
=> a message prompt to "install" Tapping on install makes the download again from beginning. So it seems that the update file(.mar) is not cached.


Environmental Variables:
Device: Keon V2.0
BuildID: 20141008071705
Gaia: 31a49c7
Gecko: 8aa6a54
Version: 32.0
Battery: 21%
Flags: needinfo?(felash)
then I'll just close the bug if this is fixed in v2.1 and v2.2.

Thanks a lot for your testing!
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(felash)
Resolution: --- → WORKSFORME
bug is resolved - removing keywords
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.