Flush signals after initializing exporters

[deividasstr]

Based on issue, flushing existing events on sdk initialization to increase chances signals are sent in case app is terminated before export interval is reached.

Flushes all exporters during SDK build, in async task of initiating exporters.

Maybe there is a better place and time to do it? Sometime after build?

If location is suitable, I will add tests.

[breedx-splk]

I am not sure I follow this. Flushing right after creation? There seems to still be a window of time after the flush and before the export interval is reached.

There's a shutdown hook in the upstream sdk that is intended to handle this case, I think.

[deividasstr]

I am not sure I follow this. Flushing right after creation? There seems to still be a window of time after the flush and before the export interval is reached.

It sounds like this comment is based on second comment. But if the latter does not work, the event remains unexported until first export interval.

There's a shutdown hook in the upstream sdk that is intended to handle this case, I think.

As @LikeTheSalad said in the issue, flushing on app closing is not reliable, the export is not ensured.

Actually I did notice there is an automatic shutdown hook. But from my testing, I have never seen an export happening on app being killed. I will take a look at the flow

[LikeTheSalad]

I think it's also worth noticing that there are 2 types of "flushing" in this repo, one to disk and the other to the network. Definitely the network one isn't reliable on app destroy, probably the disk one is, although I'm not sure because I haven't tested it.

[deividasstr]

I think it's also worth noticing that there are 2 types of "flushing" in this repo, one to disk and the other to the network. Definitely the network one isn't reliable on app destroy, probably the disk one is, although I'm not sure because I haven't tested it.

Aren't both of them attempted on flush of the reader?

[deividasstr]

There's a shutdown hook in the upstream sdk that is intended to handle this case, I think.

From my lookup, due to long chain of dependencies, I do not see where AutoConfiguredOpenTelemetrySdkBuilder is used in android SDK. And the OpenTelemetrySdk itself does also have shutdown method, which is called on close method on implementation of Closeable. But I do not see this being attached to any shutdown or use anywhere.

So it is not used, right?