Improve Appium (UiAutomator2) driver creation reliability

[mdshakib007]

Problem

Android test runs intermittently fail at session startup with:

SessionNotCreatedException: A new session could not be created.
java.lang.IllegalStateException: UiAutomation not connected

This is a UiAutomator2 race: when Appium creates a session it launches an on-device instrumentation server (io.appium.uiautomator2.server.test) that must hook into Android's UiAutomation accessibility service. On slow or just-booted emulators/devices — or when a prior session left the instrumentation in a bad state — that hook isn't ready in time and NEW_SESSION fails.

The existing retry loop masked the issue most of the time (the second attempt usually succeeds), but it could still fail outright due to three weaknesses:

1. No on-device cleanup between retries — a stuck instrumentation process caused every retry to fail the same way.
2. Stale-driver false positive — appium_driver is a global that wasn't reset before the loop; the old except: block left whatever value it previously held, so a dead/partial session could pass the if appium_driver: success check.
3. Timeouts too tight for a cold emulator, making the first attempt fail more often than necessary.

Changes (Framework/Built_In_Automation/Mobile/CrossPlatform/Appium/BuiltInFunctions.py)

• Reset the on-device UiAutomator2 server between retries — new best-effort reset_uiautomator2_server() helper force-stops io.appium.uiautomator2.server, io.appium.uiautomator2.server.test, and io.appium.settings via adb before each retry, so the next attempt starts the instrumentation cleanly instead of retrying into the same broken state.
• Fixed the stale-driver bug — appium_driver is reset to None before the loop and on every failed attempt; the loop now only succeeds when a real session_id exists, so a failed run can no longer masquerade as success.
• Added reliability capabilities (using setdefault, so user-supplied caps still win): uiautomator2ServerLaunchTimeout/uiautomator2ServerInstallTimeout/uiautomator2ServerReadTimeout (90s), adbExecTimeout (60s), androidInstallTimeout (120s), disableWindowAnimation, ignoreHiddenApiPolicyError.
• Better backoff and logging — progressive sleep (capped at 20s) and attempt-numbered log messages (attempt N/5) for easier diagnosis of future failures.

[riz-hossain]

🔎 ZeuZ PR Review

Open the full report in ZeuZ: Review findings and apply suggestions

Overview	Value
Agents	✅ 4 completed
Suggestions	💡 2

Agent breakdown

→ General Review

Status: ✅ Completed
Suggestions: 0 suggestions

No clear correctness or maintainability regressions stood out in this diff; the retry logic and cleanup are narrowly scoped to Android and appear internally consistent.

→ Security Review

Status: ✅ Completed
Suggestions: 1 suggestion

One critical command-injection issue was introduced in the new UiAutomator2 reset helper; the retry logic itself is otherwise fine.

→ Performance Review

Status: ✅ Completed
Suggestions: 0 suggestions

No high-signal performance issues found in this PR diff. The changes are bounded retry/recovery logic for Appium driver creation, with no obvious new N+1, unbounded data growth, or hot-path algorithmic regression.

→ Testing Review

Status: ✅ Completed
Suggestions: 1 suggestion

The PR changes the Appium driver startup flow in a way that clearly needs regression coverage, but I found no tests exercising the new retry/reset behavior or the new capability defaults.

Open ZeuZ to inspect full findings, continue an agent conversation, or apply safe patch suggestions.