As part of the dawn project, we would like to migrate the current aurora population on nightly. Because Google play doesn't offer the capability to migrate applications population, reuse the aurora application (with renaming the app) would be the easiest. This solution adds some legacy and isn't perfect but is pretty easy to implement.

Guys, do you know who could do that? I could give it a try if it isn't too complex.

(Adding :nalexander and :rnewman to CC) I would like to (as a first step) continue to keep everything as-is (Building and Distributing Nightly and Aurora) and "only" build Aurora from mozilla-central instead of the aurora branch (I admit that I do not know what is needed for that). This will allow us to not depend on the Aurora branch without having to immediately migrate users somehow (or abandon them). After that has happened we can try to convince users (in app messaging?) to switch from the current Nightly builds to the Google Play / Aurora version. And as soon as those numbers are low enough stop shipping this build completely. (I used the term "Aurora" above - but I don't care much about if it is actually using the Aurora branding or the Nightly one - Aurora means org.mozilla.fennec_aurora in this case).

Yo! From a build-system perspective, I expect this to be pretty straight-forward. It looks like we just need to backport mobile/android/config/mozconfigs/android-api-15/{l10n-}nightly from mozilla-aurora to mozilla-central. Equivalently, looking at Looking at https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/merge_day/central_to_aurora.py, we need to * bump the branding; * remove "--enable-profiling"; * choose what l10n repository we're using. (If we don't copy from m-a to m-c, we'll also need to remove some updater bits.) Presumably we'll want to just update the package name rather than copy the mobile/android/branding/aurora path to /nightly. sledru: Is that correct -- we want Nightly, except for ANDROID_PACKAGE_NAME=org.mozilla.fennec_aurora?

This should be straight forward: * schedule extra 2 builds for arm and x86 using the adapted mozconfigs Nick mentioned in comment #3. This is in-tree. * single locale repacks are not needed - we don't publish them to the Play Store * publish org.mozilla.fennec_aurora and org.mozilla.fennec_beta at the same time. This is pushapk something something.

> * publish org.mozilla.fennec_aurora and org.mozilla.fennec_beta at the same time. This is pushapk something something. At first, we'll need to tweak the taskgraph to keep using the aurora scopes[1] on central. This shouldn't be a big thing. However, I'm not sure why we need to publish org.mozilla.fennec_aurora and org.mozilla.fennec_beta at the same time. What does it mean, to you, Rail? [1] https://dxr.mozilla.org/mozilla-central/rev/abf145ebd05fe105efbc78b761858c34f7690154/taskcluster/taskgraph/util/scriptworker.py#207

One other question: if we publish "Aurora" (repackaged Nightly) on Play Store, what are we going to do with FTP builds, both multi-locales and single-locale? Are we going to use actual Nightly builds for those? I understand the rationale for this choice, but it seems really confusing.

(In reply to Johan Lorenzo [:jlorenzo] from comment #5) > > * publish org.mozilla.fennec_aurora and org.mozilla.fennec_beta at the same time. This is pushapk something something. > At first, we'll need to tweak the taskgraph to keep using the aurora > scopes[1] on central. This shouldn't be a big thing. However, I'm not sure > why we need to publish org.mozilla.fennec_aurora and org.mozilla.fennec_beta > at the same time. What does it mean, to you, Rail? I mean that if the only difference of those builds are the APP ID, then we should publish at the same time.

Okay. Unless I'm missing something, we're required to publish them at the same time. On google play, aurora and beta are considered as different products. In other words, Google doesn't check the APP IDs between aurora and beta. This means, we can publish whenever we want.

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #7) > I mean that if the only difference of those builds are the APP ID, then we > should publish at the same time. This is a misunderstanding. They are different. At the end of all this the result will be: * Nightly (org.mozilla.fennec_aurora) - Built from mozilla-central [Right now this is Aurora build from mozilla-aurora] * Beta (org.mozilla.firefox_beta) - Built from mozilla-beta * Release (org.mozilla.firefox) - Built from mozilla-release All those versions will be available on Google Play. Our current Nightly builds (org.mozilla.fennec) are not on Google Play and will be discontinued at some point (We would like to continue building them for now so that we have time thinking about what's the best strategy to communicate this to the small group of users).

(In reply to Sebastian Kaspari (:sebastian) from comment #9) > * Nightly (org.mozilla.fennec_aurora) - Built from mozilla-central [Right > now this is Aurora build from mozilla-aurora] An open question is what happens to features that are only available on Aurora or Nightly, but not both. Presumably the Gecko crew is working on making those same choices and altering their flags to match. On mobile we need to do three things: - Keep up with any platform changes that might affect us. - Find any features we've enabled in one or the other, and figure out what to do with those features. - Communicate the differences. > All those versions will be available on Google Play. Our current Nightly > builds (org.mozilla.fennec) are not on Google Play and will be discontinued > at some point (We would like to continue building them for now so that we > have time thinking about what's the best strategy to communicate this to the > small group of users). We should almost certainly continue building and archiving Nightly independent of its publishing to Play — installing earlier signed builds for testing is important, we will do the builds anyway to publish them to Play, and the folks who use them are the folks who really care. The remaining question is whether we continue to support the updater, and I think there is likely enough weight behind it that we should, but that's really independent of making Nightly APKs available.

(In reply to Sebastian Kaspari (:sebastian) from comment #9) > (In reply to Rail Aliiev [:rail] ⌚️ET from comment #7) > > I mean that if the only difference of those builds are the APP ID, then we > > should publish at the same time. > > This is a misunderstanding. They are different. At the end of all this the > result will be: > > * Nightly (org.mozilla.fennec_aurora) - Built from mozilla-central [Right > now this is Aurora build from mozilla-aurora] > * Beta (org.mozilla.firefox_beta) - Built from mozilla-beta > * Release (org.mozilla.firefox) - Built from mozilla-release > > All those versions will be available on Google Play. Our current Nightly > builds (org.mozilla.fennec) are not on Google Play and will be discontinued > at some point (We would like to continue building them for now so that we > have time thinking about what's the best strategy to communicate this to the > small group of users). Agree and here's what I have in mind (other than the general PR/communication that we will do for both Desktop/Mobile) Regarding aurora to nightly migration, we should update the Google Play page with proper messages and also an in app message upon first launch after the migration to let the user know what just happened and why the app's name and icon changed. Preferably this same in app message shouldn't appear for a new install of nightly from Google Play but if it's too much effort we can likely work around it. Regarding nightly (from download page) migration to nightly (on Google Play), we should have an in-app message asking the users to download nightly from Google Play and remove their existing nightly as it will no longer receive future updates.

(In reply to Richard Newman [:rnewman] from comment #10) > An open question is what happens to features that are only available on > Aurora or Nightly, but not both. > > Presumably the Gecko crew is working on making those same choices and > altering their flags to match. > > On mobile we need to do three things: > > - Keep up with any platform changes that might affect us. > - Find any features we've enabled in one or the other, and figure out what > to do with those features. > - Communicate the differences. Not sure if there is an easy way to do so? Given the aurora audience is quite limited, and our PR/communication will explain clearly on why we are doing so, we may not need to have this level of details. > > We should almost certainly continue building and archiving Nightly > independent of its publishing to Play — installing earlier signed builds for > testing is important, we will do the builds anyway to publish them to Play, > and the folks who use them are the folks who really care. Agree > The remaining question is whether we continue to support the updater, and I > think there is likely enough weight behind it that we should, but that's > really independent of making Nightly APKs available. the nightly population is "very very" limited and much less than aurora. I think it makes more sense to ask this super limited audience to download the "new" nightly again and from there and on, updates will be coming from Google Play.

(In reply to Joe Cheng [:jcheng] (please needinfo) from comment #11) > Regarding nightly (from download page) migration to nightly (on Google > Play), we should have an in-app message asking the users to download nightly > from Google Play and remove their existing nightly as it will no longer > receive future updates. Can you clarify what's the destiny for Nightly builds on FTP, both multi and single locale? I've heard concerns in the past about using Play Store as the only distribution channel, for people who can't or don't want to use it to install an app on their phone.

(In reply to Francesco Lodolo [:flod] from comment #13) > (In reply to Joe Cheng [:jcheng] (please needinfo) from comment #11) > > Regarding nightly (from download page) migration to nightly (on Google > > Play), we should have an in-app message asking the users to download nightly > > from Google Play and remove their existing nightly as it will no longer > > receive future updates. > > Can you clarify what's the destiny for Nightly builds on FTP, both multi and > single locale? > > I've heard concerns in the past about using Play Store as the only > distribution channel, for people who can't or don't want to use it to > install an app on their phone. it's open for discussion but I think we should still provide FTP downloads as usual, similar to release and beta where we encourage users to download from Google play but you can still find links to download directly from mozilla. but with regard to automatic app updates, given the build is to be on Google Play, my proposal is to use Google Play for automatic app updates like Release and Beta and the updater that we currently have with nightly is to be removed.

I think you should open a separate bug for the ftp discussion. Here, it is just about the apk id :)

Thought I'd leave a reminder: our Firefox Account types on Android are tied to release channel via the package name: 27: public static final String MOZ_ANDROID_SHARED_FXACCOUNT_TYPE = "@ANDROID_PACKAGE_NAME@_fxaccount"; I know the plan is for existing Aurora users to preserve both signing key and package name, and simply build from another channel, but it would be worth explicitly testing that accounts aren't dropped when upgrading.

What do you think ? https://reviewboard.mozilla.org/r/131162/ (I haven't been able to test that, I don't know how to use that stuff :/

With: ac_add_options --with-branding=mobile/android/branding/aurora it seems it is working

Comment on attachment 8859114 [details] Bug 1354821 - Generate fennec nightly apk with org.mozilla.fennec_aurora as id https://reviewboard.mozilla.org/r/131162/#review134334 LGTM!

Pushed by sledru@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d95142b6ad4b Generate fennec nightly apk with org.mozilla.fennec_aurora as id r=rail

(In reply to Sylvestre Ledru [:sylvestre] from comment #18) > What do you think ? https://reviewboard.mozilla.org/r/131162/ (I haven't > been able to test that, I don't know how to use that stuff :/ Yes, I expect this will produce org.mozilla.fennec_aurora but with Nightly branding. I think rnewman's https://bugzilla.mozilla.org/show_bug.cgi?id=1354821#c16 is worth manually testing, although I don't expect an issue.

We may want to use one of the Google Play controlled distribution methods to verify that this pave-over works as expected. https://support.google.com/googleplay/android-developer/answer/3131213?hl=en

(In reply to Kevin Brosnan [:kbrosnan] from comment #25) Good idea! Let me detail what we may need to do. We publish aurora on Google Play's beta track already[1] (values defined at [2]). This allows us to display the warning on [3]: > ⚠️ This is an unreleased app. It may be unstable. and to have users to explicitly subscribe to a test program. Hence, we may want to use the alpha track for this scenario. However, we would require an extra subscription for users, which means we: * either test it internally * or communicate about this with the community. What's release management's POV on this? Should we open a new bug for it? [1] https://tools.taskcluster.net/task-inspector/#Uf_dBSlqSWSpdw_c8Inqog/ [2] https://dxr.mozilla.org/mozilla-central/rev/27311156637f9b5d4504373967e01c4241902ae7/taskcluster/taskgraph/util/scriptworker.py#215 [3] https://play.google.com/store/apps/details?id=org.mozilla.fennec_aurora

I was mainly thinking email based control. SV and a few Mozilla people to make sure that pave over installs don't hit any flags. These should be glaring stuff like signatures for the apk not matching or sync breaking.

yes, we can use the alpha track of the aurora app to test. Good idea