[robert-goheen-cko]

Add a shared helper that manages window flags for the payment form and CVV component while they are shown. It resolves the hosting window (Activity, Fragment, dialog or bottom sheet), shares state between components on the same window, and restores the host app's settings afterwards.

Add unit tests and a README note.

Issue

Issue ticket number and link.

Proposed changes

Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.

Test Steps

If there's any functionality change, please list a step by step guide of how to verify the changes, and/or upload a screen recording for any visible changes.

For instance:

1. Go to the main screen
2. Tap on primary button
3. Verify the image is shown on the screen

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• Reviewers assigned
• I have performed a self-review of my code and manual testing
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if applicable)

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you choose the solution you did and what alternatives you considered, etc...

[Copilot]

🟡 Changes recommended

Critical lifecycle, dialog-window, and reference-counting defects can leave visible payment data without screenshot protection or keep an old window blocked after the UI is removed.

4 open issues

• Manage secure flags across view detach and reattachment · New
• Use a shared window key to coordinate secure-flag reference counts · New
• Secure dialog windows across attribute updates and recomposition · New
• Use current layout params when releasing FLAG_SECURE · New

What changed in this PR

Adds shared screenshot and screen-capture protection for the payment form and CVV component, with per-window tracking intended to preserve the host app’s existing security settings.

Changes:

• Introduces window resolution, secure-flag management, and shared reference counting.
• Integrates protection into both payment UI entry points.
• Adds registry unit tests and documents capture protection.

File	Description
README.md	Documents capture protection and flag restoration.
frames/​src/​test/​java/​com/​checkout/​frames/​utils/​SecureWindowRegistryTest.kt	Tests flag ownership and shared reference counting.
frames/​src/​main/​java/​com/​checkout/​frames/​utils/​SecureWindow.kt	Implements window targeting and secure-flag lifecycle management.
frames/​src/​main/​java/​com/​checkout/​frames/​cvvinputfield/​api/​InternalCVVComponentMediator.kt	Applies protection to the CVV component.
frames/​src/​main/​java/​com/​checkout/​frames/​api/​PaymentFormMediator.kt	Applies protection to the payment form.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

The pre-draw callback can allow sensitive content to render before FLAG_SECURE takes effect, while hidden payment fragments can keep the flag set instead of restoring the host setting.

2 open issues

• FLAG_SECURE may be applied after sensitive content is drawn · New
• Hidden payment fragment keeps FLAG_SECURE set · New

4 resolved since last review

• Secure dialog windows across attribute updates and recomposition
• Use a shared window key to coordinate secure-flag reference counts
• Manage secure flags across view detach and reattachment
• Use current layout params when releasing FLAG_SECURE

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Two lifecycle issues can leave screenshot blocking enabled after the payment UI is hidden or removed: clearing the wrong target and a stale pre-draw watcher reapplying FLAG_SECURE.

1 open issue

• Deactivate the watcher during cleanup to prevent re-enabling FLAG_SECURE · New

1 previously missed issue

In code that hasn't changed since last review

Restore secure state using the target that acquired it

frames/​src/​main/​java/​com/​checkout/​frames/​utils/​SecureWindow.kt:283

If a WindowSecureTarget acquires first and a RootViewSecureTarget for the same decor view releases last, restoration uses the wrong target. When the root's layout parameters are a separate copy, the final clear leaves Window.attributes secure, so a later window attribute update re-enables screenshot blocking after both components are gone. Retain the acquiring target in Entry and use it for the final clear.

2 resolved since last review

• FLAG_SECURE may be applied after sensitive content is drawn
• Hidden payment fragment keeps FLAG_SECURE set

_{Review effort: Balanced}

[robert-goheen-cko]

Re the previously missed issue in the latest review (restoring through the acquiring target): fixed in dc19a11. The registry entry keeps the target that acquired the window and uses it for the final clear. Added a unit test.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

🔵 Needs a closer look

Screenshot protection depends on Android callback and rendering timing across Activity and dialog hosts, requiring device-level validation of capture prevention and lifecycle restoration beyond the registry-only JVM tests.

No open issues 🎉

1 resolved since last review

• Deactivate the watcher during cleanup to prevent re-enabling FLAG_SECURE

_{Review effort: Balanced}