[arifBurakDemiray]

Board card: C-121, Bring R15 SDK limit: max key length to the Java SDK (part 4 of 4 of C-117)
Reference: https://github.com/Countly/countly-sdk-android (ConfigSdkInternalLimits.setMaxKeyLength)

Why

Android, iOS, React Native and Flutter let the developer set a key length limit at init. The Java SDK on staging already applies a key length limit everywhere the reference does (custom event keys, view names, segmentation keys, custom user property keys and modifier keys), but only when the SDK behavior settings send lkl. A developer has no way to set it.

What changed

• Config.setMaxKeyLength(int): new init config method, chainable like the other Config setters. Values below 1 are refused with an error log and the previous value stays, as the other range-checked setters in Config do.
• InternalConfig.getMaxKeyLength() and ModuleConfiguration.seedFromDeveloperConfig feed the developer value in as the fallback of lkl. So the settings override it while they carry lkl, and it applies again once they stop, the same precedence as every other setting.
• Tests: ConfigSurfaceTests (chain, range check, default), ModuleConfigurationLimitsTests (developer limit cuts keys on the wire, lkl overrides it, removal brings it back; and without any settings it cuts event, view and user property keys).
• CHANGELOG entry under XX.XX.XX.

For a person to decide

• Default. Android defaults to 128. This PR keeps the Java SDK's current default of no limit, because the card says existing defaults stay as they are and a 128 default would start cutting keys in apps that do not call the new method. Say if the default should move to 128.
• Invalid values. Android raises a value below 1 to 1. This PR refuses it and keeps the previous value instead, matching the Java Config setters and the lkl validation. Say if it should clamp instead.

Not verified

• Nothing was built or run. Gradle could not run in the worker's environment, so neither the compile nor the new and changed tests have run. CI on this PR is the first run.
• Backend mode records through its own path, which applies no key limit, so the new option has no effect there. That has not been changed or tested.

[github-actions]

Dependency security scan

Scanned 25 resolved dependencies, failing on HIGH and above.

No known vulnerabilities in 25 resolved dependencies.

Result: passed

Full run log

[github-actions]

Unit Test Results 🚀

741 tests  +2   741 ✅ +3   2m 49s ⏱️ -1s
 64 suites ±0     0 💤 ±0 
 64 files   ±0     0 ❌  - 1 

Results for commit 3bfa163. ± Comparison against base commit c0b090d.

[github-actions]

Code coverage

module	lines	branches
sdk-java	89.8% (7240/8062)	80.1% (3207/4004)
sdk-java-ui	70.5% (968/1374)	63.2% (499/790)

Files changed by this pull request

file	lines covered
sdk-java/src/main/java/ly/count/sdk/java/Config.java	91.9% (308/335)
sdk-java/src/main/java/ly/count/sdk/java/internal/InternalConfig.java	88.8% (71/80)
sdk-java/src/main/java/ly/count/sdk/java/internal/ModuleConfiguration.java	95.7% (428/447)

Least covered classes (10 shown)

class	module	lines covered	uncovered
ly.count.sdk.java.ui.JavaFxContentDisplay	sdk-java-ui	10.6% (23/216)	193
ly.count.sdk.java.ui.FxSurfaces	sdk-java-ui	74.8% (172/230)	58
ly.count.sdk.java.ui.ExternalBrowser	sdk-java-ui	55.0% (66/120)	54
ly.count.sdk.java.internal.SDKCore	sdk-java	89.0% (363/408)	45
ly.count.sdk.java.ui.JavaFxWidgetHost	sdk-java-ui	81.2% (190/234)	44
ly.count.sdk.java.internal.ModuleRequests	sdk-java	75.9% (132/174)	42
ly.count.sdk.java.internal.ModuleContent	sdk-java	89.7% (280/312)	32
ly.count.sdk.java.internal.TimedEvents	sdk-java	60.8% (48/79)	31
ly.count.sdk.java.internal.SessionImpl	sdk-java	90.1% (274/304)	30
ly.count.sdk.java.internal.SDKStorage	sdk-java	84.5% (158/187)	29

Full run log