Provide an easy-to-use update-method for users without Play store access

REOPENED
Unassigned

Status

()

Firefox for Android
General
REOPENED
2 years ago
an hour ago

People

(Reporter: Boris Kraut, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150806192140

Steps to reproduce:

0. Don't have play-store installed.

1. Download and install a (non-current) release build from the FTP server (e.g. https://ftp.mozilla.org/pub/mozilla.org/mobile/releases/).

2. Wait




Actual results:

No update notices is shown.


Expected results:

Release builds should provide an update (or at least an update notice) if a newer version is available and the updates are not managed by the playstore (e.g. not installed).
(Reporter)

Updated

2 years ago
OS: Unspecified → Android
Hardware: Unspecified → All
(Reporter)

Comment 1

2 years ago
I talked to the people in #releng and #mobile and while all agree that it is a bad thing to have users without easy updates at all, my proposed solution was rejected: The updater from beta/nightly builds can not be used because this could confuse "regular" play-store users (amongst other problems).
Richard, I think you have some context here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(rnewman)
This is already on file.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(rnewman)
Resolution: --- → DUPLICATE
Duplicate of bug: 1019724
Actually not quite a dupe; perhaps a dependency.

Bug 1019724 is intended to address a different and more specific objective: an update path for users who aren't served at all by the locales we ship in Play, or users of single-locale builds in general.

This bug applies not only to single-locale builds but also to multi-locale builds: exactly the builds we ship in Play.

The reason I don't think this is a dupe is that single locale builds *are different*, and so our potential solutions are different. A solution we blindly apply to that .multi build will affect Play builds, and we don't want that.

I recently discovered that we do include the updater in all Mozilla builds; indeed, it hits the network from release! We just don't serve up any builds for it.

Addressing this bug would likely involve a little client-side work, perhaps a small amount of build work -- perhaps the builds we upload to Play need an updater URL that's different -- and of course some work behind the scenes.

But we need to decide if we should do that work. We probably should, even though the number of potential users isn't large; we have a fair number of Kindle Fire users who are users of Aurora so that they have a working updater.

I don't have the cycles to devote to this right now, but I think it's worth leaving open.
Status: RESOLVED → REOPENED
Depends on: 1019724
Resolution: DUPLICATE → ---
Facebook was soundly slapped by Google when they tried to update their users outside the Play Store. http://www.theverge.com/2013/3/15/4109528/facebook-updating-android-app-outside-google-play-test-new-features

I can't see how Google will allow us to go down this path.
(Reporter)

Comment 6

2 years ago
Well, I don't know what would be the appropriate way to deal with this. However, some solutions I could think of:

* Check if the play-store is installed (or If an account exists to access it).
* Don't update, but prompt the user that he might be using an outdated version of Firefox (either timebased or by poking archive.mozilla.org or something..) along with options where to get newer versions.
Depends on: 1220773
:kbrosnan I'm not sure if this is an option worth visiting but perhaps their can be a check to see if the device has play-store and if not offer update via the updater that nightly uses? Seems like a simple enough check and a good way to support third-party stores like F-Droid.
Depends on: 1226511
Duplicate of this bug: 1234108
See Also: → bug 1241114
To re-summarize, with Bug 1220773 fixed, we could:

* Know whether we were installed via Play or not.
* Supply this as an argument to Balrog in our updater check.

It would then be possible to publish ordinary multi-locale APKs to Balrog and serve them up to non-Play users, and -- barring any unknown complications -- this would just work. Play users wouldn't get updates, and non-Play users would.

Comment 10

8 months ago
Note that this might be handy for some of our random distributions as well. We occasionally get one offs that don't have Google Play services.

Comment 11

5 months ago
This is important for MozillaOnline as well.
Blocks: 1093113
I'd love to help make this happen!  I'm working on F-Droid as part of Guardian Project and we're working to address exactly these kinds of use cases.

About the Google Play Terms of Service, it is correct that apps distributed via Play are not allowed to update via outside channels.  There are a number of apps that support this in the APKs that are shipped via Google Play (WhatsApp, Signal, etc).  They do this by disabling the self-updating when Google Play is present.  We're making a library to handle this, and have already discussed this with some Googlers.  Once the library is complete, we're going to ask our Google contacts to vet it in terms of Play ToS.

I think its also important to note the f-droid.org use case: the main repo is 100% free software, except for official Firefox APKs (they include proprietary Google libs needed for WebRTC/voice/video to work).  We want to make the main repo have no exceptions any more. What would be perfect is if Mozilla ran an fdroid repo of their builds, then we can add that to the F-Droid client app, and users would just need to go to the prefs and turn on a switch, and they'd get official Firefox releases.

The aforementioned library for self-updating then will also use this same fdroid repo to get updates when devices have neither Google Play nor F-Droid.
We're scoping out the final shape that this library should take, we'd love feedback since we want to cover the Firefox use case:
https://gitlab.com/fdroid/fdroidclient/issues/852
Note that we already have (in theory) everything in place now:
* We haven an updater that we use in Aurora and Nightly
* We now run a check that determines whether we have been installed from Google Play or somewhere else
* We deployed Aurora to Google Play and it now uses either its own updater or lets Google Play handle it.

So I guess the "only" things left are:
* Making sure that our server knows about and servers builds of beta/release
* Making sure that our clients query the correct server/URL in beta/release
* Enable the updater code in beta/release and test
Thanks for the update!  Did you receive any feedback from Google about including the updater in the Google Play releases?

Comment 16

5 months ago
We already included the updater in our Google Play Aurora release, it's just not used if you downloaded from Google Play.

For reference:

Setting MOZ_UPDATER in configure.sh for release/beta would allow this.

Need to make sure anybody that preloads gets their updates from Google Play if they want it.

And we need to figure out who we can get from build to help us test putting a beta/release build onto the update servers.
(In reply to Mike Kaply [:mkaply] from comment #16)
> We already included the updater in our Google Play Aurora release, it's just
> not used if you downloaded from Google Play.
> 
> For reference:
> 
> Setting MOZ_UPDATER in configure.sh for release/beta would allow this.
> 
> Need to make sure anybody that preloads gets their updates from Google Play
> if they want it.
> 
> And we need to figure out who we can get from build to help us test putting
> a beta/release build onto the update servers.

This would technically violate Google's TOS my team has an update in some of our android work but we use a build flag so it's only enabled for our non-google play builds for things like f-droid.

Comment 18

5 months ago
> This would technically violate Google's TOS my team has an update in some of our android work but we use a build flag so it's only enabled for our non-google play builds for things like f-droid.

That would mean our Aurora build is violating Google's TOS. We currently have one build that updates differently based on where it is downloaded...

We're getting the installerPackageName to know.
Mike, Elvin, does this need review from the legal team?
Flags: needinfo?(mozilla)
Flags: needinfo?(ellee)

Comment 20

3 months ago
Yeah, I think we need to review Google TOS to make sure Aurora isn't violating it.
Flags: needinfo?(mozilla)
The review should be a separate legal bug with a minimal number of people cc'ed on it. https://bugzilla.mozilla.org/enter_bug.cgi?product=Legal

Comment 22

3 months ago
I've opened bug 1351793. If anyone wants to be cced, let me know. I put no one extra by default.
Flags: needinfo?(ellee)
Legal would say that offer should only be open to employees and NDA'ed Mozillains.
Depends on: 1351793
See Also: → bug 1357364

Updated

2 months ago
See Also: → bug 1357362
You need to log in before you can comment on or make changes to this bug.