expose logCrash function that can be called before SDK init #188
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
snowp
force-pushed
the
deferred-crash-event
branch
from
27feb59 to
b81e720
Compare
snowp
force-pushed
the
deferred-crash-event
branch
from
b81e720 to
63f0db6
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces a way to report a crash event even before the SDK has started. No real event information is currently included in the event, but this should be sufficient to trigger an upload should another crash framework notify us that there has been a crash.
By being able to be called before SDK init, this eliminates the ordering requirement between the initializing bitdrift before whatever crash handling may want to report a crash.
Since this is limited to a simple crash notification, we can take a lot of shortcuts, making this not suitable for general logging prior to init.
For both iOS and Android this uses a state machine guarded by synchronized access to make sure that we don't race against the SDK init. On Android this means that we are introducing a synchronized block during regular logger access where we previously could get away with atomics, though this just ends up matching the existing behavior on iOS.
Fixes BIT-4335