Skip to content

fix debug screen zoom control bug#538

Open
Kimblebee wants to merge 4 commits into
mainfrom
kim/clickable-interactionsource-bug
Open

fix debug screen zoom control bug#538
Kimblebee wants to merge 4 commits into
mainfrom
kim/clickable-interactionsource-bug

Conversation

@Kimblebee

Copy link
Copy Markdown
Collaborator

fix debug screen zoom control bug where debug zoom controls were missing from accessibility tree, which led to automated test failures on some devices.

…er interactive controls were missing from the Android Accessibility tree—causing automated test failures on some devices—due to passing `null` to the `interactionSource` parameter in `clickable` modifiers.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces UI Automator compatibility tests in ExternalAutomationCompatibilityTest, expands the debug overlay tests, and updates several Compose components to use a remembered MutableInteractionSource instead of null in clickable modifiers. The review feedback correctly identifies multiple violations of the repository style guide where JUnit's assertNotNull was used instead of Google Truth's assertWithMessage assertions.

}

companion object {
private const val TIMEOUT_MS = 5000L

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are waiting for the Capture and Flip buttons right after runMainActivityScenarioTest launches the app, we are subject to the same cold-start emulator delays (like virtual camera HAL initialization) that the rest of the app tests face.

Instead of defining a custom 5000ms timeout here, could we import and use APP_START_TIMEOUT_MILLIS (which is 20,000ms) from UiTestUtil.kt for the initial button checks? We can also use DEFAULT_TIMEOUT_MILLIS for the subsequent dialog checks. Using the centralized timeouts helps keep our CI flakiness mitigations consistent across the codebase!

Comment on lines +48 to +51
@Before
fun setUp() {
device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add an @After block to clean up the device state. Since the setZoomRatio test opens a dialog and interacts with a text field, we should ensure the screen is cleared for the next test.

@After
fun tearDown() {
    device.pressBack()
    device.pressHome()
}

fun verifyUiAutomator_canFindCaptureControls() {
runMainActivityScenarioTest {
// Wait for the capture button to be visible to UI Automator via Resource ID
val captureButton = device.wait(Until.findObject(By.res(CAPTURE_BUTTON)), TIMEOUT_MS)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To ensure maximum compatibility across different Android OS versions in ATP/TAP, it's safer to provide the fully-qualified package format for UIAutomator's By.res(). Stricter OS versions will sometimes fail to match bare resource strings.

val pkg = InstrumentationRegistry.getInstrumentation().targetContext.packageName
val captureButton = device.wait(Until.findObject(By.res(pkg, CAPTURE_BUTTON)), TIMEOUT_MS)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants