| ActivationPing.kt |
Ensures that only one activation ping is ever sent.
(Taken from Fenix)
|
2631 |
| BrowsersCache.kt |
Caches the list of browsers installed on a user's device.
BrowsersCache caches the list of installed browsers is gathered lazily when it is first accessed
after initial creation or invalidation. For that reason, a context is required every time
the cache is accessed.
Users are responsible for invalidating the cache at the appropriate time. It is left up to the
user to determine appropriate policies for maintaining the validity of the cache. If, when the
cache is accessed, it is filled, the contents will be returned. As mentioned above, the cache
will be lazily refilled after invalidation. In other words, invalidation is O(1).
This cache is threadsafe.
|
1529 |
| FactsProcessor.kt |
Processes all [Fact]s emitted from Android Components based on which the appropriate telemetry
will be collected.
|
3081 |
| FenixProductDetector.kt |
|
1583 |
| GleanMetricsService.kt |
Glean telemetry service.
To track events, use Glean's generated bindings directly.
|
11651 |
| MetricsService.kt |
A service for tracking telemetry events in various parts of the app.
|
502 |
| ProfilerMarkerFactProcessor.kt |
A fact processor that adds Gecko profiler markers for [Fact]s matching a specific format.
We look for the following format:
```
Fact(
action = Action.IMPLEMENTATION_DETAIL
item = <marker name>
)
```
This allows us to add profiler markers from android-components code. Using the Fact API for this
purpose, rather than calling [Profiler.addMarker] directly inside components, has trade-offs. Its
downsides are that it is less explicit and tooling does not work as well on it. However, we felt
it was worthwhile because:
1. we don't know what profiler markers are useful so we want to be able to iterate quickly.
Adding dependencies on the Profiler and landing these changes across two repos hinders that
2. we want to instrument the code as close to specific method calls as possible (e.g.
GeckoSession.loadUrl) but it's not always easy to do so (e.g. in the previous example, passing a
Profiler reference to GeckoEngineSession is difficult because GES is not a global dependency)
3. we can only add Profiler markers from the main thread so adding markers will become more
difficult if we have to understand the threading needs of each Profiler call site
An additional benefit with having this infrastructure is that it's easy to add Profiler markers
for local debugging.
That being said, if we find a location where it would be valuable to have a long term Profiler
marker, we should consider instrumenting it via the [Profiler] API.
|
3963 |
| startuptelemetry |
|
|
| TelemetryMiddleware.kt |
|
5167 |