Merge develop into feature/view-update branch#3560
Open
hamorillo wants to merge 55 commits into
Open
Conversation
…put-privacy-api-doc Update wrong API doc for the text and input privacy configuration in Session Replay
…s in package regex Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…eyword-package Fix flaky `InternalApiUsageDetectorTest` due to Kotlin reserved keywords in package regex
The trampoline introduced in #3420 didn't fix the ANRs (see #3480) — PairIP wraps onReceive() at entry on the main thread, before the trampoline can offload its body. Remove the executorService parameters and wiring on both BroadcastReceiver*InfoProviders ahead of a follow-up commit that registers the receivers with a background Handler. Keep @volatile on systemInfo, networkInfo, and lastNetworkInfo since they're independently useful for cross-thread visibility once dispatch moves off-main.
Introduce BroadcastReceiverThread, a dedicated HandlerThread used to deliver CONNECTIVITY_ACTION, ACTION_BATTERY_CHANGED, and ACTION_POWER_SAVE_MODE_CHANGED broadcasts to BroadcastReceiverNetworkInfoProvider and BroadcastReceiverSystemInfoProvider on a background thread instead of the main thread. The handler is passed to registerReceiver via ThreadSafeReceiver, and the thread is created in setupExecutors() and shut down in shutDownExecutors(). The @volatile fields on networkInfo and systemInfo continue to guarantee visibility for any reader thread.
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
…ag-key-naming refactor(flags): rename flag names to flag keys
…tion Fix Detekt stackoverflow on wildcard projections
Make BroadcastReceiverThread extend HandlerThread directly instead of wrapping one, removing the handler property and shutdown() wrapper. Create a single Handler from the thread's looper in setupInfoProviders() and share it across BroadcastReceiverSystemInfoProvider and BroadcastReceiverNetworkInfoProvider.
…stom-action-fix RUM-15577: Write CUSTOM RUM actions immediately
RUM-16123: Move broadcast receiver dispatch off the main thread
- Add toEvaluationMetadata() helper that builds EvaluationMetadata from flagMetadata via the public Builder API (EvaluationMetadata constructor is internal in kotlin-sdk 0.6.2) - Wire metadata into toProviderEvaluation() - Add test verifying allocationKey round-trips through flagMetadata
The Builder API doesn't have putLong; Long values fall through to putString as-is via the else branch.
…esolution-details-metadata Thread allocationKey into ResolutionDetails flagMetadata Co-authored-by: typotter <tyler.potter@datadoghq.com>
…ersion Bump Datadog Gradle Plugin to 1.27.0
…mappers Pass InternalLogger through the SR mappers
…or-service Move FakeSameThreadExecutorService into core textFixtures
…olors RUM-8112: Fix gradients not showing in compose
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…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 <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
…ase-3.11.0 Prepare the 3.11.0 release
…snapshot Bump version to 3.12.0-SNAPSHOT
…/merge-release-3.11.0-to-develop Co-authored-by: Cursor <cursoragent@cursor.com> # Conflicts: # buildSrc/src/main/kotlin/com/datadog/gradle/config/AndroidConfig.kt
…e-3.11.0-to-develop Merge release 3.11.0 into develop
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.
…analysis-optimization RUM-14050: Reduce CI pipeline time via parallelism and Gradle consolidation
…to/merge-develop-into-feature-view-update-260619 # Conflicts: # reliability/single-fit/rum/src/test/kotlin/com/datadog/android/rum/integration/ManualTrackingRumTest.kt
kikoveiga
approved these changes
Jun 19, 2026
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ff9427bc65
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| fun toJson(): com.google.gson.JsonElement | ||
| companion object | ||
| fun fromJson(kotlin.String): Family | ||
| data class com.datadog.android.profiling.model.RumMetadataEvent |
There was a problem hiding this comment.
The profiling generator currently maps only profile-event-schema.json to ProfileEvent (features/dd-sdk-android-profiling/generate_profiling_models.gradle.kts), and a repo-wide search finds no RumMetadataEvent schema/source outside these API files. Adding RumMetadataEvent here makes the checked-in API surface diverge from what the module can generate/compile, so checkApiSurfaceChangesAll will regenerate without these entries and fail.
Useful? React with 👍 / 👎.
Comment on lines
+139
to
+142
| return resolveGradientFillColor(drawable)?.let { resolvedColor -> | ||
| val colorAlpha = (resolvedColor ushr ALPHA_SHIFT_ANDROID) and MAX_ALPHA_VALUE | ||
| val fillAlpha = (colorAlpha * drawable.alpha) / MAX_ALPHA_VALUE | ||
| if (fillAlpha == 0) null else mergeColorAndAlpha(resolvedColor, fillAlpha) |
There was a problem hiding this comment.
On API 24–28, DrawableToColorMapper.getDefault() still instantiates AndroidMDrawableToColorMapper, but this new N+ branch returns from GradientDrawable.color without looking at drawable.colorFilter. Tinted GradientDrawable backgrounds (for example via setColorFilter/tint) will be recorded with their untinted fill color, whereas the Q mapper below still applies the filter; keep the color-filter handling for this branch too.
Useful? React with 👍 / 👎.
Contributor
|
aleksandr-gringauz
approved these changes
Jun 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR does the merge of
developintofeature/view-updatebranch.Review checklist (to be filled by reviewers)