feat: Android double masking with frame drop

[abelonogov-ld]

Summary

Introduces double masking and if number of masks changed the frame being dropped.

How did you test this change?

Are there any deployment considerations?

---

Note

Double-pass masking with frame synchronization and stability check

• Collects masks twice (before/after a frame) and merges via MaskApplier.mergeMasksMap; drops capture if masks are unstable or counts differ
• Adds MaskApplier to render masks (pre/post paints) and centralize merge/draw logic; removes inlined drawing from CaptureSource
• Refactors capture pipeline: base window picked by index, captures stacked windows, synchronizes with Choreographer twice, recycles bitmaps safely, and guards with tiled signature check
• Minor UI/demo tweaks: add .ldMask() to ZIP and CVV fields (remove from header), small import/format changes

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

[cursor]

Condition check always true causing unnecessary canvas creation

Low Severity

The condition afterMasks.isNotEmpty() always evaluates to true because afterMasks is created from captureResults at line 141 with the same size, and execution only reaches this point when captureResults contains at least one element. This causes unnecessary Canvas creation and drawMasks calls even when there are no actual masks to apply. The intent, as indicated by the comment "if need to draw something on base bitmap additionally", appears to be checking if there are masks that need drawing, which would require checking if any inner lists contain masks (e.g., afterMasks.any { it?.isNotEmpty() == true }).

 

[cursor]

Bitmap memory leak on coroutine cancellation during frame wait

Low Severity

The second Choreographer.postFrameCallback wait (lines 132-139) occurs after bitmaps have been captured into captureResults but before the withContext(default) block that handles cleanup via recycleCaptureResults. If the coroutine is cancelled during this frame wait, the captured Bitmap objects are orphaned without being recycled. Since Android bitmaps hold native memory that requires explicit recycling, this causes a native memory leak. The suspendCancellableCoroutine lacks an invokeOnCancellation handler to recycle the bitmaps when cancellation occurs at this point.

 

[cursor]

Shared mutable Path causes thread-safety race condition

Medium Severity

The path field is now a shared member variable instead of being created locally within each drawMasks call as it was in the original code. Since MaskApplier is a single instance on CaptureSource and drawMasks executes on Dispatchers.Default (a multi-threaded dispatcher), concurrent capture operations can modify the same path object simultaneously. The drawMask method calls reset(), moveTo(), lineTo(), and close() on this shared path before drawing, which can corrupt path data when interleaved with another concurrent call, resulting in incorrect mask rendering.