Need an updater for Fennec on Android

VERIFIED FIXED

Status

Firefox for Android Graveyard
General
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: alexp, Assigned: alexp)

Tracking

Trunk
All
Android
Dependency tree / graph
Bug Flags:
in-litmus +

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Assignee)

Description

8 years ago
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)

Updated

8 years ago
Assignee: nobody → alexp
Status: NEW → ASSIGNED
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0b1+
(Assignee)

Updated

8 years ago
Depends on: 593242
(Assignee)

Comment 1

8 years ago
Created attachment 472118 [details] [diff] [review]
[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.
(Assignee)

Comment 2

8 years ago
Created attachment 472119 [details] [diff] [review]
[WIP] Update hack - mobile

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

Comment 4

8 years ago
(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.

Updated

8 years ago
Blocks: 554249
(Assignee)

Updated

8 years ago
Depends on: 594238
(Assignee)

Updated

8 years ago
Depends on: 594549

Comment 5

8 years ago
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.
(Assignee)

Updated

8 years ago
Depends on: 594897
(Assignee)

Comment 6

8 years ago
Created attachment 473707 [details] [diff] [review]
[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.
Attachment #472119 - Attachment is obsolete: true
(Assignee)

Comment 7

8 years ago
Created attachment 473714 [details] [diff] [review]
[WIP] Update service

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
(Assignee)

Comment 8

8 years ago
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.
(Assignee)

Updated

8 years ago
Attachment #473714 - Flags: review?(robert.bugzilla)
(Assignee)

Updated

8 years ago
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+
(Assignee)

Comment 10

8 years ago
(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.
(Assignee)

Updated

8 years ago
Depends on: 595384
(Assignee)

Comment 11

8 years ago
Created attachment 474298 [details] [diff] [review]
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.
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.
(Assignee)

Comment 14

8 years ago
(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.
(Assignee)

Comment 16

8 years ago
(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.
(Assignee)

Comment 19

8 years ago
(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.
(Assignee)

Updated

8 years ago
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
Last Resolved: 8 years ago
Resolution: --- → FIXED

Updated

8 years ago
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.