-
Notifications
You must be signed in to change notification settings - Fork 8.5k
Adding endpoint to upload android map files #161252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding endpoint to upload android map files #161252
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
Co-authored-by: Søren Louv-Jansen <[email protected]>
…/kibana into uploading-android-map-files
…-ref HEAD~1..HEAD --fix'
…/kibana into uploading-android-map-files
|
@elasticmachine merge upstream |
|
Pinging @elastic/apm-ui (Team:APM) |
|
@elasticmachine merge upstream |
| }, | ||
| }); | ||
|
|
||
| const uploadAndroidMapRoute = createApmServerRoute({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add docs for this one? (Example: https://www.elastic.co/guide/en/kibana/current/apm-api.html)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gbamparop - I've just added docs for the overall Android source map API. There are lots of similarities with the RUM one, which is why I took a lot of the parts involved in that part of the doc file. I'm not sure if my approach is the right one, so please have a look just in case there might be a better way to handle it. I'm also looping @bmorelli25 in, in case he's got some inputs as well.
Co-authored-by: Brandon Morelli <[email protected]>
Co-authored-by: Brandon Morelli <[email protected]>
Co-authored-by: Brandon Morelli <[email protected]>
|
@elasticmachine, run elasticsearch-ci/docs |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
| options: { | ||
| tags: ['access:apm', 'access:apm_write'], | ||
| body: { accepts: ['multipart/form-data'] }, | ||
| body: { accepts: ['multipart/form-data'], maxBytes: 100 * 1024 * 1024 }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it override the option https://www.elastic.co/guide/en/kibana/current/settings.html#server-maxPayload?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the core team, this option sets the limit at the route level but there is no option for the user to increase the value. We need to introduce a new config setting for the endpoint.
I think we can proceed with the current approach and handle it in a follow-up work if is needed
| fleetId: artifact.id, | ||
| created: artifact.created, | ||
| mapContent: sourceMapContent, | ||
| bundleFilepath: bundleFilePath.toString(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bundleFilePath is a string. Is this needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, I think it's not needed. I've just removed it 👍
kpatticha
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM just left 2 comments
Co-authored-by: Katerina Patticha <[email protected]>
|
@elasticmachine merge upstream |
…/kibana into uploading-android-map-files
…-ref HEAD~1..HEAD --fix'
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
## Summary We need a way to decode Android crash's stacktraces so that they can provide meaningful insights to our customers, this is because, due to security reasons, android apps tend to obfuscate their code before publishing it online, making crash reports contain obfuscated names, which don't make any sense before mapping them to the actual source code names. In order to help our customers deobfuscate their stacktraces, we need to allow them to provide us with an R8 map file, which is generated by the code obfuscation tool (R8) at compile time. This map file is needed to later do the deobfuscation process. So these code changes take care of adding a new endpoint that our customers can use to upload their map files, similarly to what's currently available to [RUM Sourcemaps](https://www.elastic.co/guide/en/apm/guide/current/source-map-how-to.html#source-map-rum-upload), the Android map files will be uploaded to ES, using the same index as the one currently used to store RUM Sourcemaps. There's a couple of reasons why a new endpoint to upload android maps is needed instead of re-using the existing RUM Sourcemaps one: * The Sourcemaps upload endpoint has validations in place to check the sourcemap format, which must be a JSON with some expected keys available. Android map files don't have a JSON format, so they are rejected by the sourcemaps endpoint. * Android map files tend to be large in size, just as an example, the map file generated for our [sample app](https://github.com/elastic/opbeans-android) has a size of ~7 MB, so for real apps this number can be larger, which would also cause issues with the RUM upload endpoint since it has a max file limit size of 1 MB. * The RUM upload endpoint contains a parameter (`bundle_filepath `) that doesn't have an equivalent for the android map use case. This PR depends on elastic#161152 ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [ ] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Søren Louv-Jansen <[email protected]> Co-authored-by: Brandon Morelli <[email protected]> Co-authored-by: Katerina Patticha <[email protected]>


Summary
We need a way to decode Android crash's stacktraces so that they can provide meaningful insights to our customers, this is because, due to security reasons, android apps tend to obfuscate their code before publishing it online, making crash reports contain obfuscated names, which don't make any sense before mapping them to the actual source code names.
In order to help our customers deobfuscate their stacktraces, we need to allow them to provide us with an R8 map file, which is generated by the code obfuscation tool (R8) at compile time. This map file is needed to later do the deobfuscation process.
So these code changes take care of adding a new endpoint that our customers can use to upload their map files, similarly to what's currently available to RUM Sourcemaps, the Android map files will be uploaded to ES, using the same index as the one currently used to store RUM Sourcemaps.
There's a couple of reasons why a new endpoint to upload android maps is needed instead of re-using the existing RUM Sourcemaps one:
bundle_filepath) that doesn't have an equivalent for the android map use case.This PR depends on #161152
Checklist
Delete any items that are not applicable to this PR.
For maintainers