Closed Bug 1148257 Opened 9 years ago Closed 9 years ago

[3.0] [ota] ota updates not being checked automatically on the flame, have to check manually

Categories

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

defect
Not set
normal

Tracking

(blocking-b2g:2.2+, b2g-v2.2 verified, b2g-master fixed)

VERIFIED FIXED
2.2 S10 (17apr)
blocking-b2g 2.2+
Tracking Status
b2g-v2.2 --- verified
b2g-master --- fixed

People

(Reporter: Jamie_, Assigned: kgrandon)

References

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150127140910

Steps to reproduce:

on the flame running 3.0 master nightly the device is not checking automatically for updates.

Flame
appid 	{3c2e2abc-06d4-11e1-ac3b-374f68613e61}
apptype	b2g
vendor	Mozilla
name 	B2G
version	3.0.0.0-prerelease
appbuildid	20150326160206
platformbuildid	20150326160206
platformversion	39.0a1
geckobuildid	20150326160206
geckoversion	39.0a1
changeset   	59554288b4eb
locale	                en-US
os             	B2G
hardware    	qcom
processor   	arm
compiler     	eabi

1.) when there is an update available
2.) have the device set to check daily for updates
3.) wait 24 hrs. to wait for it to update


Actual results:

The updates are not notified or checked from what it seems. You have to go in a check manually for the updates from the device information tab and check the updates and then pull down the notification bar to do the updates


Expected results:

The device should check automatically for the updates and put it in the notification bar that there is an update
qawanted, please confirm.
Keywords: qawanted
okay, I know there is an update right now... I have not updated yet today an the flame has still not checked for updates on its own like it should be.
There are smoketest blockers so they turned off OTA to latest on 3.0 master. The latest you can update to for now is the build on 3/25.
This is more than just recent... I have had this problem as far as I know since I flashed 3.0... The only way it checks for updates is if the phone is restarted for some odd reason.
Works for me using 3.0. I checked manually a few minutes ago (18:05 ART Time - 21:05 hs UTC) and I was notified of today's OTA update which I proceeded to download and install without any further issue.

The last time I had received an OTA update before the actual one was March 26 at the same time as today.
Its supposed to check automatically if I have it set to check daily. It should pop up in the notification bar, I have to check manually from the info section of settings before it pops up in the notifications bar.
I reproduced the issue as well after a full flash and I did not reboot.  Update using the 18D_nightly image, and then let the phone sit.  I think the full flash of the phone doesn't initialize the variables.

After rebooting the device, I checked the settings using nightly desktop browser's webide and going to device settings:
app.update.interval : 86400
deviceinfo.last_updated : 1403989921167
gaia.system.checkForUpdates : false
gecko.updateStatus : check-error-2153389949

Also side note : 
time.clock.automatic-update.enabled false
time.timezone.automatic-update.enabled false

It might have to do with the change to the userdebug now that I think about it...
Not 100 % sure as of yet.  In any cases, setting this to new for now as I confirmed the issue.

