fix: Normalize js_refresh_rate against actual screen fps

[sbarrio]

What does this PR do?

This PR fixes the js_refresh_rate normalization. It normalizes fps metrics into a 0-60fps range, but it always did so against the screen's maximum possible refresh rate rather than the rate the screen is actually running at. On high refresh rate screens running below their maximum (e.g. a 120Hz panel running at 60Hz), a healthy JS thread was reported at ~30fps.

The current refresh rate now comes from CADisplayLink's targetTimestamp on iOS and from the default display's Display.refreshRate on Android, and is passed to the existing normalization functions in place of the maximum.

Android below API 30: we keep normalizing against the maximum refresh rate. Before API 30 Display.refreshRate isn't cached and every read is an IPC to the system, which we don't want on every JS frame (dd-sdk-android doesn't read it below API 30 either).

Motivation

The calculation of js_refresh_rate should be accurate under all circumstances.

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests
• 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)
• If this PR is auto-generated, please make sure also to manually update the code related to the change

[Copilot]

Copilot review overview

🟡 Changes recommended

Android may use the wrong display on multi-display devices, and the iOS refresh-rate calculation lacks direct coverage.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Use the Activity's current display instead of hardcoded display 0 · New
• Add iOS tests for target timestamp priming and FPS calculation · New

What changed in this PR

Updates JS refresh-rate normalization to use the display’s active refresh rate rather than its maximum supported rate.

Changes:

• Propagates current display FPS through Android and iOS frame callbacks.
• Adds normalization tests for 60 Hz and 120 Hz scenarios.
• Uses platform-specific refresh-rate APIs.

File	Description
packages/​core/​ios/​Tests/​DdSdkTests.swift	Tests FPS-aware normalization.
packages/​core/​ios/​Sources/​JSRefreshRateListener.swift	Derives FPS from display-link timestamps.
packages/​core/​ios/​Sources/​DdSdkImplementation.swift	Applies reported FPS during normalization.
packages/​core/​android/​src/​test/​kotlin/​com/​datadog/​reactnative/​DdSdkTest.kt	Tests dynamic refresh-rate normalization.
packages/​core/​android/​src/​main/​kotlin/​com/​datadog/​reactnative/​FrameRateProvider.kt	Reports the display refresh rate with frame timing.
packages/​core/​android/​src/​main/​kotlin/​com/​datadog/​reactnative/​DdSdkImplementation.kt	Supplies the display and applies its refresh rate.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

The Android implementation has avoidable per-frame overhead and does not meet the stated behavior on supported pre-30 devices.

Review effort: Balanced
Findings: 1

Open (1)

• Android 23–29 still use maximum-rate normalization · New

Resolved since last review (2)

• Use the Activity's current display instead of hardcoded display 0
• Add iOS tests for target timestamp priming and FPS calculation

Previously missed (1)

In code that hasn't changed since last review

Avoid reading display refresh rate when frame vitals are disabled

packages/​core/​android/​src/​main/​kotlin/​com/​datadog/​reactnative/​DdSdkImplementation.kt:340

The display is also supplied when frame-rate vitals are disabled but JavaScript long-task monitoring is enabled. In that supported configuration, FpsFrameCallback now reads display.refreshRate on every JS-thread frame even though buildFrameTimeCallback discards the value, adding continuous overhead unrelated to the enabled feature. Only resolve/pass the display when the vitals frequency is not NEVER.

[marco-saia-datadog]

Looks good 👍