How to Test Address Autocomplete on Android (Complete Guide)

Address autocomplete is a tiny UI widget that can make or break a user’s first impression. When it works, a user types a few characters and instantly sees a relevant suggestion, taps it, and moves on.

Why Address Autocomplete Deserves Focused Testing

Address autocomplete is a tiny UI widget that can make or break a user’s first impression. When it works, a user types a few characters and instantly sees a relevant suggestion, taps it, and moves on. When it fails, the user may abandon a form, enter an incorrect address, or trigger a crash that propagates to downstream services (shipping, tax calculation, fraud detection).

In production, autocomplete failures are often hidden behind device‑specific quirks: different IMEs, varying network latency, locale‑specific address formats, or accessibility services that intercept input events. A script that only checks the happy path on a single emulator will miss these issues, while a manual tester can only sample a fraction of the possible combinations.

Because the widget touches several layers—UI, input method, network, data storage, and sometimes native code—testing it requires a matrix that spans functional correctness, error handling, performance, accessibility, and privacy. The following sections give you a complete, practical guide to cover all of those angles on Android.

---

Common Ways Autocomplete Breaks in the Wild

Before we define what to test, it helps to see the patterns that repeatedly surface in bug reports and crash logs.

These categories form the backbone of our test matrix. Each one can be exercised manually, automated, or discovered by an autonomous explorer that simulates real user personas.

---

Test Matrix for Address Autocomplete

The table below lists the dimensions you should cover. For each dimension we note the test type (manual, automated, persona‑driven), the expected outcome, and a sample test case. Use this as a checklist when you build your test suite.

---

Manual Testing – Step‑by‑Step Walkthrough

A disciplined manual session helps you catch subtle UI glitches that automated checks may overlook. Follow this procedure on a physical device (or a well‑configured emulator) for each build you want to validate.

1. Prepare the device

• Clear app data (adb shell pm clear com.example.app) to start from a clean state.
• Set the desired language/region via Settings → System → Languages & input.
• Enable TalkBack (Settings → Accessibility → TalkBack) if you plan to test accessibility.
• Install a network‑throttling tool (e.g., clumsy on Windows or tc on Linux) to simulate 3G latency.

1. Launch the screen containing the autocomplete field

• Navigate to the address entry flow (signup, checkout, profile edit).
• Verify the field shows the correct hint (e.g., “Enter address”).

1. Happy‑path validation

• Type two characters. Observe that a dropdown appears within ~150 ms.
• Verify that the list is sorted by relevance (usually distance or popularity).
• Tap the first suggestion. Confirm the field text matches the suggestion exactly and the popup disappears.

1. Error‑path validation

• Activate network throttling to add a 2‑second delay. Type three characters.
• Expect a toast or inline error (“Unable to load suggestions”) and the field to retain its current text.
• Disable the network entirely. Type again; the app should show a permanent error state and allow a retry button.

1. IME and keyboard tests

• Switch to a different IME (e.g., SwiftKey, Hacker’s Keyboard). Repeat step 3.
• Connect a USB‑OTG hardware keyboard. Type using it; ensure the popup still appears and is positioned correctly.
• Rotate the device while the suggestion list is visible. The list should either stay anchored or re‑appear after rotation without flicker.

1. Accessibility checks

• With TalkBack enabled, move focus to the autocomplete field. It should announce “edit box, address entry, double tap to edit”.
• Navigate into the suggestion list using swipe gestures. Each item should be announced as a button containing the full address.
• Activate an item via double tap; verify the field updates and TalkBack announces the new value.

1. Security & privacy sniffing

• Connect the device to a workstation running adb logcat.
• Filter for your app’s tag (adb logcat | grep autocomplete).
• Type a test address and confirm no address string appears in the logs.
• If you use an analytics SDK, enable its opt‑out toggle, repeat the typing, and watch network traffic with HttpCanary or Charles Proxy to ensure no request to the analytics endpoint contains the query string.

1. Performance observation

• Enable the GPU profiling overlay (adb shell setprop debug.hwui.profile true).
• Type rapidly (≈8 cps) and watch for spikes >16 ms per frame.
• Note any jank that causes the suggestion list to lag behind the keystrokes.

1. Edge‑case scenarios

• Paste a string containing emojis, accented characters, and very long text (500 chars). Verify the app either sanitizes input or shows a graceful error.
• Simulate a duplicate backend response by intercepting the API call with MockWebServer and returning the same prediction twice. Ensure the UI shows only one entry.
• Change the device’s SIM card to one from a different country while keeping the locale unchanged. Observe whether the service biases results toward the SIM’s country (many geocoding APIs do this).

1. Final sign‑off

