Closed Bug 587384 Opened 9 years ago Closed 9 years ago

Need an updater for Fennec on Android

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set

Tracking

(fennec2.0b1+)

VERIFIED FIXED
Tracking Status
fennec 2.0b1+ ---

People

(Reporter: alexp, Assigned: alexp)

References

Details

Attachments

(2 files, 3 obsolete files)

Fennec upgrades to the new releases will be handled automatically through Android Market, but a similar functionality is needed for Alpha/Beta versions and nightly builds.
Assignee: nobody → alexp
Status: NEW → ASSIGNED
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0b1+
Depends on: 593242
Attached patch [WIP] Update service hack (obsolete) — Splinter Review
WIP version of the updater. This draft implementation checks for an update in background every several hours (depending on the prefs), when update is available it downloads the .APK file and shows a status bar notification. When user clicks on that, it launches the .APK to reinstall Fennec.

The final implementation should notify the user when update is available, and start downloading only when user agrees. It requires more changes to the update service, and the UI elements used by it.
Attached patch [WIP] Update hack - mobile (obsolete) — Splinter Review
Preferences for the update service, and a test function to force the update download (using Menu button).
Alex, glad to see this is coming along! I'll try to put aside some time next week to look at the patches, etc.
(In reply to comment #3)

Please note it is a very raw version just to see if it's possible to use this approach.

Eventually we will probably use the way very similar to Firefox, just have to make the UI a bit less obtrusive and add some mobile specifics.
Depends on: 594238
Depends on: 594549
When we branch mozilla-2.0, if we want to have updates for both mozilla-2.0 and mozilla-central, we'll have to add ac_add_options --enable-update-channel=CHANNELNAME in the mozconfig.

I can handle the mozconfig side; just making sure that the update channel set by autoconf is used for Android.
Depends on: 594897
Attached patch [WIP] Update hack - mobile (obsolete) — Splinter Review
WIP changes to test the update service: preferences, and a test function to force the update check using the Menu button.
Attachment #472119 - Attachment is obsolete: true
Use .apk instead of .mar.
The update service doesn't seem to need major changes to make it work on Android.
Attachment #472118 - Attachment is obsolete: true
The current approach is as follows:
- The background update service checks for updates periodically
- When update is available a notification is shown: "Get the new version..." (see bug 594238 for our new nsIUpdatePrompt implementation)
- When user confirms the update, it starts downloading
- On download completion, another notification is shown: "Install the new version..."
- When it's clicked, Fennec restarts
- On startup GeckoAppJava checks for a downloaded update.apk file, launches it, and writes the "succeeded" status to the update.status file (see bug 594897)

There are some questions and concerns:
- Is there anything else required? For example, does UpdateDriver need any changes?
- Do we need any additional manipulation with the status file and/or updates database?
- What exact preferences do we need to make this machinery work how we want it? For example, how to make the update service do the first check for an update earlier (if we need this)? "app.update.lastUpdateTime.background-update-timer=1" pref doesn't seem to work.
Attachment #473714 - Flags: review?(robert.bugzilla)
Depends on: 594986
Comment on attachment 473714 [details] [diff] [review]
[WIP] Update service

Looks fine though it isn't clear to me how this actually will get applied based on the existing patches. From the patches in this bug I don't think you want toolkit/xre/nsAppRunner calling ProcessUpdates in nsUpdateDriver and you shouldn't build in toolkit/mozapps/update/src/ since you aren't using the updater.

I'll try to put together comments regarding implementation details outside of app update later.
Attachment #473714 - Flags: review?(robert.bugzilla) → review+
(In reply to comment #9)
> Looks fine though it isn't clear to me how this actually will get applied based
> on the existing patches.

Can you elaborate please? What exactly are you concerned about?

> From the patches in this bug I don't think you want
> toolkit/xre/nsAppRunner calling ProcessUpdates in nsUpdateDriver and you
> shouldn't build in toolkit/mozapps/update/src/ since you aren't using the
> updater.

That's right. I will file a separate bug to disable the updater for Android.
Depends on: 595384
app.update.enabled=true -- enable updates;
app.update.timerFirstInterval=20000 -- do the first update service call earlier;
app.update.auto=false -- notify the user before starting download;
app.update.download.backgroundInterval=0 -- make download faster.
Attachment #473707 - Attachment is obsolete: true
Attachment #474298 - Flags: review?(robert.bugzilla)
(In reply to comment #11)
> Created attachment 474298 [details] [diff] [review]
> Tweaked preferences for the update service
> 
> app.update.enabled=true -- enable updates;
This will default to true
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#288

I mention this because I've noticed that Fennec typically doesn't add preferences unless they are different than the default value. It is each apps choice whether to do this or not so I am not saying you shouldn't.

> app.update.timerFirstInterval=20000 -- do the first update service call
> earlier;
> app.update.auto=false -- notify the user before starting download;
> app.update.download.backgroundInterval=0 -- make download faster.
Having a slower background download interval keeps us from killing the mirror servers when a huge number of clients are download an update. You should run this by IT so they are aware that the clients will be downloading the update at full speed.
(In reply to comment #10)
> (In reply to comment #9)
> > Looks fine though it isn't clear to me how this actually will get applied based
> > on the existing patches.
> 
> Can you elaborate please? What exactly are you concerned about?
You download the update but it isn't clear to me from the current set of patches how it will be applied after it is downloaded.
(In reply to comment #13)
> You download the update but it isn't clear to me from the current set of
> patches how it will be applied after it is downloaded.

As mentioned in my comment #8 it is handled in Java, and the change is in a separate bug 594897.
Sorry about that, when I last went through the dependencies there wasn't a patch for reference. I'll comment over in bug 594897.
(In reply to comment #12)
> > app.update.enabled=true -- enable updates;

> This will default to true
> I mention this because I've noticed that Fennec typically doesn't add
> preferences unless they are different than the default value. It is each apps
> choice whether to do this or not so I am not saying you shouldn't.

Makes sense.
We may just remove it then.

> > app.update.download.backgroundInterval=0 -- make download faster.
> Having a slower background download interval keeps us from killing the mirror
> servers when a huge number of clients are download an update. You should run
> this by IT so they are aware that the clients will be downloading the update at
> full speed.

This will probably be the only way how we download the update. We won't have a real foreground download like in Firefox, so the way we use is "background" only from the UI point of view.
But you are right - we have to decide how exactly we want to do this, and if the update servers will be able to handle such load.
Comment on attachment 474298 [details] [diff] [review]
Tweaked preferences for the update service

These are all fine by me though I am not a peer of this code so you should get someone that is to r+ it.

One item of note is that
>+pref("app.update.auto", false);
makes it so the user will always be prompted which I assume is what you want.
Attachment #474298 - Flags: review?(robert.bugzilla) → review+
(In reply to comment #16)
> (In reply to comment #12)
> > > app.update.enabled=true -- enable updates;
> 
> > This will default to true
> > I mention this because I've noticed that Fennec typically doesn't add
> > preferences unless they are different than the default value. It is each apps
> > choice whether to do this or not so I am not saying you shouldn't.
> 
> Makes sense.
> We may just remove it then.
Just noticed that many of the prefs have been added since I last looked so I don't think it is worth removing.

> > > app.update.download.backgroundInterval=0 -- make download faster.
> > Having a slower background download interval keeps us from killing the mirror
> > servers when a huge number of clients are download an update. You should run
> > this by IT so they are aware that the clients will be downloading the update at
> > full speed.
> 
> This will probably be the only way how we download the update. We won't have a
> real foreground download like in Firefox, so the way we use is "background"
> only from the UI point of view.
> But you are right - we have to decide how exactly we want to do this, and if
> the update servers will be able to handle such load.
It is more about how it is initiated vs. having UI. If the user does a manual check and it is downloaded it should be a foreground download. If the download is initiated by a background update check (app.update.auto would need to be true) then it wouldn't be a foreground download and since the user isn't aware of the download it can download it slowly.
(In reply to comment #18)
> > This will probably be the only way how we download the update. We won't have a
> > real foreground download like in Firefox, so the way we use is "background"
> > only from the UI point of view.
> It is more about how it is initiated vs. having UI. If the user does a manual
> check and it is downloaded it should be a foreground download. If the download
> is initiated by a background update check (app.update.auto would need to be
> true) then it wouldn't be a foreground download and since the user isn't aware
> of the download it can download it slowly.

We'll probably have a combination of those (at least for now). The check for an update is done automatically in background, but the download is supposed to be initiated by the user when a notification comes up. Downloading will be happening at maximal speed, but there will be no full-screen UI, probably only a small animated icon will be shown in a status bar (still a todo), then again the user will be notified about the update ready to be installed.
Attachment #474298 - Flags: superreview?(mark.finkle)
Comment on attachment 474298 [details] [diff] [review]
Tweaked preferences for the update service

looks fine to me. r+ is enough
Attachment #474298 - Flags: superreview?(mark.finkle) → review+
Comment on attachment 474298 [details] [diff] [review]
Tweaked preferences for the update service

Pushed to mobile-browser:
http://hg.mozilla.org/mobile-browser/rev/40d8fc8429fb
pushed http://hg.mozilla.org/mozilla-central/rev/f61962db89a0
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Flags: in-litmus?
verified : 
Mozilla/5.0 (Maemo;Linux armv71; rv:2.0b7pre)Gecko/20101007 Firefox/4.0b7pre Fennec/4.0b2pre

Beta 1 is on a different channel but does have prefs for update
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus?(nhirata.bugzilla)
You need to log in before you can comment on or make changes to this bug.