883768 - [OTA] Device should not restart automatically to apply a system update in idle mode, which results in an unreachable state due to locked SIM

Status: RESOLVED FIXED

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

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/537f3eac4c48
Gaia   0c836be7f24693b74ad7fd21c8153824f1c7f548
BuildID 20130613230207
Version 18.0

I have had this a couple of times lately that I triggered an update check and let OTA download the update, but actually forgot to trigger its installation. After a couple of hours I re-checked my phone I see the enter PIN dialog which showed me that the device has been restarted. Sadly because of that I missed some important calls.

So even with the update downloaded we should never automatically restart the phone. Always the user should trigger the install with the required restart of the phone.

Comment 1

[Jason Smith [:jsmith]]

I don't understand this bug exactly. The OTA update process should be something like this:

1. Download the package
2. Uncompress it
3. Ask to install it now or wait until later
3a. If I install it now, the phone will be restarted to apply the update
3b. If I hit later, the phone should not be restarted and remain with an item in the notification bar allowing the user to install the update

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Jason Smith [:jsmith] from comment #1)
> 1. Download the package
> 2. Uncompress it
> 3. Ask to install it now or wait until later

Leave the phone with the screen turned off for that amount of time it usually needs to download and uncompress the update. Don't turn the screen on for 3). When i leave the phone in this state, it usually restarts itself after a period of time.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Henrik Skupin (:whimboo) from comment #2)
> (In reply to Jason Smith [:jsmith] from comment #1)
> > 1. Download the package
> > 2. Uncompress it
> > 3. Ask to install it now or wait until later
> 
> Leave the phone with the screen turned off for that amount of time it
> usually needs to download and uncompress the update. Don't turn the screen
> on for 3). When i leave the phone in this state, it usually restarts itself
> after a period of time.

Probably because the phone has decided to apply the OTA update in background without user decision and restart the phone upon completion. I think I might have seen this as well. Depending on how one would argue, this could this be by design.

Dave - What do you think?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I would disagree that something like that can be by design, if I stay half of a day as not reachable, because I haven't checked my phone during that time. Beside that it might be ok, if no SIM is inserted.

Comment 5

[Dave Hylands [:dhylands]]

This is by design.

Once the Later/Install dialog is presented, if the system remains idle for 10 minutes, then it will assume "Install".

Comment 6

[Jason Smith [:jsmith]]

That's what I thought. Thanks Dave. Invalid per comment 5.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Jason Smith [:jsmith] from comment #6)
> That's what I thought. Thanks Dave. Invalid per comment 5.

Please do not close bugs that hastily without thinking what could be wrong. Even if it was a design decision at a former time it does not mean that it was 100% correct and every possible path has been taken care of. Everyone makes mistakes. So I request that someone from the design team checks that request and we have to figure out if a change is necessary.

My points against this decision are:

* If the user has not accepted the installation at this time, we should not do this automatically. The same behavior you don't see in Firefox desktop, where we do not restart the browser after a version check if you were idle for a while. We apply the update in the background, but that's really all.

* An unexpected restart will cause your mobile availability to go down. Especially if you forgot to check your phone again, this can happen for a couple of hours. You will not be reachable via your phone number given that the PIN hasn't been entered yet.

* This is a potential factor for dataloss. You might have started to write a SMS but haven't sent it out yet. You got distracted for a moment (longer than such 10 minutes) and when you come back you see that your written and not sent message is gone. That's only one factor, and other applications might be more problematic. At least from Daniel I know that the music application does not store the current position of the song, so with a restart you will loose the current state. But well, not sure what idle means in detail here.

As you can see all those points are valid concerns for that behavior. So please give the design team the change to clear this up.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Henrik Skupin (:whimboo) from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > That's what I thought. Thanks Dave. Invalid per comment 5.
> 
> Please do not close bugs that hastily without thinking what could be wrong.
> Even if it was a design decision at a former time it does not mean that it
> was 100% correct and every possible path has been taken care of. Everyone
> makes mistakes. So I request that someone from the design team checks that
> request and we have to figure out if a change is necessary.

I would not think of this as a mistake in the design. I could see arguments for either approach. The original design decisions around system updates pushes heavily to get users to update via system updates as much as possible at the sacrifice of some UX to avoid OS fragmentation when the update is available. That was considered a critical requirement in old discussions.

