Make sure that we actually lazily initialize our storage layers.
With this patch applied, storage layers (history, logins, bookmarks) will be initialized when first
accessed. We will no longer block GeckoEngine init, for example, on waiting for the logins storage
to initialize (which needs to access the costly securePrefStorage).
Similarly, BackgroundServices init will no longer require initialized instances of the storage
components - references to their "lazy wrappers" will suffice.
In practice, this change changes when our storage layers are initialized in the following ways.
Currently, we will initialize everything on startup. This includes loading our megazord, as well.
With this change, init path depends on if the user is signed-into FxA or not.
If user is not an FxA user:
- on startup, none of the storage layers are initialized
- history storage will be initialized once, whenever:
- first non-customTab page is loaded (access to the HistoryDelegate)
- first interaction with the awesomebar
- history UI is accessed
- bookmarks storage will be initialized once, whenever:
- something is bookmarked, or we need to figure out if something's bookmarked
- bookmarks UI is accessed
- logins storage will be initialized once, whenever:
- first page is loaded with a login/password fields that can be autofilled
- (or some other interaction by GV with the autofill/loginStorage delegates)
- logins UI is accessed
- all of these storages will be initialized if the user logs into FxA and starts syncing data
- except, if a storage is not chosen to be synced, it will not be initialized
If user is an FxA user:
- on startup, none of the storage layers are initialized
- sometime shortly after startup is complete, when a sync worker runs in the background, all storage
layers that are enabled to sync will be initialized.
This change also means that we delay loading the megazord until first access (as described above).
As far as I can tell, we never actually exercise the a-s libraries in Fenix tests currently (this was one of the presumed reasons for having a direct dependency).
In a different branch I've started work on adding end-to-end tests, but currently that's blocked on trying to figure out to load native libraries in tests (somehow, fenix's setup is different than what we have in A-C, not yet clear to me in what way).
Another reason for a direct dependency (i think) is that we needed it to configure a `fenix` megazord. This could be solved via a `support-megazord-fenix` a-c component that provides the correct transient dependencies,
but we can also just switch to use the `full` megazord instead, which is essentially what fenix megazord is at this point. A-S team wants to remove the fenix megazord, so this will help. This is what this patch does.
Added kapt plugin + dependencies in order to be able to use Room
Added recent apps to share fragment (top 6)
Extracted dimens of share_to_apps.xml in the dimens file
Add a custom detekt rule to blacklist certain properties. This is
immediately useful for making sure that developers do not configure
runtime behavior using the `BuildConfig.DEBUG` property but it is
useful in a wider context.
This removes Fretboard. The goal is to reduce cold startup costs associated with loading the experiments on the main thread. We currently have two experiments frameworks in use and should only require one.
* For https://github.com/mozilla-mobile/fenix/issues/7410: rewrite updateBookmarkFromObservableInput with coroutines
* For 7410: remove RxJava from project. :(
* For 7410: converted updateBookmarkFromTextChanges to Flow per review