• Take a screenshot of the suggestion list in each language/locale you support.
• Archive the logcat output for the session.
• Compare against the baseline from the previous release to detect regressions.

When you finish, you should have a clear pass/fail verdict for each matrix cell. Document any deviations and create tickets for the development team.

---

Automated Testing on Android

Automated checks give you confidence that regressions are caught early and that you can run the matrix on every CI build. Below are the most effective techniques for address autocomplete, grouped by the layer they target.

Unit‑level Logic (ViewModel / UseCase)

If your autocomplete logic lives in a ViewModel (e.g., calling a repository that wraps the Places API), write plain JUnit tests with MockK or Mockito.

// AddressViewModelTest.kt
class AddressViewModelTest {

    private val repositoryMock = mockk<AddressRepository>()
    private val viewModel = AddressViewModel(repositoryMock)

    @Test
    fun `shows suggestions when repository returns non‑empty list`() {
        // arrange
        val fakeResponse = listOf(
            Suggestion("1600 Amphitheatre Pkwy, Mountain View, CA"),
            Suggestion("1600 Pennsylvania Ave NW, Washington, DC")
        )
        coEvery { repositoryMock.getSuggestions("1600") } returns fakeResponse

        // act
        viewModel.query("1600")

        // assert
        assertEquals(fakeResponse, viewModel.suggestions.getOrElse { emptyList() })
    }

    @Test
    fun `handles empty response gracefully`() {
        coEvery { repositoryMock.getSuggestions("xyz") } returns emptyList()
        viewModel.query("xyz")
        assertTrue(viewModel.suggestions.isNullOrEmpty())
        assertTrue(viewModel.errorMessage.isNotEmpty()) // UI shows hint
    }
}

*Why this matters*: Unit tests catch logic errors (e.g., faulty sorting, missing null checks) without needing an emulator, giving you fast feedback.

Instrumented UI Tests (Espresso)

Espresso excels at validating the interaction between the UI and the autocomplete dropdown. Use IdlingResource to wait for asynchronous network calls.

// AddressAutocompleteTest.kt
@RunWith(AndroidJUnit4::class)
class AddressAutocompleteTest {

    private val mockWebServer = MockWebServer()

    @Before
    fun setUp() {
        mockWebServer.start()
        // Inject the mock base URL into your app via Dependency Injection or BuildConfig
        ActivityScenario.launch<AddressActivity>()
    }

    @After
    fun tearDown() {
        mockWebServer.shutdown()
    }

    @Test
    fun `displays suggestions after two characters`() {
        // enqueue a delayed response to simulate latency
        mockWebServer.enqueue(
            MockResponse()
                .setResponseCode(200)
                .setBody("""{
                    "predictions": [
                        {"description": "1600 Amphitheatre Pkwy, Mountain View, CA"},
                        {"description": "1600 Amherst St, Buffalo, NY"}
                    ]
                }""")
                .setBodyEncoding("utf-8")
                .setHeader("Content-Type", "application/json")
                .setBodyDelay(2, TimeUnit.SECONDS)
        )

        onView(withId(R.id.address_input))
            .perform(typeText("1600"), closeSoftKeyboard())

        // Wait for the list to appear
        onView(withId(R.id.suggestion_list))
            .check(matches(isDisplayed()))

        onView(withText("1600 Amphitheatre Pkwy, Mountain View, CA"))
            .check(matches(isDisplayed()))
    }

    @Test
    fun `shows error toast on network failure`() {
        mockWebServer.enqueue(
            MockResponse()
                .setResponseCode(504)
                .setBodyDelay(5, TimeUnit.SECONDS)
        )

        onView(withId(R.id.address_input))
            .perform(typeText("1600"), closeSoftKeyboard())

        onView(withText(containsString("Unable to load")))
            .inRoot(ToastMatcher())
            .check(matches(isDisplayed()))
    }
}

Key points

• Use MockWebServer to control latency, error codes, and payload shape.
• Espresso’s onView with perform(typeText(...)) simulates real typing, including IME events.
• A custom ToastMatcher (available in the Espresso contrib library) lets you assert on transient messages.

UI Automator for System‑Level Interactions

When you need to test behavior that crosses app boundaries (e.g., the suggestion popup being obscured by the system status bar or a floating chat head), UI Automator is the right tool.

// AddressPopupUiAutomatorTest.java
@RunWith(AndroidJUnit4.class)
public class AddressPopupUiAutomatorTest {

    private UiDevice device;

