Merge develop into feature/heatmaps

…eal/PANA-5681/view-identity-resolver

…ntity-resolver

PANA-5681: Add `HeatmapIdentifier` infrastructure [1 of 4]

…pdates

PANA-5681: Update RUM and Session Replay schemas for heatmaps [2 of 4]

…ctor params

…maps

PANA-5681: Integrate HeatmapIdentifierRegistry into RUM for heatmaps [3 of 4]

… mappers

…olors

RUM-8112: Fix gradients not showing in compose

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…ection-issues

RUM-16551: Fix hidden API reflection noise in Session Replay drawable mappers

Update the CHANGELOG and switch AndroidConfig version from SNAPSHOT to Release.

Co-authored-by: Cursor <[email protected]>

…replay-heatmaps

PANA-5681: Integrate HeatmapIdentifierRegistry into Session Replay for heatmaps [4 of 4]

Co-authored-by: Cursor <[email protected]>

PANA-5681: Add heatmaps feature flag

RUM-16882: Fix the cronet sample crashing when loading 404.png

…util

Remove the unused KotlinDSLUtils from the Gradle build

The analysis:detekt-custom job runs custom Detekt rules by invoking
./gradlew customDetektRules, which sequentially executes 31 independent
JavaExec tasks — one JVM per module. Because the tasks share no state and
declare no inter-dependencies, they are safe to run concurrently.

Adding --parallel --max-workers=4 reduces step 6 of the job from ~155s to
~69s (2.2× speedup) on a local benchmark of all 31 modules.

Each worker JVM is capped at maxHeapSize=2g to bound heap usage. The job's
Kubernetes memory limit is increased to 32Gi (matching datadog-android) to
accommodate 4 concurrent JVMs: 4 × ~3.25Gi (heap + metaspace) + 4Gi
Gradle daemon ≈ 18Gi, well within the new limit.

# Conflicts:
#	ci/pipelines/default-pipeline.yml

assembleLibrariesRelease is the dominant step in analysis:detekt-custom,
taking ~8m 17s (56% of the job) in CI. Adding --parallel enables Gradle
to compile independent library modules concurrently within the same daemon
process (in-process workers sharing the 4Gi heap) rather than sequentially.

Unlike customDetektRules --parallel which spawns separate JVMs per task,
--parallel on assembleLibrariesRelease uses Gradle's built-in worker
infrastructure — no additional memory per concurrent task. The module
dependency graph has a natural fan-out: dd-sdk-android-internal and
dd-sdk-android-core must compile first, then 25+ feature and integration
modules can compile in parallel.

Move KUBERNETES_MEMORY_LIMIT from 13Gi to 32Gi in the root .gitlab-ci.yml,
matching datadog-android which uses the same limit on the same runner pool.

The higher limit is needed for jobs that run parallel JVM workers
(analysis:detekt-custom, test:debug). Setting it globally is simpler than
per-job overrides and has no scheduling cost since KUBERNETES_MEMORY_REQUEST
remains at 8Gi — the scheduler still only needs 8Gi free on the node.
Actual memory consumed per job is unchanged for jobs that don't use the
extra headroom.

Removes the now-redundant KUBERNETES_MEMORY_LIMIT: 32Gi override from
analysis:detekt-custom.

…--parallel

test:debug ran 5 separate ./gradlew --no-daemon invocations sequentially.
Each call pays the full Gradle startup and project configuration overhead
(~10-15s in CI × 4 extra calls = ~40-60s wasted). Consolidating into a
single invocation eliminates that redundancy.

--parallel --max-workers=4 lets Gradle run up to 4 modules' test tasks
concurrently. Each module forks its own test JVM (~768MB); 4 concurrent
test JVMs + 3Gi Gradle JVM ≈ 6Gi total — well within the 32Gi limit now
set globally.

Note: unlike assembleLibrariesRelease --parallel (in-process workers,
shared heap), test tasks fork separate JVMs. --max-workers=4 acts as the
memory safety valve, the same role it plays for customDetektRules.

…--parallel

test:kover ran 4 separate ./gradlew --no-daemon invocations for coverage
generation, paying ~33s of Gradle startup overhead across 3 extra calls.
Consolidating into a single invocation using the >- YAML folded scalar
eliminates that overhead (same fix applied to test:debug).

--parallel --max-workers=4 lets Gradle run up to 4 modules' koverXmlReport
tasks concurrently. koverXmlReportRelease forks a test JVM per module for
instrumented coverage tracking (~1.5-2GB each); 4 workers stay well within
the 32Gi global limit set in the previous commit.

test:kover is the current critical path of the test stage (~17m 55s avg)
now that test:debug has been reduced to ~7m 57s.

… API 30+

… API 24+

…analysis-optimization

RUM-14050: Reduce CI pipeline time via parallelism and Gradle consolidation

Fix regression of missing tinted backgrounds

…rossplatform-prep

[PANA-5681] Preparation for Heatmaps cross-platform integration

Merge develop into feature/heatmaps

Merge heatmaps into develop