However, whether we decide to address this or not, this isn't a blocker for ship. It's not new to 1.1 and not severe enough to block. I was asked to triage this, so I'm pulling the nom.

> 
> My points against this decision are:
> 
> * If the user has not accepted the installation at this time, we should not
> do this automatically. The same behavior you don't see in Firefox desktop,
> where we do not restart the browser after a version check if you were idle
> for a while. We apply the update in the background, but that's really all.

I don't believe the Desktop argument here is relevant. The argument for doing this via the phone was the use case of:

I've initiated downloading of a system update, left my phone running for 30 minutes. Download completed and install update prompt appeared. The install occurs in 10 minutes and restarts the phone to continue usage such that system updates in the background, so that when a user returns to using the phone, they have the latest bits ready to go and can still use their phone.

> 
> * An unexpected restart will cause your mobile availability to go down.
> Especially if you forgot to check your phone again, this can happen for a
> couple of hours. You will not be reachable via your phone number given that
> the PIN hasn't been entered yet.

It's temporary. When a system update applied in the background after 10 minute time limit is hit, the phone is restarted. So I don't understand how you would not be reachable for multiple hours.

> 
> * This is a potential factor for dataloss. You might have started to write a
> SMS but haven't sent it out yet. You got distracted for a moment (longer
> than such 10 minutes) and when you come back you see that your written and
> not sent message is gone. That's only one factor, and other applications
> might be more problematic. At least from Daniel I know that the music
> application does not store the current position of the song, so with a
> restart you will loose the current state. But well, not sure what idle means
> in detail here.

The SMS case is being handled later on by supporting drafts feature to handle that. Technically any of those scenarios can happen anyways if the app is killed in the background due to going past memory usage requirements. So I don't believe I would call this confirmed new data loss, so I'm pulling the keyword.

> 
> As you can see all those points are valid concerns for that behavior. So
> please give the design team the change to clear this up.

1. I don't understand the unreachable case.
2. The other two concerns raised I don't agree warrant defense on this bug - one violates the intention to avoid OS fragmentation with silent background updates & second does nothing different than what happens when an app gets killed in the background, so I would disagree it's any new data loss that couldn't already happen by design in how we manage apps on this system.

I can get a third opinion here from UX here.

Comment 9

[Jason Smith [:jsmith]]

Doing some reading, I'm guessing you are arguing for the unreachable case if you have a locked SIM. Someone would need to confirm that the following use case could happen:

If I have a locked SIM that I just unlocked, I download an OTA update, and OTA update gets applied in the background and the phone is restarted, am I still required to unlock my SIM? If so, then yes, the scenario is valid. If not, then that scenario present isn't relevant.

Comment 10

[Jason Smith [:jsmith]]

I'll put qawanted to see what happens in comment 9's test case.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Jason Smith [:jsmith] from comment #9)
> If I have a locked SIM that I just unlocked, I download an OTA update, and
> OTA update gets applied in the background and the phone is restarted, am I
> still required to unlock my SIM? If so, then yes, the scenario is valid. If
> not, then that scenario present isn't relevant.

Exactly that's my problem. Probably no-one here in Europe is having a phone with no PIN associated with the SIM card. We even get those shipped with a pre-defined PIN. So I wonder if that's different in the US or other parts of the world.

Comment 12

[Jason Smith [:jsmith]]

Note - although this is a valid concern, as I mentioned above, this won't block the release. We aren't blocking on any post 1.01 issues that are not regressions. This could be bumped into 1.2.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Jason Smith [:jsmith] from comment #12)
> regressions. This could be bumped into 1.2.

Would this be koi? Would you mind to adjust the flags as appropriate?

Comment 14

[Stephany Wilkes]

Assigning to Casey since this is System. Casey, let's see where this ends up; looks like it may be moving to koi.

Comment 15

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Has this behavior changed? I can't reproduce the automatic restart, at least with the last two update on the nightly channel of the 18.1 branch. Both the update prompt showing up while the lock screen was active (you can see the prompt for a split second when turning on the screen) and after unlocking the lock screen were left alone/idle for 15-35 minutes (last night the lock screen for hours).