    @Before
    public void setUp() {
        device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());
        // launch the app
        Context ctx = Registry.getInstrumentation().getTargetContext();
        Intent intent = ctx.getPackageManager()
                .getLaunchIntentForPackage(ctx.getPackageName());
        intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK);
        ctx.startActivity(intent);
    }

    @Test
    public void suggestionListNotCoveredByKeyboard() {
        // open the keyboard
        device.pressKeyCode(KeyEvent.KEYCODE_SHIFT_LEFT);
        device.pressKeyCode(KeyEvent.KEYCODE_SPACE);
        // type a few chars
        for (char c : "1600".toCharArray()) {
            device.pressKeyCode(KeyEvent.getKeyCode(String.valueOf(c)));
        }

        // get bounds of the suggestion list UI element
        UiObject2 list = device.findObject(By.clazz("android.widget.ListView"));
        assertNotNull(list);
        Rect listBounds = list.getVisibleBounds();

        // get bounds of the soft keyboard (approx via window frame)
        UiObject2 window = device.findObject(By.clazz("android.widget.PopupWindow"));
        Rect keyboardBounds = window != null ? window.getVisibleBounds() : new Rect();

        // ensure the bottom of the list is above the top of the keyboard
        assertTrue(listBounds.bottom < keyboardBounds.top);
    }
}

This test catches the frequent bug where the popup appears under the keyboard on certain device configurations (especially tablets with navigation bars).

Benchmark Tests for Performance

Use the Macrobenchmark library to measure end‑to‑end latency from keystroke to suggestion display.

// AddressAutocompleteBenchmark.kt
@get:Rule
val benchmarkRule = MacrobenchmarkRule()

@Test
fun `measure suggestion latency`() {
    benchmarkRule.measureRepeated(
        packageName = "com.example.app",
        metrics = listOf(FrameTimingMetric()),
        iterations = 5,
        setup = {
            // start at the address screen
            startActivityAndWait()
        }
    ) {
        // simulate typing two chars
        val input = device.findObject(By.res("com.example.app", "address_input"))
        input.setText("16")
        // wait a fixed time for suggestions to appear (you can also wait for a view)
        Thread.sleep(250)
    }
}

The resulting CSV report gives you the 50th, 90th, and 95th percentile frame times; you can assert that the 95th percentile stays below 200 ms.

Accessibility Test Automation

Leverage Accessibility Test Framework (ATF) from Google or the axe-android runner to scan for WCAG violations.

# Install the tester
pip install accessibility-test-framework-for-android

# Run on a connected device
atf run --app com.example.app --package com.example.app --test-target android.support.test.runner.AndroidJUnitRunner

The tool will output violations such as missing contentDescription, insufficient contrast, or touch targets smaller than 48 dp.

Security / Privacy Checks with Network Security Config

Ensure your app’s network_security_config.xml enforces HTTPS for autocomplete endpoints.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">maps.googleapis.com</domain>
        <domain includeSubdomains="true">api.example.com</domain>
    </domain-config>
</network-security-config>

Then add a unit test that asserts the config is present:

@Test
fun `network security config disallows cleartext`() {
    val xml = Resources.getSystem().getXml(R.xml.network_security_config)
    val domainConfig = xml.nextTag() // <domain-config>
    assertEquals("false", domainConfig.getAttributeValue(null, "cleartextTrafficPermitted"))
}

If you use a debugging proxy (e.g., Charles) in a debug build, make sure the config is overridden only for that build type.

---

Tooling & Libraries Cheat‑Sheet

Keep this table handy when you set up a new test module; most of the entries are available via Maven Central and add minimal overhead to your APK.

---

Edge Cases That Only Surface in Production

Even the most exhaustive lab matrix can miss issues that appear only when real users interact with the app under unpredictable conditions. Below are the most common production‑only gotchas and how to surface them deliberately.

1. Locale‑Specific Address Formats

Some countries require the postal code *before* the city (e.g., Japan), others use hyphens in postal codes (UK), and a few have multiple address lines. If your autocomplete view assumes a strict “street, city, state, ZIP” pattern, you’ll see truncated or malformed suggestions.

How to test

• Change the device locale to ja-JP, en-GB, ar-SA, and sv-SE.
• Type a known address (e.g., a Japanese postal code) and verify the suggestion respects the local ordering.
• Use a mock backend that returns address components in the native order; assert that the UI does not re‑order them incorrectly.

2. Carrier‑Dependent Country Detection

Many geocoding APIs prefer the SIM’s country code over the device locale when determining result bias. A user roaming abroad may get irrelevant suggestions.

How to test

• Insert a SIM from a different country (or use an emulator with -simulate-sim-country us).
• Keep the locale set to the home country (e.g., fr-FR).
• Type a generic query like “1600” and confirm that the results are biased toward the SIM’s country (US addresses appear first).

If your app does not expose a way to override this bias, consider adding a setting that lets the user lock the region.

3. IME‑Specific Inline Prediction

