Allow using objcopy instead of objdump for native symbols #484
Conversation
This file contains 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
…iles on newer NDK versions
… instead of having to pass each property separately
…ion works as expected
Use `objcopy` instead of `objdump` when configured
Upload .so files produced using objcopy
Merge NDK symbol upload tasks
# Conflicts: # src/main/kotlin/com/bugsnag/android/gradle/BugsnagGenerateNdkSoMappingTask.kt
tomlongridge
approved these changes
Nov 9, 2022
Merged
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.
Goal
Support using
objcopyinstead ofobjdumpto extract native symbols (when supported by the current NDK).Design
Bugsnag can now be configured with
useLegacyNdkSymbolUpload = falseon supported projects, which will useobjcopyto extract the debug info from native.sofiles and upload them to a new Bugsnag endpoint. Projects must be configured to use a version of thebugsnag-androidSDK of at least5.26.0to be considered compatible (an error will be emitted otherwise).This process is significantly faster and allows us to support NDK toolchains that don't have the old GNU based toolchains (
21.1.6352462and onwards).Testing
New end to end scenario and updated test fixture.