Repository navigation
fix: exclude a kit whose configuration throws while parsing - #937
Conversation
A kit configuration could still crash the app at start-up. A default projection with an empty "matches" list threw an IndexOutOfBoundsException while the kit configurations were parsed on the kit thread, and because the configuration is cached, the crash repeated on every launch. Any exception thrown while parsing one kit's configuration now excludes that kit and is logged, and the other kits still start. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Kotlin migration progressNo change to the Java left to convert.
Conversion progress: 0.0% (16,698 of 16,550 baseline Java LOC left to convert). 132 Java files and 36 Kotlin files in scope. |
Binary compatibility
Compares the release AAR against the same artifact at the last version published to Maven Central; R8-renamed classes and members are excluded (see the script docstring). Full japicmp HTML/XML reports are attached as the |
📦 SDK Size Impact ReportWhat the SDK adds to a minified release APK. mParticle Core SDKMeasured against an empty baseline app. Unlike the Rokt kit, android-core ships no Compose and no resources, so there is nothing here that a host app would already provide.
mParticle Core + Rokt kitMeasured against a Compose + Material3 reference app, so these are the costs on top of an app that already ships Compose. The reference app's dependencies are a documented convention, not a measured average: see
Rokt SDK+ umbrella (adds the payment extension)
➡️ SDK size impact change is minimal. Raw measurementscore, Target branch: {"baseline_dex_bytes": 0, "baseline_download_bytes": 2513, "baseline_install_bytes": 7529, "core_dex_bytes": 219692, "core_download_bytes": 123460, "core_install_bytes": 130712}core, This PR: {"baseline_dex_bytes": 0, "baseline_download_bytes": 2511, "baseline_install_bytes": 7525, "core_dex_bytes": 219692, "core_download_bytes": 123452, "core_install_bytes": 130702}rokt, Target branch: {"baseline_dex_bytes": 1829108, "baseline_download_bytes": 1240062, "baseline_install_bytes": 1300934, "kit_dex_bytes": 4163396, "kit_download_bytes": 2544133, "kit_install_bytes": 2623275, "sdkplus_dex_bytes": 9284332, "sdkplus_download_bytes": 7981260, "sdkplus_install_bytes": 8165359}rokt, This PR: {"baseline_dex_bytes": 1829108, "baseline_download_bytes": 1240062, "baseline_install_bytes": 1300934, "kit_dex_bytes": 4163360, "kit_download_bytes": 2544207, "kit_install_bytes": 2623275, "sdkplus_dex_bytes": 9284300, "sdkplus_download_bytes": 7981172, "sdkplus_install_bytes": 8165359} |
2 participants
Why
An integration whose settings contain a default mapping with no match rules still crashes the app while the settings load. Because the settings are saved and loaded again at start-up, the app can then crash every time it starts. Once this lands, the SDK skips just that integration and logs why, and the app and every other integration keep working.
Programme
Standalone fix, no programme.
What changes
Before: mParticle/mparticle-android-sdk#928 excluded a kit whose settings threw a
JSONExceptionorNumberFormatExceptionwhile parsing. Any other exception escaped on the kit thread, for example theIndexOutOfBoundsExceptionthat a default projection with an emptymatcheslist raises.After:
KitManagerImpl.parseKitConfigurationscatches any exception thrown while parsing one kit's settings. That kit is excluded through the existingkitExcludedpath, and the log line now carries the exception's stack trace.Start reading at the catch in
parseKitConfigurations, and check first that a kit excluded there never starts. Deliberately left alone: the parsers themselves, which still assume well-formed input, since guarding their one caller covers every case; and the order in which the settings are saved and then parsed. No documentation or changelog change is needed; the release notes are generated from the commit message.Linked work
Related: mParticle/mparticle-android-sdk#928, which this extends.
Rollout
Path: merging changes
mainonly. The fix ships in the next release ofandroid-kit-base, which ships with the core SDK, and apps get it when they upgrade. It is live as soon as an app runs that release, with no switch and no ordering constraint.Feature flags: none.
Turning it off: revert this pull request and publish a new release. A published version cannot be recalled, so apps on the release that carries it keep the change until they upgrade again.
What we watch: nothing monitors this path. We watch the issues reported on this repository after the release that carries it, and the
Unit Tests,Lint ChecksandKotlin Lint Checksjobs on this pull request.Risks
Exception while starting kitnames it, with the stack tracekitExcludedRisk class: low.
Who
Written by: an automated coding agent (Claude Code), working for a maintainer who asked for this fix.
Code reviewed before opening: an independent review agent, 14 October 2026; it found nothing blocking, and its suggestion to log the stack trace is applied.
Design reviewed before opening: no one.
Decision this implements: a maintainer's request on 14 October 2026; there is no public record.
Checked: the extended
KitManagerImplTestcase, which fails without the change and passes with it, plus theandroid-kit-baseunit tests,ktlintCheckandlint, on 14 October 2026.Not checked: the instrumented tests, and malformed settings served to a device.
Size
Hand-written: 12 lines changed (added plus removed) in 2 files.
Generated: none.
🤖 Generated with Claude Code