I changed some settings on my device : 
gaia.system.checkForUpdates true
time.clock.automatic-update.enabled true
time.timezone.automatic-update.enabled true
Status: UNCONFIRMED → NEW
Ever confirmed: true
[ note, the last bit of what I mentioned is that I'm testing to see if that pref turned off is the cause of it not updating, I also reselected daily in the settings. ]

needinfo'ing myself for further follow up on this bug.
Flags: needinfo?(nhirata.bugzilla)
the phone got turned off, and back after the pref change; having said that, it seems like having the prefs turned on caused the phone to check.  The work around is to turn the pref : gaia.system.checkForUpdates  on.
The other prefs may have to do with daylight savings time corrections and such...

Now I have to hunt down why that pref is turned off and whether or not it has to do with being a userdebug build.
still investigating : 
bug 952912 shows that it should be true whether or not you skip or finish the ftu.

from bug 879192:
SettingsListener.observe('gaia.system.checkForUpdates', false,
                             this.checkForUpdates.bind(this));

Also to note, the common-settings is also set to false by default:
http://mxr.mozilla.org/gaia/source/build/config/common-settings.json#64
from Bug 954441 - Add more verification to integration test on build system 

Searching the bug lists, it seems like notifications for apps in general was turned off?
I think bug 1030626 may be related to this bug.

Thinking about this, maybe we can override in the production settings...
pinging kgrandon for help in regards to the build system.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(kgrandon)
Comment on attachment 8590539 [details] [review]
[gaia] KevinGrandon:bug_1148257_production_check_updates > mozilla-b2g:master

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #10)
> Thinking about this, maybe we can override in the production settings...
> pinging kgrandon for help in regards to the build system.

Sure, this is possible, though doesn't this get set to true when you change the value to "Daily" in the settings app? I'm not sure if it will change anything, but seems like a reasonable thing to have on for production builds.

Ricky - could you review this patch when you get a chance? Thanks!
Flags: needinfo?(kgrandon)
Attachment #8590539 - Flags: review?(ricky060709)
Comment on attachment 8590539 [details] [review]
[gaia] KevinGrandon:bug_1148257_production_check_updates > mozilla-b2g:master

r+ for the one line patch.
Attachment #8590539 - Flags: review?(ricky060709) → review+
Not sure if this will work, but let's try it.
Assignee: nobody → kgrandon
Component: Gaia::Settings → Gaia::Build
Keywords: checkin-needed
http://docs.taskcluster.net/tools/task-graph-inspector/#gs1s8GqvTxeZLm4ge7X8Fw

The pull request failed to pass integration tests. It could not be landed, please try again.
Oops, fixed a unit test and trying again.
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Naoki - Can you verify this one?
Flags: needinfo?(nhirata.bugzilla)
Whiteboard: [systemsfe]
Target Milestone: --- → 2.2 S10 (17apr)
Noming for v2.2; we should turn on the flag for 2.2 production as well.


I pulled in master, and adb pushed gaia, and checked the settings.json:  "gaia.system.checkForUpdates":true
verified that the settings is turned on in the repo.

We'll need to wait for a rel eng build before signing off. ( tomorrow or the next work day )
blocking-b2g: --- → 2.2?
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(nhirata.bugzilla)
Keywords: qawantedverifyme
blocking-b2g: 2.2? → 2.2+
"gaia.system.checkForUpdates":true
in today's build, at the same time I think I flashed either thursday or friday's build and OTA didn't show?

Flashed today's build, will see tomorrow.
we have some smoke test blockers today so the build isn't being pushed.
still need to wait for a good build.
Verified that you get the dialog without having to manually check

Serial: 1b3cc2b0 (State: device)
Build ID               20150416010206
Gaia Revision          629097847567e51095a454e7e63186a6e2ac0307
Gaia Date              2015-04-15 23:16:16
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/a35163f83d22
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150416.043752
Firmware Date          Thu Apr 16 04:38:00 EDT 2015
Bootloader             L1TC000118D0
Status: RESOLVED → VERIFIED
Flags: needinfo?(nhirata.bugzilla)
Please request Gaia v2.2 approval on this patch when you get a chance.
Flags: needinfo?(kgrandon)
Comment on attachment 8590539 [details] [review]
[gaia] KevinGrandon:bug_1148257_production_check_updates > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Missing implementation detail most likely.
[User impact] if declined: Poor update experience.
[Testing completed]: Manual and unit testing.
[Risk to taking this patch] (and alternatives if risky): Low risk, self-contained patch.
[String changes made]: None.
Flags: needinfo?(kgrandon)
Attachment #8590539 - Flags: approval-gaia-v2.2?(bbajaj)
Attachment #8590539 - Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+
could you help verify?
Flags: needinfo?(pcheng)
qawanted to verify this issue on 2.2.
Flags: needinfo?(pcheng)
Keywords: qawanted
I can check 2.2 over the weekend. I flashed to today's 2.2 and verified that "gaia.system.checkForUpdates" is set to true. I'll connect to wifi and check whether it checked for update on Monday.
Unable to verify this issue today on Flame 2.2 as blocked by bug 1165195.
QA Whiteboard: [QAnalyst-Triage?]
Depends on: 1165195
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Repeat of comment 28 on latest 2.2. Will report back results on Monday.
QA Contact: pcheng
The device did not check for update on v2.2. This morning I had to manually hit "Check Now" for it to check that there's a system update available for download.

Tested on:
Device: Flame (319MB, KK, full flashed)
BuildID: 20150626002504
Gaia: 1f8981d7872e3c0053571c26fb3edaf401844d75
Gecko: 2f8b845e5fa3
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

NI assignee for failed verification on 2.2.
QA Whiteboard: [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
Flags: needinfo?(kgrandon)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Naoki - you had done some investigation previously on this for 3.0, but I guess it was only verified for 3.0 and not 2.2?

Any ideas what might be happening here on 2.2?
Flags: needinfo?(kgrandon) → needinfo?(nhirata.bugzilla)
I thought that 2.2 was no longer receiving nightly updates due to reaching code complete, the only updates should be for security updates and major patches i thought.
Jamie_ there's still some movement on 2.2.  Not much but some maintenance work so having this patch helps.

kgrandon, the backend was busted for 2.2 and wcosta just fixed it recently.
If hitting the button causes the build to be found, it's no longer a backend issue.

Without any logs and seeing what behaviors is occuring, I would say that something else is causing the issue on the client side.  We would need to do some reinvestigation in order to figure out what's happening.  I think getting some logcat statement around the timer for OTA checks would be helpful.  If you can give us a patch for that then we can probably start investigation through that.
Flags: needinfo?(kgrandon)
Seems like the issue on 2.2 might be different. Perhaps we should file a new bug for this?
Flags: needinfo?(kgrandon)
I flashed to the Flame 2.2 build from 6/26 and got the update to the 6/29 build automatically without me tapping "Check now". This seems to have been fixed. 

Before OTA

Device: Flame 2.2
BuildID: 20150626162505
Gaia: 0179935627012dfde3ca036c9a71035be463b7ad
Gecko: 330f52ef6a2d
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

After OTA:

Device: Flame 2.2
Build ID: 20150629162503
Gaia: b39d4f5b4937592ded19ec65e113a74177ae1f86
Gecko: cefa70ef71e4
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


This still broken on Flame 2.5 but this is being tracked in bug 1175361.
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage+]
Keywords: verifyme
Depends on: 1175361
NI myself to recheck this on 2.2.
Flags: needinfo?(pcheng)
The issue is still occurring. I've filed bug 1179854 for the issue observed on 2.2.
Flags: needinfo?(pcheng)
Flags: needinfo?(nhirata.bugzilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: