At a community equipment library, the closing shift checks tomorrow's loans and puts the right kits on the shelf. The team wants to automate that read-only check, exercise a native Android app on a physical device, and see whether a phone agent can find the same booking after the display language changes. Use a dedicated test phone and fictional bookings. Each job has a different deliverable: a shift report, a regression result, and a trace explaining why the agent selected a particular record.
Schedule a small task that can stop cleanly
Start by opening the booking list by hand. Select tomorrow, wait for the loading indicator to disappear, and confirm that the date in the header matches the intended day. Write down what an empty list looks like and how the app displays a fetch error. The scheduled report should capture the requested date, the number of matching entries, the actual run time, and the outcome. An empty list can be a valid result. A locked screen should be recorded as a run that could not start, and a network failure should be recorded as a run that could not verify the list.
Use stable resource identifiers or accessibility labels when the app exposes them. For a screen with only pixel targets, record the device orientation, display size, and expected starting screen. Take a fresh screenshot before using a coordinate. Stop when the surrounding layout changes or an overlay covers the target. Repeated taps can hit an unrelated control if the first tap has already moved the app to another screen. Start the rehearsal with one read-only sequence and confirm that it never reaches the booking submission screen.
Give the scheduler a maximum run time and prevent overlapping runs. Compute tomorrow from the library's business time zone at runtime. Save both the intended trigger and the actual start time so a maintainer can distinguish a missed trigger from a device problem. Test once with a locked screen and once with a slow connection. If the device needs a staff member to unlock it, record the handoff and wait for that intervention. Keep a redacted screenshot for exceptions rather than exporting a complete booking list to the job log.
Exercise an Android regression on a real device
Set aside an approved test build, a test account, and a fixture that can be reset. Appium with the UiAutomator2 driver is an option for native and hybrid Android UI testing. Follow the upstream compatibility instructions for the Appium server, driver, Android platform tools, and device OS. Enable USB debugging on the approved test device, accept the host authorization there, and confirm that the host can see the expected serial number. When several phones are connected, identify the exact test device in the session configuration. This prevents the test build or generated actions from reaching a different handset.
Start with a successful reservation for fictional kit KIT-07. Verify the selected slot on the confirmation screen and inspect the booking through an authorized test backend. Restore the fixture and rehearse two failures. In the first, disconnect before the server receives the request. In the second, let the server accept the request but interrupt the response before the app receives it. A test stub or a controlled connection can make these cases repeatable. Reconnect and retry through the app. Check that there is one active reservation, the time slot remains correct, and the user can find the confirmed result in the list. Save the request times and record identifier so a reviewer can explain what happened.
Keep setup and assertions readable when generating a script. Put kit identifiers, times, and expected states in fixtures. Wait for a specific condition such as a readable result row after the loading indicator disappears. Record the device model, OS, app build, and selected locale with every run. A screenshot can prove what the app displayed. Pair it with the permitted backend observation when the requirement concerns the number of stored bookings. Clean up only records created by the run, using their test identifiers.
If the device is visible to the host but the session fails to start, check the chosen serial, driver compatibility, package name, and launch activity. If the session starts and then cannot find a control, collect the current view and element tree. Check whether the app is on the expected screen and whether a permission dialog or loading state has interrupted the path. This separates connection failures from locator failures and from actual changes in application behavior.
Let a phone agent work from fresh observations
Ask the agent to find tomorrow's KIT-07 booking in the test app and report the visible status. Give it a package allowlist and an action list limited to opening the booking view, choosing a date, scrolling, and reading the matching detail. Cap the run at eight actions. Before each action, inspect the foreground package and the visible controls. After each action, recheck the screen. Accept the result when the detail view shows the expected kit identifier and date. A matching title alone is insufficient when two records have the same label.
Use the element tree when it supplies reliable identifiers. A screenshot can help locate controls drawn on a custom canvas. Validate a proposed tap against the current image and a permitted region of the screen. If orientation changes or the keyboard appears, discard the earlier location and observe again. Stop when the system opens another app, asks for a permission, or presents an account switch. Capture the last successful action and the reason for stopping. When an external vision service is part of the design, rehearse with synthetic screens and define which views the service may receive.
Check the same lookup in two languages, both color themes, and at a larger text size. In English, Tomorrow may appear next to a calendar date, while a translated view may use a different label. Confirm the selected calendar date and kit identifier rather than depending on a fixed English label. Include a fixture with two matching names and different identifiers. If the agent cannot distinguish the records after inspecting the visible evidence, it should hand off the candidates with their identifiers.
Rehearse failures before handing over the workflow
Give the scheduler a locked device, then verify the run report identifies the failed prerequisite. Give the native regression a connection interruption after the server accepts a booking, then verify the single stored record. Put the phone agent on a system settings screen during lookup, then check that the trace ends before another action. Keep these three results beside the successful runs. After upgrading the application or automation tool, repeat the cases with the same fixtures so differences can be traced to the upgrade.
Common questions
Do these workflows require root?
Begin with the supported developer and testing interfaces on a dedicated phone. If a proposed action needs additional permissions, identify the specific action and decide whether the task requires it. An approved test interface or a human step can cover a missing capability. Record the prerequisite so someone else can reproduce the run.
How do I prevent an old job from resuming unexpectedly?
Assign each run an identifier, an expiry time, and a cancellation flag. Check them before sending the next action. After a restart, inspect the previous result and the current business state. If the booking already exists, collect its confirmation instead of submitting again. Keep read-only checks separate from operations that can write a record.
What is left to test after the emulator passes?
Pick representative physical devices and run the paths that depend on screen size, input, sleep, orientation, or network recovery. Keep the OS and build identifiers with the result. The emulator gives a repeatable baseline and the device report shows what happened on the selected hardware. Compare results with identical test data before attributing a difference to the device.