This patch integrates relevant a-c components, and updates the current Preferences
UI to allow signing-in and displaying basic account information (email, displayName).
Currently there's no Accounts UI, and so singing out or otherwise interacting with the
account isn't possible.
* greenfield (pure Fenix without anything added)
* firefoxNightly (To replace Firefox Nightly)
* firefoxBeta (To replace Firefox Beta)
* firefoxRelease (To replace Firefox Release)
For now it will be a bit annoying to have all those flavors. But once the transition has been
successfully completed we can start to tear them down again.
Once GeckoView universal builds are available we can get rid of the "abi" dimension.
If this is going to slow down the CI process then I might look into parallelizing the build
or potentially introducing a taskcluster CI setup (if that makes sense).
The Android Lifecycle Architecture component does not have fine-grained enough lifecycle event callbacks to safely manage Rx subscriptions in Fragment lifecycles. Added autodispose to simplify.
This fixes a regression from https://github.com/mozilla-mobile/fenix/pull/294
That patch adds a dependency which loads some native libraries. Those native libs are
shipped for a variety of architectures. Specifically, there are versions of aarch64 and armv7.
What seems to happen is that since those libraries are loaded first (GV is lazily initialized
after history stuff), and since aarch64 versions of these libs is chosen by the native loader,
consequent native loads select for the same abi type. aarch64 version of libmozglue isn't there,
loader fails to find it and we crash.
Being explicit with the abiFilter in the product flavour definitions strips out aarch64 app-services
libs from the apk. When they're loaded first, armv7 versions are picked (since we don't have any other
ones), and everything works correctly afterwards.
Another way to achieve the same result would be to exclude arm64 libs via packagignOptions directive:
packagingOptions { exclude "lib/arm64-v8a/**" }
... but that's a less flexible approach in the longer term.
