---
title: "Verify Android selection survives prepared rotation"
description: "Check that Android list selection and pending edits remain consistent across an externally controlled orientation change without accidental bulk actions."
canonical_url: "https://vostride.com/agent-library/android-flows/rotation-keeps-selection.md"
md_url: "https://vostride.com/agent-library/android-flows/rotation-keeps-selection.md"
content_kind: "recipe"
topic: "android-flows"
---

# Verify Android selection survives prepared rotation

Check that Android list selection and pending edits remain consistent across an externally controlled orientation change without accidental bulk actions.

## Risk

Activity recreation can detach selected rows from their visible checkmarks. Use a prearranged device-control checkpoint and an exact identifier set to distinguish a restored screen from restored selection semantics.

## Fixtures

- A sandbox Android target using use.mobile.appState: preserve with a prepared account and five distinguishable tasks.
- An external device controller prepared to rotate the test device at a named checkpoint; rotation is fixture orchestration, not an assumed agent-qa device action.
- A read-only task oracle plus an explicit product requirement that multiselect survives orientation changes. This retention recipe applies only when the product promises to preserve the selection.

## Steps

1. Open the task list, select only tasks A and C, and verify their checkmarks and the selected-count label of two.
2. At the prepared rotation checkpoint, wait for the external controller to report completion and verify the list is visible in the new orientation.
3. Verify A and C remain checked, all other rows remain unchecked, and the selected-count label is still two. Stop and report a failed retention assertion if the selection was reset; do not reselect the rows to make the archive step pass.
4. Apply the sandbox-only archive action and verify precisely A and C leave the active list while B, D, and E remain.
5. Inspect the task oracle and verify the archived identifier set is exactly A and C; return to portrait through the prepared controller and verify no selection reappears unexpectedly.

## Expected results

- The selected identifiers and count agree after activity recreation.
- Only the intended two tasks have an archived status in independent data.
- The remaining three tasks preserve their original titles and active statuses.

## False-pass traps

- A count of two can accompany the wrong restored row identities.
- A refreshed list can look correct while a stale selection archives an unrelated task off screen.

## Cleanup

- Restore the two archived test tasks and return the device fixture to its baseline orientation.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa mobile testing](/docs/agent-qa/guides/mobile-testing.md)
- [agent-qa test](/docs/agent-qa/configuration/test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)

- [Android application QA recipes](/agent-library/android-flows.md)
- [Software factory QA library](/agent-library.md)