[Settings] Modified automatic selection of network operator setting is NOT migrated after OTA upgrade from 2.0 to 2.1

NEW
Unassigned

Status

Firefox OS
Gaia::Settings
3 years ago
3 years ago

People

(Reporter: YeojinC, Unassigned)

Tracking

({dataloss})

unspecified
ARM
Gonk (Firefox OS)
dataloss

Firefox Tracking Flags

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

Details

(Whiteboard: [2.1-flame-test-run-3][systemsfe])

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Created attachment 8502628 [details]
logcat_20141009_AfterOTANetworkOperator.txt

Description:
After user switched the automatic selection to be OFF under Settings> Cellular & Data> Network operator, the automatic selection is turned ON after performing OTA upgrade to 2.1.

Repro Steps:
1) Update a Flame device to 2.0 BuildID: 20141008000202
2) Change update channel and url on device to appropriate 2.1 build (20141009000203).
3) Go to Settings> Cellular & Data> Network operator.
4) Turn off Automatic selection.
5) Perform OTA upgrade.
6) After upgrade is complete, go to Settings> Cellular & Data> Network operator.

Actual:
Automatic selection is switched ON.

Expected:
Automatic selection is switched OFF as the user turned it off before the upgrade.

[Before OTA - Flame 2.0]
  
Environmental Variables:
Device: Flame 2.0 (319mb, Full Flash)
BuildID: 20141008000202
Gaia: 31a49c7932c7085961760a6bef9ed381ea38d7e3
Gecko: a2d707e79061
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
  
[After OTA - Flame 2.1]

Environmental Variables:
Device: Flame 2.1
BuildID: 20141009000203
Gaia: 7e2ef41d3ac98757acaf490b5413fb42061ad3e6
Gecko: 75ebb70f8b38
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Repro Frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/11469/
See attached: logcat, screenshot
(Reporter)

Comment 1

3 years ago
This issue also reproduces when the upgrading from Flame 2.1 to Flame 2.2:

[Before OTA - Flame 2.1]

Environmental Variables:
Device: Flame 2.1 (319mb, Full Flash)
BuildID: 20141008000201
Gaia: d71f8804d7229f4b354259d5d8543c25b4796064
Gecko: 7fa82c9acdf2
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

[After OTA - Flame 2.2]

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141009040206
Gaia: 7b92615bdc97e5c675cd385ec68bc5e47e0c5288
Gecko: f0bb13ef0ee4
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Automatic selection is switched ON after the upgrade.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
(Reporter)

Comment 2

3 years ago
Created attachment 8502630 [details]
AutomaticOperatorNotMigrated
(Reporter)

Updated

3 years ago
Whiteboard: [2.1-flame-test-run-3][systemfe] → [2.1-flame-test-run-3][systemsfe]
All information should be saved and kept the same after an update. NI FTE owner to see if this should block
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris) → needinfo?(mozillamarcia.knous)
Need info on jlorenzo since this is his area - jlorenzo I am assuming that this setting should not be set back, but maybe there are specs or a definition of what is supposed to happen here.
Flags: needinfo?(mozillamarcia.knous) → needinfo?(jlorenzo)
This test case exists since 1.3 and I am not aware of a modification in that area. Do you confirm, Wilfred?
Flags: needinfo?(jlorenzo) → needinfo?(wmathanaraj)
best person to know would be peter - i am starting to look at it as of 2.2 so back history i do not know.
Flags: needinfo?(wmathanaraj) → needinfo?(pdolanjski)
I doubt we had specific requirements for this, but in general we shouldn't be changing user settings after an OTA update.

Is this a regression in 2.0->2.1 or did this happen in previous releases?  
If it is not a regression, I wouldn't block on this but we should certainly prioritize it to get fixed.
Flags: needinfo?(pdolanjski) → needinfo?(jlorenzo)
QA wanted to check OTA update from 1.3 (v123 base and the latest 1.3 gaia shallow-flashed on top of it) to 2.0.
Flags: needinfo?(jlorenzo)
Keywords: qawanted
QA Contact: aalldredge
Hi Johan-

If I perform this 1.3 to 2.0 OTA test today, should I still move back to the v123 jellybean base to do so, or should I remain on v188 base since we've moved to it since the request was made? 

Thank you!
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jlorenzo)
(In reply to Rachel Pribble [:rpribble] from comment #9)
Yes. Flash your device back to v123 base image, and then apply the latest commit in 1.3 gaia branch. After that, execute the OTA to 2.0 normally.
Flags: needinfo?(jlorenzo)
I've just been informed that OTAing from 1.3 to 2.0 on the v123 base is no longer possible since focus has now moved to the KK base, so I am unable to complete this request.
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: aalldredge
You need to log in before you can comment on or make changes to this bug.