Android Profiler on calling thread

[stefanosiano]

📜 Description

AndroidTransactionProfiler now starts/stops profiles without offloading to the executorService
removed any file checks due to the code running possibly on the main thread
wrapped Debug methods into try/catch to compensate lack of file checks

💡 Motivation and Context

If the executor service is very busy, the profiler would start with some delay, and when finishing it would wait for the executor to finish, possibly causing ANRs.
fixes #2649

💚 How did you test it?

Unit test

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	323.46 ms	389.62 ms	66.16 ms
Size	1.72 MiB	2.28 MiB	565.45 KiB

Previous results on branch: fis/android-profiler-drop-executor-service

Startup times

Revision	Plain	With Sentry	Diff
3481dd7	347.71 ms	407.70 ms	59.99 ms
aa0dbc4	283.43 ms	330.94 ms	47.51 ms

App size

Revision	Plain	With Sentry	Diff
3481dd7	1.72 MiB	2.26 MiB	552.61 KiB
aa0dbc4	1.72 MiB	2.26 MiB	552.61 KiB

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (8e5929c) 81.05% compared to head (1dbf094) 81.05%.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #2691   +/-   ##
=========================================
  Coverage     81.05%   81.05%           
  Complexity     4427     4427           
=========================================
  Files           345      345           
  Lines         16356    16356           
  Branches       2219     2219           
=========================================
  Hits          13258    13258           
  Misses         2170     2170           
  Partials        928      928           

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[romtsn]

LGTM, but in the original issue this was somehow related to slow network connection. Have you managed to reproduce it? I wasn't sure how the slow connectivity can be the reason here, because our HttpConnection uses a different thread pool (also single-threaded), so in theory they should not conflict with SentryExecutorService

[stefanosiano]

LGTM, but in the original issue this was somehow related to slow network connection. Have you managed to reproduce it? I wasn't sure how the slow connectivity can be the reason here, because our HttpConnection uses a different thread pool (also single-threaded), so in theory they should not conflict with SentryExecutorService

I reproduced it by spawning lots of transactions and having a fake dsn to have all the envelopes sending timeout.
The SentryExecutorService is used by SendCachedEnvelopeIntegration and SendCachedEnvelopeFireAndForgetIntegration.
I think in case of slow connection envelopes are cached to disk and sent, but there is a wait in the processing of the envelope file
Does it make sense or am i missing something?
At the moment the SentryExecutorService is not used for any critical things anymore (except scheduling auto finish of profiling, ttfd and cpu/mem collection, but that's more to cover edge cases), but we could think about using an executor only for the envelope handling.

[romtsn]

@stefanosiano ah gotcha, that makes sense, yes! And then we were blocking on the profiler, although the executor was already busy. I think it's fine to use the executor as long as we don't call blocking .get on the main thread (except the startup crash case, where we block for 5s max), so this looks good

[helloword1]

When will the new version be released to fix the issue?