Certain IMEs (Gboard, SwiftKey, Samsung Keyboard) show their own inline suggestions above the soft keyboard. If your popup is anchored to the window’s top, it may clash with these inline bars, causing visual overlap or input lag.

How to test

• Enable each major IME, type slowly, and watch for any visual interference.
• Use the layout inspector to verify that the popup’s windowAnimations do not interfere with the IME’s inputMethodWindow.
• If you notice overlap, adjust the popup’s softInputMode to stateVisible|adjustResize or provide a custom DropDownAnchorView.

4. Background Data Restrictions

Android’s battery‑optimization may restrict background network access, causing the autocomplete service to fail after the app has been idle for a while.

How to test

• Put the app in the background, enable “Background restriction” in Settings → Apps → Your app → Battery.
• Return to the app, type a query, and observe whether suggestions appear.
• If they don’t, ensure you’re using a WorkManager or ForegroundService for the network call, or gracefully degrade to cached results.

5. Network Switch Mid‑Typed

Users often move from Wi‑Fi to cellular while typing. A sudden change in latency or DNS resolution can cause stale suggestions or duplicate requests.

How to test

• Start a Wi‑Fi connection with artificial 150 ms latency (tc qdisc add dev wlan0 root netem delay 150ms).
• Begin typing, then disable Wi‑Fi and enable a throttled cellular link (tc qdisc add dev rmnet0 root netem delay 500ms loss 5%).
• Verify that the request is cancelled and re‑issued correctly, and that the UI does not show two overlapping lists.

6. Accessibility Service Interference

Services like TalkBack, Switch Control, or third‑party screen readers can intercept key events, causing double‑typing or missed characters.

How to test

• Enable TalkBack, set speech rate to high, and type quickly.
• Confirm each character appears once in the field and that suggestions update after each character.
• If you see missing characters, ensure your EditText does not consume key events (android:imeOptions="flagNoExtractUi" may help).

7. Data‑Quota Exhaustion

On metered connections, the OS may block further network requests after a quota is hit. Autocomplete should degrade gracefully rather than crash or show a blank spinner forever.

How to test

• Use adb shell cmd netpolicy set-metered true to mark the current network as metered.
• Simulate a quota breach by returning HTTP 429 (Too Many Requests) from the mock server after a few calls.
• Verify the app shows a friendly message (“Network limit reached – try later”) and allows the user to retry manually.

By deliberately reproducing these conditions in a controlled environment (using adb, tc, or a custom test harness), you turn “production‑only” bugs into reproducible failures you can fix before release.

---

Concise Checklist for Release

Before you tag a build as ready for production, run through this short list. Each item can be verified with a combination of manual spot‑checks and automated CI jobs.

If any item fails, create a ticket, fix the root cause, and re‑run the checklist before proceeding.

---

Autonomous, Persona‑Driven Exploration – Where Scripts Fall Short

Traditional test suites excel at verifying *what you told them to check*. They are less effective at discovering *what you never imagined* a user might do. This is where an autonomous QA platform that simulates real user personas adds value.

How Persona‑Driven Search Works

A persona‑driven explorer builds a behavioral model for each user type (e.g., “impatient teen”, “elderly novice”, “power user”, “adversarial tester”). The model dictates:

• Typing speed and error rate (impatient users type fast and often backspace; elderly users type slowly with occasional mis‑hits).
• Navigation patterns (power users may swipe to open the navigation drawer while typing; novice users may stare at the keyboard).
• Reaction to system events (an adversarial persona may rotate the device rapidly, enable TalkBack, or toggle airplane mode).
• Tolerance for UI quirks (a curious user will long‑press on suggestions to see context menus; a security‑conscious user will watch logcat for leaks).

The explorer then drives the actual Android UI (via UiAutomator or Accessibility Service) using those profiles, without any pre‑written test script. It records every screen visited, every action taken, and any anomaly (crash, ANR, dead button, accessibility violation, unexpected network call, etc.). Over successive runs it builds a knowledge base of *dead ends*—UI states that lead nowhere—and avoids re‑exploring them, making each session more efficient.

What It Finds That Scripts Miss

Because the explorer does not rely on pre‑written assertions, it surfaces *behavioral* bugs that are often only caught after a real user complains in the wild.

Integrating SUSA for Address Autocomplete

SUSA (SUSATest) is an autonomous QA agent that you can point at an APK or a web URL. It automatically:

1. Installs the app on a fleet of real or emulated devices.
2. Selects a persona set (you can enable all eight built‑in personas or curate a subset).
3. Drives the UI, exercising every clickable element, text field, and gesture.
4. Detects crashes, ANRs, dead buttons, WCAG violations, security