Hi folks, I think everyone is aware that we have good support for using Android Studio and IntelliJ to develop the Firefox for Android Java code base. This support is built on Gradle because the IDEs use Gradle's project model as their project representation. However, Gradle gives us more than just IDE integration: it is the best (and in some cases, the only) way to use new Android build system features provided by Google. I wrote about the gains we might see from using Gradle more than a year ago [1] and the argument is only stronger today. So let's deprecate our existing moz.build system and use Gradle during |mach build|.
The good news first: technically, most of the work to produce a build with Gradle is already done. I messaged about testing --with-gradle recently [2], and you can see a green automation try build at [3]. Now the bad news, and where I would appreciate your help: a lot of things can go wrong when making large build changes like this! Process costs ============= A switch like this needs to ride the trains for safety. The switch needs to identify itself in some way, so that we can correlate issues in the product with the build tooling used to produce specific versions. In addition, the switch cannot prevent us from uplifting patches. That means that we will need to maintain the existing moz.build system until we're building Fennec Release with Gradle. The big file renaming patch that unlocked a lot of our IDE experience was hard for the sheriffs; I'd like to make their lives as easy as possible. We can add TaskCluster jobs building "the opposite" configuration easily, thereby ensuring that both the moz.build and Gradle configuration stay green. Technical concerns ================== I have assembled a list to which I would very much like to add your concerns and considerations. * differences in the output of the javac compiler; * differences in the code stripped or optimized by Proguard; * differences in the Android support library versions we use with moz.build and Gradle; * differences in the APK badging, including: ** changed permissions; ** changed Android package names; ** changed version codes. * differences in the Android resources: ** how we access packages by name; ** android:// Fennec references. * problems migrating backward and forward between moz.build and Gradle: ** with our own UpdateService (Nightly); ** with the Google Play Store (Release and Beta). * differences in the Telemetry and Adjust data collected; * changes to Android integration points, including: ** missing home screen icons; ** missing dock icons; ** missing Android Account objects; ** confused PendingIntents, Alarms, notifications. * changes to the l10n process. If you can think of a part of Fennec that you have seen differences at runtime between the moz.build and the Gradle versions, please respond to this message. (I will respond to this separately explaining why I think specific concerns will not cause problems and how we might verify that unexpected changes haven't happened.) Tentative plan ============== I would like to try a "controlled burn": I would like to work with QA to produce a targeted upgrade/downgrade manual test sign-off process, and then try to build Nightly with Gradle for a day (or several), then revert to |moz.build|. Our testing population is small, but this should reveal catastrophic failures. The next uplift is in slightly over a month (2016-04-18, see [4]), so I'd like to try to do this test during March. If there are schedule considerations, please raise them here. tl;dr: let's build with Gradle! Yours, Nick [1] http://www.ncalexander.net/blog/2015/01/05/we-should-build-firefox-for-android-with-an-external-build-system/ [2] https://mail.mozilla.org/pipermail/mobile-firefox-dev/2016-March/001846.html [3] https://treeherder.mozilla.org/#/jobs?repo=try&revision=1c94bb43e168 [4] https://wiki.mozilla.org/RapidRelease/Calendar
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