Unagi with Gaia 1.1.0.0-prerelease 20130718070206 -> update to 2013071823.... (have to redownload the update due to bug 855420).

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It did not happen to me all the time. So I'm not sure in which exact state the device has to be left to make that automatic restart happen. But I will keep an eye on it.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This happened to me today again. I haven't updated my device since July 26th because I'm on vacation. Today I got network access and tried to update. The download of the update got stuck because I lost the connection to the network for a moment. Stopping and restarting the update worked, and after a while it switched to unpacking. I left the phone alone and noticed that it restarted automatically. It might be that an interruption of the download could trigger that behavior.

Comment 18

[Stephany Wilkes]

Flagging Neo since this seems like System Back-end. Neo, please reassign as appropriate.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I have some more information here. As it looks like the automatic restart happens when a formerly download of the upgrade gets aborted/stopped. With the following steps I can see the behavior a lot:

1. Check for updates
2. Start the download of the update
3. Wait a bit and stop the download
4. Re-start the download
5. Put the phone away and wait for the automatic restart

Comment 20

[Dave Hylands [:dhylands]]

It should automatically restart, even if you eliminate steps 3 and 4. I admit I haven't tested this recently, but that's how it used to work.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dave, please see comment 9 and ff. This behavior is IMHO not acceptable, given that this will cause a disconnect from the mobile network. If you do not cancel the download it never restarts automatically.

Comment 22

[Dave Hylands [:dhylands]]

I'm not arguing with you about what it should or shouldn't do, just about what it does do.

I did the following:
- flashed this image onto my unagi: https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18_v1_1_0_hd-unagi/2013/08/2013-08-12-04-22-03
- unpacked and ran this script: https://wiki.mozilla.org/File:Channel-setup.zip to switch the channel to nightly (for some reason the pvt build had the channel named "default").
- Went into settings and enabled remote debugging (so I could see the logcat)
- Did a Check Now, and asked it to download the system update
- Waited for about 15 minutes
- The phone automatically restarted into the new image (10 minutes after the download finished)

I didn't cancel the update and it restarted automatically (as expected).

The key messages from logcat are:

After the download completes, you should see (regardless of whether the download was interrupted or not):

    UpdatePrompt: Update is ready to apply, registering idle timeout of 600 seconds before prompting.

And then after 600 seconds of idle time:

    Idle timer callback: current idle time 600010 msec

and finally:

    UpdatePrompt: Timed out waiting for result, restarting
    UpdatePrompt: Update downloaded, restarting to apply it

and the phone restarts. During the time that it waits, I believe that there is a prompt on the screen saying that the update is ready to apply, and that you can choose to apply it now or later. And that prompt stays up for the whole 600 seconds, but my screen was blank so I couldn't tell.

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Oh, you are right. Just tested and it even happens then. :(

How can we request input from persons who work on the specs? I would really like that we get their feedback on that, especially regarding the SIM lock.

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This happened to me again a couple of times the last days, and is very annoying. I was unreachable for a couple of hours because I missed to check my phone after I have started to download the update. I haven't seen such a behavior from no other phone so far.

Can we please move forward here? How can I ask for feedback from the ux team?

Comment 25

[Dave Hylands [:dhylands]]

I've heard people mention "locked sim".

Is this an attribute of the SIM? Or can I lock a normal SIM?

How do I go about locking a SIM?

How do I detect a locked SIM?

So I agree that this is undesirable. I'm marking this to be looked at for koi? triage.

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dave, 'locked SIM' here means that a PIN has been set. As what I have heard on other bugs that doesn't seem to be the normal case in U.S, or people don't want it? But at least here in Europe most likely everyone has a PIN set for the SIM card, which has to be entered after startup to connect to the cell network. I hope that helps.

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Why got the koi? blocker request removed? Whether it should be accepted or denied by release drivers.

Comment 28

[Hema Koka [:hema]]

We already triaged this bug and decided to not make it a blocker. However, Dave is fixing this for 1.2 release (koi release)

Thanks
Hema

Comment 29

[Dave Hylands [:dhylands]]

Attachment: Don't use fallback timer when SIM is pin-locked.

Comment 30

[Dave Hylands [:dhylands]]

Attachment: Don't use fallback timer when SIM is pin-locked. v2

Comment 31

[Dave Hylands [:dhylands]]

https://hg.mozilla.org/integration/b2g-inbound/rev/b952c1662ddc

Comment 32

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b952c1662ddc