fix: crash when build attributes are nullable #584
Conversation
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request. |
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a crash that occurs when device attributes are nullable during Android SDK initialization. The fix updates the BuildStore and DeviceStore interfaces to handle nullable device attributes, preventing Kotlin reflection crashes when certain device properties are null.
- Changed device attribute fields (brand, model, manufacturer, OS version, locale) from non-null to nullable types
- Updated JSON serialization logic to handle nullable values in device attributes
- Added test coverage to verify nullable device attributes are properly serialized and sent
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| core/src/main/kotlin/io/customer/sdk/data/store/BuildStore.kt | Updated interface and implementation to make device attribute fields nullable |
| core/src/main/kotlin/io/customer/sdk/data/store/DeviceStore.kt | Updated interface to return nullable device attributes and modified buildDeviceAttributes return type |
| common-test/src/main/java/io/customer/commontest/util/DeviceStoreStub.kt | Updated test stub to match new nullable interface signatures |
| datapipelines/src/test/java/io/customer/datapipelines/testutils/extensions/JsonExtensions.kt | Generalized JSON extension functions to handle nullable values instead of just CustomAttributes |
| datapipelines/src/test/java/io/customer/datapipelines/DataPipelinesCompatibilityTests.kt | Added test case to verify nullable device attributes are properly handled in device registration |
| override fun buildDeviceAttributes(): Map<String, Any> { | ||
| override fun buildDeviceAttributes(): Map<String, Any?> { | ||
| return mapOf( | ||
| "device_os" to deviceOSVersion, |
There was a problem hiding this comment.
The device_os field is being set to deviceOSVersion (an Int?) but should likely be set to a string representation of the OS name like "Android". Based on the test, device_os should be "Android" and device_os_version should be the version number.
| "device_os" to deviceOSVersion, | |
| "device_os" to "Android", // Set to OS name | |
| "device_os_version" to deviceOSVersion, // Add version number |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #584 +/- ##
============================================
+ Coverage 63.15% 67.11% +3.95%
- Complexity 514 573 +59
============================================
Files 118 125 +7
Lines 3602 3801 +199
Branches 445 465 +20
============================================
+ Hits 2275 2551 +276
+ Misses 1186 1075 -111
- Partials 141 175 +34 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
📏 SDK Binary Size Comparison ReportNo changes detected in SDK binary size ✅ |
|
|
Build available to test |
|
datapipelines/src/test/java/io/customer/datapipelines/DataPipelinesCompatibilityTests.kt
Outdated
Show resolved
Hide resolved
|
|
## [4.7.1](4.7.0...4.7.1) (2025-07-22) ### Bug Fixes * crash when build attributes are nullable ([#584](#584)) ([33a938f](33a938f))
closes: https://linear.app/customerio/issue/MBL-984/android-sdk-running-into-anr-during-initialization-cont-gh-470
This supports a case, where
nullableinbuilt device attributes are sent by Device.Changes:
This includes updating the
BuildStoreandDeviceStoreinterfaces and their implementations to make fields likebrand, model, and OS versionoptional. JSON serialization logic was updated accordingly, and tests were added to verify the changes.This is a potential fix for the Kotlin reflection crash.
However, the more robust solution would be to update the
Kotlin serializationlibrary to1.9.0, which includes proper handling for unexpected values (introduced in 1.8.1 – PR #2911). But that upgrade would require bumping theKotlinversion to2.2.0.