Closed Bug 799482 Opened 12 years ago Closed 12 years ago

[OTA update] No way of resuming after app crashes

Categories

(Firefox OS Graveyard :: General, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)

VERIFIED FIXED
B2G C2 (20nov-10dec)
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: tchung, Assigned: marshall)

References

Details

(Whiteboard: [ota update])

Attachments

(1 file)

Attached file logcat
+++ This bug was initially created as a clone of Bug #791829 +++

Dupe me, if i'm bug 791829.  Started on a 10-08-2012 daily build.

This morning, i got an OTA update available to download on its own.   When prompted to download in the dialog, i tapped it but then the screen crashed.

After resuming from the crash, the updater dialog never came back.   

Attached a logcat of the event, but i didnt find anything useful.  Maybe someone else sees something? 


Steps to reproduce:

1. load the 2012-10-08us build onto an otoro phone
2. wait until OTA finds an update, and then look for the system notification indicating an update is available
3. proceed to download the update.  At this point, the screen crashes (i dont know how to reproduce this part)
4. upon screen recovery, verify no update notification resumes or ever prompts me again to download.

Expected:
- updater resumes in the background, or reprompted after a crash

Actual:
- crash kills the updater, never to be seen again.
resetting blocking-basecamp for triage to view.   might be a dupe, but want marshall to take a look first.
blocking-basecamp: + → ?
Summary: [OTA update] No way of resuming a stopped/partial update → [OTA update] No way of resuming after app crashes
Marshall told me on IRC that this is not likely a dupe of bug 791829.
Assignee: nobody → marshall
blocking-basecamp: ? → +
Can we get some testing around whether bug 798948 will be a plausible workaround on this one?  I realize reproducing the crash during update might not be possible - if there's a way to gauge how much we should let this block dogfooding that would be a big help here, any ideas for forcibly crashing during update to test this would be welcome.
Severity: normal → critical
Priority: -- → P1
Whiteboard: [ota update] → [ota update][dogfooding-blocker]
What is the status here. This is a critical dogfooding blocker. Please post an ETA to fix this.
I have yet to reproduce the crashing in the middle of the update.  But i have tested that forcing update if i kill the download, will restart a full update mar.  So i could live with dogfoodblocking- if we are time crunched.
Thank you Tony, given that we can force updates now to override glitches during an update, we can remove blocking.
Whiteboard: [ota update][dogfooding-blocker] → [ota update]
It isn't clear to me what the cause of this crash is. The log provided doesn't give any insight to if / when there was a crash.. 

Tony, have you seen this again since you filed it?
Flags: needinfo?(tchung)
QA Contact: tchung
(In reply to Marshall Culpepper [:marshall_law] from comment #7)
> It isn't clear to me what the cause of this crash is. The log provided
> doesn't give any insight to if / when there was a crash.. 
> 
> Tony, have you seen this again since you filed it?

Nope, i have not crashed since when updating.  we can potentially mark this resolved:wfm, and hope that fixing bug 791829 would fix this.
Flags: needinfo?(tchung)
I suspect that bug 791829 fixed this.  We should test whether updates resume after the b2g process is forceably crashed while in the middle of downloading an update.  This command will kill the b2g process

$ adb shell kill -9 `adb shell b2g-ps | grep 'b2g ' | awk '{print $3}'`

After the b2g process restarts, AUS should come back after the first-poll timer and resume downloading the update.  Also, a force-check should resume the download.
Keywords: qawanted
Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.
Target Milestone: --- → B2G C2 (20nov-10dec)
I pinged QA to see if they can reproduce this.
The update resumes after crashing.

There's no notification that it's downloading, but that's a separate less-critical issue that I'll file.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified update resumes now after crashing and restarting.  tested on 12/14 build
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: