feat: Initial version of double masking

[abelonogov-ld]

Summary

Initial version double masking. Doesn't work perfect but masks should be more stable

Are there any deployment considerations?

---

Note

Implement double-pass masking in the capture pipeline using MaskApplier, collecting masks before/after a frame and drawing only stable masks; update demos and minor cleanups.

• SDK – masking/capture pipeline:
  • Introduce MaskApplier to draw masks and filter "before" masks against "after" masks for stability.
  • Revamp CaptureSource to:
    • Select base window by index; capture a list of windows from base upward.
    • Collect masks twice (before and after a choreographer frame) and apply only stable masks.
    • Compose results onto the base bitmap; remove inlined mask-drawing logic and related imports.
  • Minor adjustments in mask targets:
    • ComposeMaskTarget: stop subtracting root offsets in polygon points.
    • NativeMaskTarget: reuse matrix with reset; add comment, keep offset correction.
• E2E/demo:
  • Compose form: apply ldMask to ZIP Code and CVV; remove header ldMask; minor layout tweaks.
  • XML activity: remove unused import.

^{Written by Cursor Bugbot for commit a053d38. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Axis-aligned rectangle masks may use wrong coordinates

When mask.points forms an axis-aligned rectangle (no rotation), the code falls through to use mask.rect coordinates instead of constructing a rectangle from the points values. However, these coordinate systems can differ: mask.rect contains window-relative coordinates from getLocationInWindow(), while mask.points contains root-relative coordinates (screen position minus locationOnScreen(root)). These only match if the root view is at window position (0,0). For views in dialogs, popups, or non-standard window configurations where the root view has an offset within the window, the mask will be drawn at the wrong position. The old code always used points when available, avoiding this coordinate mismatch.

 

[cursor]

Bug: Empty mask maps cause all captures to fail

The filteredBeforeMasksMap function returns null when afterMasksMap.count() == 0, even if both maps are empty (no masked elements). In CaptureSource.kt, this null return causes the capture to be discarded via the ?: return@withContext null pattern. This means screens without any masked elements will never produce a capture event, which is likely unintended behavior.

Additional Locations (1)

• sdk/@launchdarkly/observability-android/lib/src/main/kotlin/com/launchdarkly/observability/replay/capture/CaptureSource.kt#L154-L155

 

[cursor]

Bug: Compose masks use different coordinate system than Native masks

The removal of the rootX/rootY adjustment from ComposeMaskTarget.points() creates an inconsistency with NativeMaskTarget.points(), which still subtracts context.rootX and context.rootY from the coordinates. Now Compose masks return screen coordinates while Native masks return window-relative coordinates. When both types of masks are drawn on the same canvas, the Compose masks will be offset incorrectly.

 

[cursor]

Bug: Missing continue causes incorrect capture counting logic

When captureResult is null and i != 0, the code sets beforeMasks[i] = null but then falls through to increment captured++ and assign captureResults[i] = captureResult. A continue statement is missing after setting beforeMasks[i] = null. This causes captured to count all loop iterations rather than just successful captures, making the if (captured == 0) check at line 129-131 dead code since captured is always incremented.