{"id":313,"date":"2021-07-26T10:18:53","date_gmt":"2021-07-26T10:18:53","guid":{"rendered":"https:\/\/blog.mozilla.org\/data\/?p=313"},"modified":"2021-07-26T10:18:53","modified_gmt":"2021-07-26T10:18:53","slug":"this-week-in-glean-shipping-glean-with-geckoview","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/data\/2021\/07\/26\/this-week-in-glean-shipping-glean-with-geckoview\/","title":{"rendered":"This Week in Glean: Shipping Glean with GeckoView"},"content":{"rendered":"

(\u201cThis Week in Glean\u201d is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean.) All \u201cThis Week in Glean\u201d blog posts are listed in the TWiG index<\/a> (and on the Mozilla Data blog<\/a>).<\/p>\n

\n

Glean SDK<\/h2>\n

The Glean SDK is Mozilla\u2019s telemetry library, used in most mobile products and now for Firefox Desktop as well. By now it has grown to a sizable code base with a lot of functionality beyond just storing some metric data. Since its first release as a Rust crate in 2019 we managed to move more and more logic from the language SDKs (previously also known as \u201clanguage bindings\u201d) into the core Rust crate. This allows us to maintain business logic only once and can easily share that across different implementations and platforms. The Rust core is shipped precompiled for multiple target platforms, with the language SDK distributed through the respective package manager.<\/p>\n

I talked about how this all works in more detail last year<\/a>, this year<\/a> and blogged about it in a previous TWiG<\/a>.<\/p>\n

GeckoView<\/h2>\n

GeckoView<\/a> is Mozilla\u2019s alternative implementation for WebViews on Android, based on Gecko, the web engine that also powers Firefox Desktop. It is used as the engine behind Firefox for Android<\/a> (also called Fenix). The visible parts of what makes up Firefox for Android is written in Kotlin, but it all delegates to the underlying Gecko engine, written in a combination of C++, Rust & JavaScript.<\/p>\n

The GeckoView code resides in the mozilla-central repository, next to all the other Gecko code. From there releases are pushed to Mozilla\u2019s own Maven repository<\/a>.<\/p>\n

One Glean too many<\/h2>\n

Initially Firefox for Android was the only user of the Glean SDK. Up until today it consumes Glean through its release as part of Android Components<\/a>, a collection of libraries to build browser-like applications.<\/p>\n

But the Glean SDK is also available outside of Android Components, as its own package. And additionally it\u2019s available for other languages and platforms too, including a Rust crate<\/a>. Over the past year we\u2019ve been busy<\/a> getting Gecko to use Glean through the Rust crate to build its own telemetry on top.<\/p>\n

With the Glean SDK used in all these applications we\u2019re in a difficult position: There\u2019s a Glean in Firefox for Android that\u2019s reporting data. Firefox for Android is using Gecko to render the web. And Gecko is starting to use Glean to report data.<\/p>\n

That\u2019s one Glean too many if we want coherent data from the full application.<\/p>\n

Shipping it all together, take one<\/h2>\n

Of course we knew about this scenario for a long time. It\u2019s been one of the goals of Project FOG to transparently collect data from Gecko and the embedding application!<\/p>\n

We set out to find a solution so that we can connect both sides and have only one Glean be responsible for the data collection & sending.<\/p>\n

We started with more detailed planning all the way back in August of last year and agreed on a design in October. Due to changed priorities & availability of people we didn\u2019t get into the implementation phase until earlier this year.<\/p>\n

By February I had a first rough prototype in place. When Gecko was shipped as part of GeckoView it would automatically look up the Glean library that is shipped as a dynamic library with the Android application. All function calls to record data from within Gecko would thus ultimately land in the Glean instance that is controlled by Fenix. Glean and the abstraction layer within Gecko would do the heavy work, but users of the Glean API would notice no difference, except their data would now show up in pings sent from Fenix.<\/p>\n

This integration was brittle. It required finding the right dynamic library, looking up symbols at runtime as well as reimplementing all metric types to switch to the FFI API in a GeckoView build. We abandoned this approach and started looking for a better one.<\/p>\n

Shipping it all together, take two<\/h2>\n

After the first failed approach the issue was acknowledged by other teams, including the GeckoView and Android teams.<\/p>\n

Glean is not the only Rust project shipped for mobile, the application-services team<\/a> is also shipping components written in Rust. They bundle all components into a single library, dubbed the megazord<\/a>. This reduces its size (dependencies & the Rust standard library are only linked once) and simplifies shipping, because there\u2019s only one library to ship. We always talked about pulling in Glean as well into such a megazord, but ultimately didn\u2019t do it (except for iOS builds<\/a>).<\/p>\n

With that in mind we decided it\u2019s now the time to design a solution, so that eventually we can bundle multiple Rust components in a single build. We came up with the following plan:<\/p>\n