We need to support the following use cases:

• Different components using glean must contribute to the same ping payload

• Fretboard must be able to call Glean.setActiveExperiment/setInactiveExperiment

• Individual libraries can define and use their own metrics

  • e.g. Preferences page might want to record how often specific preferences are changed

• Individual libraries can use metrics defined in other libraries

  • e.g. For search, we may have a counter for search engine used that would be updated from awesomebar and from in content search

• GeckoView may be able to use whatever approach we come up with for this -- or it could remain special cased

This bug is primarily a meta bug to track these related investigations. Implementation into actual mergeable PRs will probably be files as separate bugs.

First successful experiment:

• Metrics defined in glean itself can be updated by third-party libraries. (Side question: Is this an encapsulation violation we want to close off?)

• Basic core Glean API (like setExperimentEnabled) can be called from a third-party library.

This information all ends up in a single storage engine, and sent in a single ping on a single cadence.

Second successful experiment:

• Metrics defined in a third-party library (fretboard) can be used from fretboard, and they end up being sent in the common pings on the regular cadence.

 {
      "metrics": {
        "counter": {
          "fretboard.calls": 1   <--- This comes from fretboard
        },
        "string": {
          "glean.baseline.os": "Android",
          "glean.baseline.os_version": "27",
          "glean.baseline.device": "Google-Android SDK built f",
          "glean.baseline.architecture": "x86"
        }
      },
      "ping_info": {
        "ping_type": "baseline",
        "telemetry_sdk_build": "0.40.0",
        "experiments": {
          "FretboardIntegrationExperiment": {
            "branch": "special"   <--- This also comes from fretboard
          }
        },
        "seq": 9,
        "app_build": "1",
        "app_display_version": "1.0",
        "client_id": "529d4119-9faa-4ff8-bd67-dca724098686",
        "start_time": "2019-01-28T17:55-05:00",
        "end_time": "2019-01-28T17:55-05:00"
      }
    }

Ongoing work can be seen at this link:

https://github.com/mozilla-mobile/android-components/compare/master...mdboom:third-party

I consider all of the use cases confirmed as easily doable with the exception of:

Individual libraries can use metrics defined in other libraries

Based on discussion in the meeting, I think we actually want better encapsulation of this. Libraries can either define the same metric an another library (which we won't exclude), or libraries can provide a public API to modify a particular metric.