Decouple ui:controller:impl and ui:uistateadapter:capture from ui:components:capture

[davidjiagoogle]

Breaks the transitive dependency chain to exclude heavy development/tooling dependencies when JCA is embedded as an external library.

[gemini-code-assist]

Code Review

This pull request refactors the project by moving capture-related test tags and the DisabledReason enum from the ui:components:capture module to the ui:uistate module, while also adding corresponding localized string resources. Review feedback identifies a missing R class import in CaptureControllerImpl.kt required for string resource access and a bug where HDR_VIDEO_UNSUPPORTED_ON_LENS_TAG was assigned a duplicate string value.

[temcguir]

Decoupling ui:controller:impl and ui:uistateadapter:capture from ui:components:capture is the right goal for allowing JCA to be embedded externally.

However, moving test tags and UI string resources into ui:uistate highlights a deeper architectural issue: we are passing test tags through our state layer. Test tags in Compose are meant to identify structural UI nodes (e.g., a "Snackbar" component), not the data passing through them.

The cleanest architecture is to remove the testTag property from both SnackbarData and DisableRationale.

1. Our UI tests can find the UI element using a single static tag (like SNACKBAR_NODE_TAG defined in ui:components) and then inspect its text or semantics to verify the specific message or severity.
2. ui:controller should stop constructing SnackbarData and just emit domain events.
3. ui:uistateadapter:capture should evaluate constraints and provide the string resources for the rationales.

This severs the dependencies on test tags across the board and makes the state layer generic. I have left a few inline comments showing how we can distribute these changes.

[temcguir]

Looks great. See my one comment on ComposeTestRule.

[temcguir]

I noticed that the UI tests were updated to use waitForNodeWithText to globally search for the success/failure strings. This defeats the purpose of adding the SNACKBAR_NODE_TAG and could lead to flaky tests or false positives if that same text ever appears elsewhere on the screen.

Could you update the testing approach to ensure we are specifically inspecting the Snackbar? I recommend creating a new utility function in ComposeTestRuleExt.kt (e.g., waitForSnackbarWithText) that explicitly waits for a node matching both the SNACKBAR_NODE_TAG and the expected text.

Here is an example of what that could look like:

fun ComposeTestRule.waitForSnackbarWithText(
    @StringRes textResId: Int,
    timeoutMillis: Long = DEFAULT_TIMEOUT_MILLIS
) {
    val expectedText = getResString(textResId)
    waitUntil(timeoutMillis = timeoutMillis) {
        onAllNodes(hasTestTag(SNACKBAR_NODE_TAG) and hasText(expectedText))
            .fetchSemanticsNodes().isNotEmpty()
    }
}

You can then replace the waitForNodeWithText calls with waitForSnackbarWithText where appropriate in the test files. This will make the UI tests much more robust.