(In reply to Eugen Sawin [:esawin] from comment #3)
Alessio, can we explore your proposed options?
Sure! See my comments below.
With bug 1545266 we aim to introduce more structured handling of Android lifecycle events like app backgrounding.
This would be very, very useful.
I'm thinking of introducing lifecycle-aware handling of scheduled flushes like this.
One possible strategy that could work for this and bug 1536797 is as follows:
- Flush periodically when in foreground (current mechanic).
- Force-flush when app is getting backgrounded.
- No I/O when app is in background or at an increased timeout.
I'm afraid we should go for "increased timeout", as we can't guarantee that nobody will attempt to record telemetry while in background (think of GC). For "how increased", that depends on two things:
- how frequent can we be without being bad to Android power management?
- how much data (being accumulated while in background) are we willing to sacrify?
Assuming we can ensure that flushing in #2 is successful, data integrity should be preserved and we would have options to play nice with Android's power management.
All these states and timers should be controlled by GV events, that would give us the most flexibility for future improvements.
Do you think such mechanics would be feasible for telemetry, are there any risks in the interaction with Gecko?
Yes, it would be feasible. I can imagine the Telemetry core to listen to some event like "GeckoViewGoingToBackground", then we internally increase the timeout for the I/O, and restore it back once we're back to foreground.
One other short-term option, if this is creating problems for the Fenix launch, is to completely disable the mechanism as Fenix is not currently fetching GeckoView telemetry.
I'm happy to have a vidyo chat next week if that helps!