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

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.

This is already on file.

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.

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.

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.

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

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.

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.

This is important for MozillaOnline as well.

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?

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.

> 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?

Yeah, I think we need to review Google TOS to make sure Aurora isn't violating it.

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

I've opened bug 1351793. If anyone wants to be cced, let me know. I put no one extra by default.

Legal would say that offer should only be open to employees and NDA'ed Mozillains.

(In reply to Kevin Brosnan [:kbrosnan] from comment #23) > Legal would say that offer should only be open to employees and NDA'ed > Mozillains. Sorry, I am not English-native speaker, so I may not get the nuance, but what "would" means here? WONTFIX for this bug? If so, it would be probably better to say so.

Could someone please check with legal what the are actually saying about this. And if it is a no, what are the possibilities to apply for an exception. I know many F-Droid users which are confused in what to use. For those interested, have a look at: - https://f-droid.org/packages/#q=firefox - https://f-droid.org/packages/#q=icecat - https://gitlab.com/fdroid/fdroiddata/issues?state=all&search=firefox - https://gitlab.com/fdroid/rfp/issues?state=all&search=firefox It would not be beneficial for Mozilla if old (and less safe) versions are being offered and used by non-advanced users. On the other hand, F-Droid is an important distribution channel, especially for more advanced uses, such as FOSS developers that also contribute to Mozilla projects. There are more apps, such as OsmAnd, which have given written permission in the form of an exception that their app is allowed to be distributed by F-Droid. Additionally, F-Droid also reports on the reproducibility when they are building, which also an advantage for Mozilla.

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.