Skip to content

Give the Android emulator fixed DNS servers - #1866

Open
Ewerton Scaboro da Silva (ewertons) wants to merge 2 commits into
mainfrom
fix-android-emulator-dns
Open

Give the Android emulator fixed DNS servers#1866
Ewerton Scaboro da Silva (ewertons) wants to merge 2 commits into
mainfrom
fix-android-emulator-dns

Conversation

@ewertons

Copy link
Copy Markdown
Contributor

Android test jobs intermittently fail with:

java.net.UnknownHostException: Unable to resolve host
"javasdkgate<random>-dps.azure-devices-provisioning.net":
No address associated with hostname
    at ContractApiHttp.request(ContractApiHttp.java:157)

thrown from the first HTTPS call, before any SDK logic runs.

Why it is the emulator's DNS

StartEmulator.sh started the emulator without -dns-server, so the guest resolves through the emulator's DNS proxy, which forwards to whatever resolvers the host agent has.

It is not deterministic. In build 162434, 5 of 17 tests in TestGroup1 failed on that hostname while the other 12 — which reach the same host through ProvisioningCommon — passed in the same emulator process. A missing or misdeployed resource would fail all 17.

Recent Android Test TestGroup1 failures, all the same exception:

Build Branch Failures / 17
161767 main 6
162061 PR #1862 11
162434 PR #1863 5
162511 PR #1863 6

4 of the last 39 Android builds (~10%), across main and unrelated PRs. DeployCloudTestResources succeeded in every one.

Change

  • -dns-server 8.8.8.8,8.8.4.4 on emulator start, so the guest does not depend on the host agent's resolver configuration.
  • One name resolution check logged after boot, so a later DNS failure can be told apart from an emulator that never had working resolution. It only logs and cannot fail the task.

Verification

  • bash -n: clean.
  • ShellCheck 0.10.0: same 3 pre-existing informational findings as the unmodified file, none new.
  • Not run end to end: that needs a macOS agent with the Android emulator, which I do not have. The gate on this PR exercises it.

Given the ~10% base rate, one green run will not prove this fixed. Several consecutive green Android runs would.

The Android test jobs intermittently fail with

  java.net.UnknownHostException: Unable to resolve host
  "javasdkgate<random>-dps.azure-devices-provisioning.net":
  No address associated with hostname

thrown from the first HTTPS call the test makes. It is not deterministic:
in the same emulator run, some tests resolve that hostname successfully
while others fail on it, and the number of affected tests varies from run
to run.

The emulator was started without -dns-server, so the guest resolves
through the emulator's DNS proxy, which forwards to whatever resolvers the
host agent has. Pointing the guest at fixed public resolvers takes the
host's resolver configuration out of the picture.

Also logs a single name resolution check after boot, so that a later DNS
failure can be told apart from an emulator that never had working name
resolution. That check only logs and cannot fail the task.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

This PR aims to reduce intermittent Android emulator test flakes caused by nondeterministic DNS resolution inside the emulator by explicitly configuring DNS servers at emulator startup and adding a lightweight, non-fatal post-boot resolution check for diagnostics.

Changes:

  • Start the Android emulator with explicit DNS servers (-dns-server 8.8.8.8,8.8.4.4) to avoid dependence on the host agent’s resolver configuration.
  • Add an adb shell name-resolution check after boot to help distinguish later DNS flakes from an emulator that never had working resolution.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread vsts/StartEmulator.sh Outdated
ping also fails when ICMP is not allowed out, which is common and
harmless on these agents, so its exit status cannot stand in for a DNS
verdict. Inspect the output for the resolution failure signatures
instead, and say explicitly when a ping failure was reachability rather
than name resolution.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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.

3 participants