We decided to upload in onStart before we had session information because we want to capture a user using the browser ASAP on first run (e.g. for install tracking) As bnicholson doing the iOS impl pointed out, now there is some value to uploading in onStop – we can get information about the users' last session before they stop using the browser indefinitely. This is particularly relevant for the first few runs (e.g. bug 1273689). However, uploading in onStop has some downsides: * onStop is less likely to be called: * In low memory situations, it is not guaranteed to be called * If we crash, it won't be called * The system has more opportunity to kill us if we don't have a foreground service * The next app to be opened (if any) may not be doing network operations so we'll may be activating the radio and draining battery just for this ping. If we did implement this, we probably want to upload on first run in onStart for the reasons at the top of this comment. Also, we'd have to verify the implementation – we need to wait for the reuploader verification to finish: bug 1268513 and bug 1275929. fwiw, given the amount of debugging this may require, I don't think I'll get to this any time soon.

(In reply to Michael Comella (:mcomella) from comment #0) > However, uploading in onStop has some downsides: > ... * I'd expect the user is less likely to have network connection when they close the browser than when they open it (e.g. closing the browser because they lost their internet connection & it's no longer useful to them). For the extreme case: we don't try to reupload until the next time an upload attempt is hit (i.e. when the browser is closed) so if they always close the browser without an internet connection, we're screwed!

If we decide not to do this, consider delaying upload until after Gecko is started to improve start-up times – we currently upload in onStart and perform various amounts of computation and disk read/write. fwiw, one of the original design goals of the core ping was to upload ASAP, to send it before a user a) backs out of Fennec, b) crashes Fennec, etc., but these seem extreme to me when it'd be ideal to start-up faster – we should talk to product.

It's worth noting that the current implementation does not allow us to accurately identify when the session data took place – we create a ping in onStart but this onStart could be called on, for example, June 7, when the session data it is filled with was recorded in onStop on June 6.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.