1525904 - Investigate ways of making glean a "null-op" dependency

Status: RESOLVED WONTFIX

(Data Platform and Tools :: Glean: SDK, enhancement, P3)

Description

[Alessio Placitelli [:Dexter]]

Components in android-components do not necessarily want an hard dependency on glean. Moreover, due to the fact that glean has an high level API that gets generated at runtime, disabling glean would imply that all the calls to such API would need to be protected or shimmed, in case glean was not available.

This bug is for investigating ways in which glean could still create a stub API, but making all the operations no-op.

Comment 1

[Alessio Placitelli [:Dexter]]

Notes from the related discussion with Sebastian: https://docs.google.com/document/d/14nHysJV3RUDuYYJHFgsBViSM9wSYwXCjQRSkJTRZ8fE/edit

Comment 2

[Michael Droettboom [:mdroettboom]]

LeakCanary has an example of this pattern in a Java app: https://github.com/square/leakcanary

Comment 3

[Michael Droettboom [:mdroettboom]]

An initial experiment with this approach: https://github.com/mozilla-mobile/android-components/compare/master...mdboom:noop?expand=1

Comment 4

[Michael Droettboom [:mdroettboom]]

Attachment: GitHub Pull Request

Comment 5

[Michael Droettboom [:mdroettboom]]

There seems to be a philosophical objection to conditional compilation in Kotlin, because it makes IDE things a lot harder. Therefore, I don't think there's any form of annotation that will let us build this from the same source tree.

There might, however, be ways to enforce that the no-op library has the same public API as the real one:

There are a number of tools (japi-compatibility-checker, clirr, sigtest) that can compare the public APIs of a jar file. All of these seem to suffer from various forms of bitrot, unfortunately.

That leaves us with a couple of other options:

• Create abstract interfaces for the public API in a third library. Both the no-op and real libraries would implement these interfaces, and we let the compiler check it for us.

• Wait until we have a rust core and deal with this at the rust level. The Kotlin API would remain a thin wrapper around the rust core, which would then either be real or no-op.

Comment 6

[Michael Droettboom [:mdroettboom]]

:pocmo -- I thought it would be worth checking in with you about this again. It's proving difficult to do this well. How much of a priority does it remain?

Comment 7

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Michael Droettboom [:mdroettboom] from comment #6)

:pocmo -- I thought it would be worth checking in with you about this again. It's proving difficult to do this well. How much of a priority does it remain?

Very low.

Fenix is currently mapping generic "facts" that our components emit to glean events here:
https://github.com/mozilla-mobile/fenix/blob/4b4d172e2e03dcc320d57573cc2042951ce18f82/app/src/main/java/org/mozilla/fenix/components/metrics/Metrics.kt#L122

That works fairly well and should be good enough for the MVP.

Comment 8

[Michael Droettboom [:mdroettboom]]

The move to the Rust-based Glean core implementation potentially makes this easier.

We could no-op everything on the Rust side of the FFI quite easily by parsing the generate C FFI header and providing no-op functions for each of those. Users would continue to use the language-specific frontends. The payload size would still be larger than it needs to be (since the frontends contain non-trivial things like the ping uploader), but it would be impossible to collect telemetry in this case and the hot path of collecting telemetry would be much faster.