py - Pierre Yves Ricau

> I'm not sure I understand why unsealing the class has to be done together with removing thread checks. > > And removing the threading guarantees seems like it could...

And so of course a follow up change prior to releasing would be to make the Android dependency optional and prove that it works. I'm thinking we might not actually...

> while also introducing less new API surface, by using coroutines Oxymoron spotted! Using coroutines means adding a dependency that's not necessarily used by all consumers yet, so that would...

Aside from that, I wonder, what's the behavior of this when you are indeed on the main thread: ``` withTimeout(5.seconds) { withContext(Dispatchers.Main.immediate) { continue() } } ``` I can't think...

> That's just a feature of co-operative multitasking (or 'non-preemptive' if you'd rather), you have to co-operate. Indeed. And AFAIK the current code does not cooperate (e.g. no suspending functions...

Screenshot of current recipe: https://twitter.com/Piwai/status/1291771701584252928 A better path forward: https://github.com/android/android-test/issues/724

Those are actually unhandled crashes. We don't let bugsnag capture unhandled crashes automatically, we have our own exception handler and delegate to bugsnag (another missing API here is the ability...

> As for setting a handled report as unhandled, for your use case, you could use the [isUnhandled](https://docs.bugsnag.com/platforms/android/customizing-error-reports/#isunhandled) property in a callback if this makes adjusting this easier for you?...

(note: by "we" here @mutexkid is referring to Square)

@yousif-bugsnag this points to a core design flaw in the Bugsnag Android SDK: it should be fairly straightforward to adopt it without the default automatic crash reporting, and still report...