Add Split Apks info as extras

[ganadist]

:scroll: Description

Fix #3192

:bulb: Motivation and Context

:green_heart: How did you test it?

:pencil: 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.

:crystal_ball: Next steps

Need to check test and unittest cases.

[romtsn]

hi @ganadist thanks for opening an issue for this and the PR! Before proceeding, I'd like to better understand your use-case - would you like to search for events with a specific split name?

In general, we don't set tags by default in the SDKs, but rather extract them on backend, if there's a good case for those and cardinality is not high.

[ganadist]

Hello, @romtsn I added more description at #3192 And I checked the implementation of setSideLoadedInfo and implemented setSplitApksInfo similarly. Is there any additional work required on the backend side?

[romtsn]

@ganadist thanks, but can you please answer the question: would you like to search for events with a specific split name? If you don't need to search for it but just see it in the issue details, we could just send this info as part of App context then.

Sending this as tag would require us to store and index it, and given that this field is high-cardinality (afaik apk splits are unique in their names and if multiply it by number of apks our customers might have that's huge), so this is unlikely that we'll take that route.

setSideLoadedInfo is doing it wrong and we have an issue to fix that, so don't see it as a reference for implementation.

[ganadist]

: would you like to search for events with a specific split name?

If it is possible to search for these events, it will be helpful to know the crash rate that occurs due to these problems. Because I have experienced several instances of increased crashes due to random distribution by the vendor store with missing split apks.

However, if this change may cause strain to the backend, it would be okay with being part of the app context instead of tags.

[ganadist]

Added 42a229f to use extras instead of tags.

[romtsn]

it will be helpful to know the crash rate that occurs due to these problems.

Unfortunately crash rate is based on Sessions dataset and it's not possible to filter session by custom tags/values yet. If search is not crucial for you, we should just add it as part of the App context - you will be able to see this information on individual events/issues then