587384 - Need an updater for Fennec on Android

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Alex Pakhotin (:alexp)]

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.

Comment 1

[Alex Pakhotin (:alexp)]

Attachment: [WIP] Update service hack

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.

Comment 2

[Alex Pakhotin (:alexp)]

Attachment: [WIP] Update hack - mobile

Preferences for the update service, and a test function to force the update download (using Menu button).

Comment 3

[Robert Strong (they/them - no direct email)]

Alex, glad to see this is coming along! I'll try to put aside some time next week to look at the patches, etc.

Comment 4

[Alex Pakhotin (:alexp)]

(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.

Comment 5

[Aki Sasaki (not active)]

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.

Comment 6

[Alex Pakhotin (:alexp)]

Attachment: [WIP] Update hack - mobile

WIP changes to test the update service: preferences, and a test function to force the update check using the Menu button.

Comment 7

[Alex Pakhotin (:alexp)]

Attachment: [WIP] Update service

Use .apk instead of .mar.
The update service doesn't seem to need major changes to make it work on Android.

Comment 8

[Alex Pakhotin (:alexp)]

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.

Comment 9

[Robert Strong (they/them - no direct email)]

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.

Comment 10

[Alex Pakhotin (:alexp)]

(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.

Comment 11

[Alex Pakhotin (:alexp)]

Attachment: Tweaked preferences for the update service

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.

Comment 12

[Robert Strong (they/them - no direct email)]

(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.

Comment 13

[Robert Strong (they/them - no direct email)]

(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.

Comment 14

[Alex Pakhotin (:alexp)]

(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.

Comment 15

[Robert Strong (they/them - no direct email)]

Sorry about that, when I last went through the dependencies there wasn't a patch for reference. I'll comment over in bug 594897.

Comment 16

[Alex Pakhotin (:alexp)]

(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 17

[Robert Strong (they/them - no direct email)]

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.

Comment 18

[Robert Strong (they/them - no direct email)]

(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.

Comment 19

[Alex Pakhotin (:alexp)]

(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.

Comment 20

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 474298 [details] [diff] [review]
Tweaked preferences for the update service

looks fine to me. r+ is enough

Comment 21

[Matt Brubeck (:mbrubeck)]

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

Comment 22

[Brad Lassey [:blassey] (use needinfo?)]

pushed http://hg.mozilla.org/mozilla-central/rev/f61962db89a0

Comment 23

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 24

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=13647
https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=13648 (beta channel testing)