RUM-13468: Add totalRam, logicalCpuCount and isLowRam to DeviceInfo

[marco-saia-datadog]

What does this PR do?

Adds new attributes to the Device Info:

• totalRam: The total RAM in megabytes
• processorCount: Number of logical CPU cores available for scheduling on the device at

• runtime, as reported by the operating system.

• *isLowRam: Whether the device is considered a low RAM device (from ActivityManager.isLowRamDevice)

Additional Notes

• The relevant schemas have been modified locally
• PR in rum-events-format: [FEAT] Added new attributes to RUM Device Info rum-events-format#323
• PR in rum-events-format: RUM-12199: Device Capabilities Attributes Refactoring rum-events-format#337 (refactoring)

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

[codecov-commenter]

Codecov Report

❌ Patch coverage is 78.65169% with 19 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.26%. Comparing base (e253017) to head (a4e01bd).

Files with missing lines	Patch %	Lines
...core/internal/system/DefaultAndroidInfoProvider.kt	18.75%	13 Missing ⚠️
...tadog/android/core/internal/NoOpContextProvider.kt	0.00%	3 Missing ⚠️
...id/core/internal/system/NoOpAndroidInfoProvider.kt	0.00%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3024      +/-   ##
===========================================
+ Coverage    71.25%   71.26%   +0.01%     
===========================================
  Files          866      866              
  Lines        31734    31807      +73     
  Branches      5360     5360              
===========================================
+ Hits         22610    22665      +55     
- Misses        7596     7614      +18     
  Partials      1528     1528              

Files with missing lines	Coverage Δ
...tlin/com/datadog/android/api/context/DeviceInfo.kt	100.00% <100.00%> (ø)
...og/android/core/internal/DatadogContextProvider.kt	97.92% <100.00%> (+0.14%)	⬆️
...android/log/internal/domain/DatadogLogGenerator.kt	98.02% <100.00%> (+0.03%)	⬆️
...g/android/rum/internal/DatadogLateCrashReporter.kt	86.60% <100.00%> (+0.73%)	⬆️
...ndroid/rum/internal/domain/scope/RumActionScope.kt	97.07% <100.00%> (+0.04%)	⬆️
...roid/rum/internal/domain/scope/RumResourceScope.kt	91.12% <100.00%> (+0.45%)	⬆️
.../android/rum/internal/domain/scope/RumViewScope.kt	94.12% <100.00%> (+0.09%)	⬆️
...ndroid/telemetry/internal/TelemetryEventHandler.kt	85.93% <100.00%> (+1.77%)	⬆️
...trace/internal/domain/event/BaseSpanEventMapper.kt	70.45% <100.00%> (-2.72%)	⬇️
...tadog/android/core/internal/NoOpContextProvider.kt	2.27% <0.00%> (-0.17%)	⬇️
... and 2 more

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[0xnm]

Probably the naming is not the best one, because processor is a chip containing multiple cores. We probably want to send the number of physical cores, right?

[marco-saia-datadog]

Hey @0xnm thanks for the review! I’m picking this PR up again, sorry for the delay.

I initially went with processor_count rather than something more precise is because both the Android and iOS APIs use the term processor, even though they effectively return the number of CPU cores:

• Android: Runtime.getRuntime().availableProcessors()
• iOS: ProcessInfo.processInfo.processorCount

That said, I'm not particularly happy with this name either, as it could be clearer. I was thinking cpu_core_count.

WDYT?

[0xnm]

Apple docs say:

processorCount
The number of processing cores available on the computer.

Android docs say:

Returns the number of processors available to the Java virtual machine.

This value may change during a particular invocation of the virtual machine. Applications that are sensitive to the number of available processors should therefore occasionally poll this property and adjust their resource usage appropriately.

Apple docs are more explicit about the cores meaning behind. But given that both are using processors <-> cores lingvo interchangeably, I don't have a strong no against it, so I'm okay with any of cpu_core_count or processor_count. Maybe the former is a bit better for understanding (not sure if we can find any mobile devices with multiple CPU units).

[0xnm]

not sure if we want to send the number of processors (chips) or cores, but this method returns the number of physical cores and not the number of chips.

[0xnm]

unless we have any performance concerns, we can use default mode

Suggested change

	override val processorCount: Int by lazy(LazyThreadSafetyMode.PUBLICATION) {
	override val processorCount: Int by lazy {

[0xnm]

Suggested change

	override val totalRam: Int? by lazy(LazyThreadSafetyMode.PUBLICATION) {
	override val totalRam: Int? by lazy {

[0xnm]

Suggested change

	override val isLowRamDevice: Boolean? by lazy(LazyThreadSafetyMode.PUBLICATION) {
	override val isLowRamDevice: Boolean? by lazy {

[0xnm]

minor: it is better to move this annotation right to the call site rather than to keep it for the whole method. I guess here it will be getMemoryInfo and ActivityManager.MemoryInfo() constructor can be declared as safe in YAML config.

[0xnm]

Suggested change

	val processorCount: Int = forge.anInt()
	val totalRam: Int = forge.anInt()
	val isLowRamDevice: Boolean = forge.aBool()
	val processorCount = forge.anInt()
	val totalRam = forge.aNullable { anInt() }
	val isLowRamDevice = forge.aNullable { aBool() }

[0xnm]

Suggested change

	totalRam = forge.anInt(),
	isLowRamDevice = forge.aBool()
	totalRam = forge.aNullable { anInt() },
	isLowRamDevice = forge.aNullable { aBool() }

[0xnm]

we need to add assertions for these new properties in tests for RumViewScope, RumResourceScope, etc.