Harden Android DevFlow integration tests

[Redth]

The Android integration CI failure showed the app process still resumed while localhost agent calls started returning connection refused, which points at transient ADB/forward instability rather than a deterministic app crash. This hardens the test transport so hosted-runner blips do not cascade into dozens of false failures.

Changes

• Add opt-in transient transport retries to AgentClient and enable them only for Android integration fixture calls.
• Re-establish missing adb forward entries while Android tests are running.
• Debounce process-loss detection and fall back from pidof to ps -A before treating the app as gone.
• Capture forward-list and agent-status diagnostics when app-loss diagnostics are collected.
• Let DEVFLOW_TEST_ANDROID_SERIAL target connected physical devices for local debugging.

Validation

• dotnet test src/DevFlow/Microsoft.Maui.DevFlow.Tests/Microsoft.Maui.DevFlow.Tests.csproj -c Debug --logger "trx;LogFileName=devflow-unit-after-fix.trx"
• DEVFLOW_TEST_PLATFORM=android DEVFLOW_TEST_ANDROID_SERIAL=38020DLJG004ZG dotnet test src/DevFlow/Microsoft.Maui.DevFlow.Agent.IntegrationTests/Microsoft.Maui.DevFlow.Agent.IntegrationTests.csproj -c Debug --logger "trx;LogFileName=android-full-after-fix.trx" --results-directory artifacts/TestResults/devflow-integration/android-full-after-fix

[github-actions]

Expert Code Review: 3 findings posted inline (2 moderate, 1 minor) plus 1 overflow finding. See the lean summary comment for full details.

Generated by Expert Code Review (auto) for issue #287 · ● 20.1M

[Redth]

Thanks for the cross-cutting summary. Addressed all three inline findings (PID parsing, transient retry narrowing, test hang guard) plus the overflow finding: InitializePlatformAsync now calls a new IsPhysicalDeviceReadyAsync() helper first, and when DEVFLOW_TEST_ANDROID_SERIAL points at a non-emulator serial that adb get-state reports as device, AVD provisioning is skipped entirely so the physical-device path works without cmdline-tools installed. The discarded findings look reasonable to leave as-is for now; the pre-existing iOS CI failure is unrelated to this PR.

[Copilot]

Pull request overview

This PR hardens DevFlow’s Android integration test infrastructure against transient transport instability (notably ADB port-forward drops) to reduce CI flakiness that manifests as cascaded “connection refused” failures while the app is still running.

Changes:

• Added opt-in transient transport retry support to AgentClient and enabled it for Android integration tests.
• Improved Android integration fixture resiliency by re-checking/recreating ADB forwards, debouncing process-loss detection, and adding richer diagnostics capture.
• Added a unit test covering the new retry behavior in AgentClient.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/DevFlow/Microsoft.Maui.DevFlow.Tests/WebViewDriverTests.cs	Adds a unit test intended to validate transient retry behavior for connection-refused scenarios.
src/DevFlow/Microsoft.Maui.DevFlow.Driver/AgentClient.cs	Introduces configurable transient transport retries and applies them across many HTTP operations.
src/DevFlow/Microsoft.Maui.DevFlow.Agent.IntegrationTests/Fixtures/IntegrationTestBase.cs	Wraps raw HTTP helpers with Android-only transport retry logic for integration tests.
src/DevFlow/Microsoft.Maui.DevFlow.Agent.IntegrationTests/Fixtures/AppFixtureBase.cs	Enables the new AgentClient retry knobs for Android fixtures.
src/DevFlow/Microsoft.Maui.DevFlow.Agent.IntegrationTests/Fixtures/AndroidEmulatorFixture.cs	Adds forward re-establishment, debounced process probes, ps -A fallback, and extra diagnostics; supports targeting a physical device via env var.

[Redth]

Follow-up: round 2 of review feedback also addressed two findings this workflow had discarded - the non-idempotent POST/PUT/DELETE retry concern (added a RetryMutatingRequests opt-out, default true to preserve existing behavior, with XML docs spelling out the duplicate-side-effect risk) and the retry test's reliance on a fixed delay (bumped server startup to 500ms and added an elapsed >= retryDelay Stopwatch assertion that fails loudly if the retry path is ever skipped). The remaining discarded findings (ObjectDisposedException propagation, duplicate retry constants, misleading get-state error, monitor tick frequency) still look reasonable to leave as-is - the iOS CI failure is unrelated to this PR.

[github-actions]

Analysis of Finding: Missing serial validation in EnsureAgentPortForwardAsync

Verdict: Disagree — this is not a real issue in the actual code.

The reviewer's finding describes a pattern where parts[1] and parts[2] are read without validating parts[0]. However, the actual code in this PR does not use that pattern. Here's what EnsureAgentPortForwardAsync() actually does:

var hasForward = exitCode == 0 && output
    .Split('\n', StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries)
    .Any(line => line.StartsWith(_serialNumber, StringComparison.OrdinalIgnoreCase)
        && line.Contains(expectedForward, StringComparison.Ordinal));

It explicitly checks line.StartsWith(_serialNumber, ...) — this does validate that the line belongs to this device's serial number. A forward rule from another device would not match because its line would start with a different serial.

Addressing the three considerations:

1. Does adb -s <serial> forward --list scope output? — The code uses adb forward --list (without -s), so it gets all devices' forwards. However, the line.StartsWith(_serialNumber, ...) check correctly filters to only this device's lines.

2. Multi-device CI environments — Even if multiple devices are connected, the StartsWith(_serialNumber) check prevents false positives from other devices' forward rules.

3. Severity of a false positive — A false positive (thinking the forward exists when it doesn't) would mean the fixture skips re-establishing the forward, potentially causing test connectivity failures. However, this scenario cannot occur with the current code because the serial filtering is correct.

The finding appears to be based on a code pattern that doesn't exist in the actual implementation.

Generated by Expert Code Review (auto) for issue #287 · ● 27.5M · ◷

[github-actions]

Expert Code Review: 3 findings posted inline. See the summary comment for full methodology and discarded findings.

Generated by Expert Code Review (auto) for issue #287 · ● 27.5M

[Redth]

https://github.com/dotnet/maui-labs/actions/runs/26180361507 Integration tests ran for android on this one too (manually)