Blog

Android Background Restriction Testing: Doze, WorkManager & ADB

by Rajesh K | Oct 16, 2026 | Mobile App Testing, Blog, Latest Post | 0 comments

Android background restriction testing is most useful when it treats Doze, App Standby, App Standby Buckets, user-applied battery restriction, and Battery Saver as different operating-system states. Start with an unrestricted baseline, apply one deliberate restriction, verify that the state is actually active, trigger the production path, collect app, scheduler, and backend evidence, remove the restriction, and then verify recovery. Android can legitimately defer jobs, alarms, network access, and other background work. That means the central QA question is not simply whether the work ran immediately. It is whether the app preserved the user’s intent, reported the state truthfully, and recovered without loss or duplication when Android allowed work again. Android documents both the background limits and the ADB controls needed to reproduce several of these states in a test environment (Optimize for Doze and App Standby: Test power-related issues). Codoid’s mobile app testing services apply this same state-based discipline to production Android releases.

Updated for Android 17 and API 37. Research refreshed 7 October 2026.

Table of Contents

• What Android Background Restriction Actually Means
• Doze vs App Standby
• App Standby Buckets and the Restricted Bucket
• User-Applied Background Battery Restriction
• Battery Saver and Charging State
• Why Foreground State Changes the Expected Result
• Exceptions That Change the Expected Doze Result
• Prepare a Repeatable Background-Restriction Test
• ADB Command Cookbook for Each Android Restriction
• How to Test JobScheduler and WorkManager Under Restrictions
• Android 16 and 17 Quota and Pending-Job Diagnostics
• How to Test Alarms Under Doze and Background Limits
• Android 14+ Exact-Alarm Access Test Matrix
• How to Validate Background Network Calls and Sync
• Test Recovery When Android Releases the Restriction
• A Practical Android Background-Restriction Test Matrix
• Common False Positives in Android Background Testing
• Automating Background-Restriction Tests in a Device Pipeline
• Copy-Ready Defect Evidence Bundle
• Android Background-Restriction Release Checklist
• Conclusion

Need the commands first? Use the quick-reference table below, then return to the detailed sections for version gates, exceptions, assertions, and recovery checks.

Test invariant: deferred is not failed. A restricted-state test can pass even when work does not run immediately. The pass condition is that the operation remains durable, the app does not claim success prematurely, the block is explainable from evidence, and recovery reaches the correct final state.

The table is a shortcut, not a substitute for state verification. In particular, exit code 0 from an ADB command does not prove that an OEM build mapped the command to the state you intended to test.

The first testing mistake to avoid is collapsing every power-management feature into one generic “background mode.” The mechanisms are related, but their triggers and contracts differ.

Doze is mainly a device state. Android enters idle power-saving behavior when the device is unused, and it defers battery-intensive activity such as jobs, syncs, standard alarms, and ordinary background network access. Android provides dumpsys deviceidle force-idle specifically so testers can reproduce this behavior rather than waiting for natural idle conditions.

App Standby is mainly an app state. The system can treat one app as inactive when the user has not recently interacted with it. A test result should therefore identify whether the whole device was forced into Doze, one app was marked inactive, or a different restriction was active. “The worker did not run” is not enough diagnostic information.

App Standby Buckets add a usage-based resource policy on top of basic standby. The Restricted bucket is the most aggressive standard bucket for background limits. Android notes that Restricted-bucket limits continue even while the device is charging, although some conditions can loosen specific restrictions.

For QA, that means a charging device is not a universal “restrictions off” state. Record charging status, but keep Restricted-bucket tests distinct from ordinary App Standby tests.

A user can place an app in a Restricted battery state through system settings. Android states that the precise restriction is manufacturer-dependent. On AOSP builds, jobs and alarms may not execute in the background, and foreground service behavior is also constrained.

On API 28 and higher, the app can query ActivityManager.isBackgroundRestricted() to determine whether the user has enforced background restrictions. Android also states that these user restrictions remain in effect even when the device is charging.

A Pixel or emulator result is therefore a reference point, not proof of behavior across Samsung, Xiaomi, Oppo, Vivo, or other supported OEM builds. Repeat the highest-risk cases on representative physical devices from the product’s support matrix.

Battery Saver is a separate device-wide condition. Charging can release ordinary App Standby and removes many resource limits, but Android’s current resource table explicitly keeps job execution limits for the Restricted standby bucket and notes that user-applied background restriction can still constrain alarms while charging.

Record charging, Battery Saver, standby bucket, and user-restricted state as separate fields. Do not reduce them to one boolean such as batteryRestricted = true.

Foreground state changes the contract because Android treats a visible app, an app with a foreground service, and a background app differently. Android 16 also changed job runtime quota enforcement so jobs that start while an app is visible or while a foreground service is running can still become subject to runtime quota after conditions change.

Record the app state both when work is scheduled and when the restriction takes effect. Otherwise, a pass or failure can be attributed to the wrong mechanism.

Two exceptions deserve explicit preconditions because they can make a valid Doze test look wrong.

• Battery-optimization exemption. A partially exempt app can use the network and hold partial wake locks during Doze and App Standby, although other restrictions still apply. Android exposes PowerManager.isIgnoringBatteryOptimizations() so an app can report whether it is on the exemption list. Capture that value before any Doze network assertion.
• Firebase Cloud Messaging priority. Normal-priority FCM can be delayed during Doze. High-priority FCM can wake the app and temporarily provide limited network access or partial wake-lock opportunity so the app can deliver time-sensitive, user-visible notifications. Google warns that high priority should be reserved for appropriate user-visible messages. Misuse can lead to deprioritization.

If the product uses FCM, test these paths separately.

• Normal-priority message while the device is in Doze
• High-priority message that produces the intended user-visible notification
• Any follow-up WorkManager work scheduled from the message handler
• Behavior when the app is or is not exempt from battery optimization

A generic assertion such as “network must be unavailable in Doze” is therefore too broad unless exemption and FCM conditions are known.

Before applying any restriction, run the same job, alarm, or network operation in an unrestricted baseline. If the flow already fails, a power-management test cannot isolate the cause.

Capture these fields for every case.

Use synthetic records and a unique correlation ID. For example, qa-bg-2026-10-07-001 makes it possible to determine whether the operation was sent once, retried safely, duplicated, or never sent.

A practical record format is:

    Precondition
        ↓
    Trigger
        ↓
    Restriction
        ↓
    Verify restriction
        ↓
    App assertion
        ↓
    Scheduler evidence
        ↓
    Backend evidence
        ↓
    Release restriction
        ↓
    Recovery assertion
    

Figure 1. QA diagnostic flow for Android background restriction testing. The evidence sequence is more important than any single ADB command.

The commands below assume a connected test device or emulator and a known package name. Production automation should version-gate commands and verify the resulting state.

    PACKAGE=com.example.app
    

Force and Exit Doze

Android documents the following Doze sequence on API 23 and higher.

    adb shell dumpsys deviceidle force-idle
    

Before interpreting the result, also record whether the app is on the battery-optimization exemption list and whether an FCM message is normal or high priority. Those conditions can change the expected network behavior.

When the observation window ends:

    adb shell dumpsys deviceidle unforce
    adb shell dumpsys battery reset
    

The restricted-phase assertion should focus on whether work remains durable and correctly represented. Recovery is checked after leaving Doze.

Place One App in App Standby

    adb shell dumpsys battery unplug
    adb shell am set-inactive "$PACKAGE" true
    adb shell am get-inactive "$PACKAGE"
    

Restore the pre-test inactive state rather than blindly assuming false was the original value. A simple exploratory test can manually restore false. A shared or automated lab should snapshot first.

Move an App Through Standby Buckets

For supported versions:

    adb shell dumpsys battery unplug
    adb shell am set-standby-bucket "$PACKAGE" restricted
    adb shell am get-standby-bucket "$PACKAGE"
    

When testing manually, record the original bucket before mutation. In automation, restore that exact bucket after the case. Avoid fixed timing assertions for Rare or Restricted unless the product requirement and platform contract actually promise that timing.

Apply and Verify Manual Background Restriction

Android’s power-testing page currently uses RUN_ANY_IN_BACKGROUND ignore to apply the restriction and allow to remove it.

    adb shell cmd appops set "$PACKAGE" RUN_ANY_IN_BACKGROUND ignore
    

Another current Android page uses deny, so treat the app-op token as build-dependent supporting evidence rather than proof by itself.

For API 28 and higher, expose or log the app-side signal:

    val activityManager = getSystemService(ActivityManager::class.java)
    Log.d("BgRestriction",
      "restricted-${activityManager.isBackgroundRestricted}")
    

Use ActivityManager.isBackgroundRestricted() as an application-visible check for user-enforced restriction. In automated labs, also capture the relevant appops output because OEM and build behavior can differ.

Simulate Background-Service and Implicit-Broadcast Restrictions

RUN_IN_BACKGROUND is a different app-op and should have a different test case:

    adb shell cmd appops set "$PACKAGE" RUN_IN_BACKGROUND ignore
    

Restore the original mode after testing. Do not label this result as Doze.

Test Battery Saver

Android documents:

    adb shell dumpsys battery unplug
    adb shell settings put global low_power 1
    adb shell settings get global low_power
    

The documented cleanup is:

    adb shell dumpsys battery reset
    

After cleanup, verify the resulting state. In a shared lab, record the initial power-simulation state before mutation so the test does not silently inherit or overwrite another scenario.

For JobScheduler and WorkManager, distinguish scheduled, eligible, running, stopped, retried, and completed. A worker that remains queued while the OS deliberately blocks it may be correct.

Start with one known unit of work and one correlation ID. Trigger it through the production scheduling path, then apply one restriction at a time.

Assert Deferred, Running, Stopped, Retried, and Completed States

When a job does not run, verify in this order:

• Confirm the app scheduled the work.
• Confirm WorkManager or JobScheduler still knows about it.
• Confirm the intended restriction is active.
• Inspect pending or stop reasons where available.
• Release the restriction and verify the same logical operation recovers.

Stop-Reason Version Gates

Be explicit about dependency and platform gates.

• WorkInfo.getStopReason() and ListenableWorker.getStopReason() were added in WorkManager 2.9.0 and are annotated for API 31 and higher.
• JobParameters.getStopReason() is a platform API available from API 31.

If a stop reason is unavailable on an older device or older WorkManager dependency, that is a platform or dependency limitation, not automatically an app defect.

Treat stop reasons as diagnostics. They are not a substitute for determining whether a user transaction is safe to retry.

Android 16 Runtime-Quota Scenarios

Android 16 and API 36 changed runtime quota enforcement for regular and expedited jobs, including work started while the app was visible or while a foreground service was running. Google states that the behavior affects WorkManager, JobScheduler, and DownloadManager.

Add at least these transitions for Android 16 and higher.

• Start a job while the activity is visible, then background the app.
• Run a job while a foreground service is active and observe quota-related stopping.
• Repeat high-risk jobs across relevant standby buckets.

Android 17 Pending-Job Diagnostics

Android 16 added pending-job reason APIs. Android 17 and API 37 adds getPendingJobReasonStats(), which aggregates time spent pending for reasons such as App Standby, background restriction, connectivity, device state, or quota.

Use this information as diagnostic evidence, not as a product SLA. Android notes that the statistics are not persisted across reboot and can be cleared by completion or cancellation.

Why jobscheduler run -f Is Diagnostic Only

Android documents:

    adb shell cmd jobscheduler run -f APP_PACKAGE_NAME JOB_ID
    

for forcing a job to run or retry, and:

    adb shell cmd jobscheduler timeout APP_PACKAGE_NAME JOB_ID
    

for simulating a system stop.

These commands are useful failure-injection tools. A forced run proves that the job implementation can execute. It does not prove that natural scheduling works under the restriction being tested.

Alarm testing needs its own assertion model because Android treats inexact, exact, allow-while-idle, and alarm-clock alarms differently.

Inexact Alarms

Record scheduled trigger time, actual delivery time, the active restriction, and the application outcome. The acceptable window should come from the product requirement and Android’s API contract, not from a tester-created “within five seconds” rule.

Exact and Allow-While-Idle Alarms

setExact() and setExactAndAllowWhileIdle() are different contracts. Test both normal and Doze conditions. If a use case must fire during idle, validate the allow-while-idle path and any associated exact-alarm access.

For apps targeting Android 13 and API 33 or higher, Android allows either SCHEDULE_EXACT_ALARM or USE_EXACT_ALARM, but their grant models differ.

A practical exact-alarm test sequence:

• Install fresh on Android 14 or higher with the relevant target SDK.
• Confirm canScheduleExactAlarms() is false where denial is expected.
• Verify graceful fallback and user guidance.
• Grant Alarms and reminders access.
• Verify capability becomes true and required alarms are recreated.
• Revoke access again.
• Verify stale “scheduled” UI is not shown and future behavior remains consistent.

Permission denial and Doze deferral are different failure classes. Keep them separate in defect evidence.

setAlarmClock()

Alarm-clock alarms are intended for explicitly user-visible, time-critical experiences. Test visible alarm information, sound and vibration as applicable, dismiss and snooze behavior, and process recovery. Do not test only the callback timestamp.

Treat every background network operation as interruptible. It may be delayed, stopped, retried, or committed server-side before the client records success. Test for correctness at each interruption point.

Uncertain Outcome Rule

If the server outcome is unknown, a retry must be duplicate-safe. Use idempotency keys, correlation IDs, server-side deduplication, or another product-appropriate mechanism. The QA assertion is the business outcome: one order, one message, one upload, one state transition. Not merely that the retry returned 200.

Illustrative Sync-Worker Scenario

This is an illustrative example, not measured client data.

Network Call Already in Progress When Restriction Begins

Start a uniquely identifiable server operation, then apply the restriction while the call is in flight. Determine whether the server committed the operation, whether the client recorded the response, and whether recovery causes a duplicate. Do not assume the OS must terminate every already-open socket at the moment a restriction is applied.

New Network Work Scheduled While Restricted

Schedule network-constrained work after the restriction is already active. In Doze, ordinary JobScheduler and WorkManager work and background network access can be deferred. With user-applied restriction, AOSP can also block normal background execution. The app should represent this as queued or pending until it has evidence of server success.

Connectivity Returns Before the OS Releases the Job

Disconnect the network, queue work, restore connectivity, but keep the app in the OS-restricted state. This verifies that the app does not confuse “network reachable” with “background operation completed.”

Restriction Ends After Multiple Queued Operations

Queue several dependent or conflicting operations while restricted. After release, verify ordering, conflict resolution, bounded retries, and the uncertain-outcome rule above. For deeper reconnect and sync-conflict coverage, see Codoid’s offline and online mobile behavior testing guide.

Recovery is part of the feature contract. A restricted-state case is incomplete until the final state is verified.

Check that:

• Eligible work resumes without unnecessary user intervention unless the product intentionally requires it.
• Retries do not duplicate already committed operations.
• Temporary files, queue rows, locks, or “syncing” UI settle into a stable state.
• Notifications are not emitted more than once for one logical event.
• User-visible status moves from pending to confirmed only after completion evidence exists.

Repeat the restrict and release cycle more than once. Lifecycle defects often appear on the second or third transition because counters, listeners, or locks were not reset.

Reboot Recovery for Target SDK 33+ Apps

If the product relies on BOOT_COMPLETED or LOCKED_BOOT_COMPLETED to reschedule alarms or jobs after reboot, add this conditional scenario for apps targeting Android 13 and API 33 or higher.

• Put the app in the user-restricted battery state.
• Reboot the device.
• Verify that expected boot-time work does not incorrectly appear to have been scheduled.
• Start the app for another reason.
• Verify the deferred startup or reconciliation path now restores the required state.

Android documents that, for target SDK 33+ apps in the Restricted state, BOOT_COMPLETED and LOCKED_BOOT_COMPLETED are withheld until the app starts for another reason.

For web publication, this matrix is best implemented as a responsive table. The grouped structure below separates the control from the evidence so each row stays scannable.

State and Control

Expected Evidence and Recovery

Codoid’s Mobile Testing Strategy: Coverage, Risks and Gates provides a broader framework for deciding which device and OS combinations and release gates deserve recurring coverage.

Avoid foregrounding the app just to “see whether it synced” during the restricted observation period. That user interaction can change App Standby or give the app a foreground opportunity.

Automation should preserve the device’s pre-test state. A hard-coded teardown that resets to active and allow is convenient for a disposable emulator but is risky in a shared lab because it can overwrite a realistic pre-existing state.

Snapshot Before Mutation

At minimum, capture the raw outputs you intend to change:

    PACKAGE="com.example.app"
    adb shell am get-inactive "$PACKAGE"
    adb shell am get-standby-bucket "$PACKAGE"
    adb shell cmd appops get "$PACKAGE" RUN_ANY_IN_BACKGROUND
    adb shell cmd appops get "$PACKAGE" RUN_IN_BACKGROUND
    adb shell dumpsys battery
    

Persist these raw outputs before mutation. Because appops and bucket output formats can differ across Android builds, a production harness should parse only recognized modes and buckets and abort before mutation if it cannot map the original value safely.

A safe cleanup sequence should:

• Leave forced Doze if the test entered it.
• Restore the original inactive state.
• Restore the original standby bucket.
• Restore the original app-op modes.
• Reset only the battery simulation the test owns.
• Re-run the same get and diagnostic commands and compare the final values with the snapshot.

A shared device-lab test should fail cleanup if it cannot prove that the state was restored. “Best effort” cleanup is not enough when a leaked restriction can invalidate later cases.

A practical pipeline should also record API level, device and build, app build, targetSdk, WorkManager version, correlation ID, restriction verification, WorkInfo state and attempt count, stop or pending reason where supported, and backend evidence.

Do not wait indefinitely for OS-scheduled work. Use a defined observation window, prove that work remains safely pending when appropriate, then deliberately release the restriction and test recovery.

When filing a background-execution defect, include:

• Device model, OEM, build, and Android API level
• App build, targetSdk, and WorkManager version
• Exact restriction and how it was verified
• Charging, Battery Saver, exemption, and FCM priority state
• Worker, job, or alarm ID and correlation ID
• Relevant WorkInfo or JobScheduler pending or stop reason
• Logcat excerpt around scheduling, stop, and recovery
• Local queue or database state
• Backend request, result, and duplicate count
• Cleanup verification and final recovery result

This makes “background sync failed” reproducible enough for Android developers and backend engineers to diagnose without guessing which layer blocked the work.

Before release, confirm that:

The release question remains simple: when Android delays or stops background execution as designed, does the app preserve the user’s intent and recover to a correct, explainable state?

Effective Android background restriction testing requires treating each power-management mechanism as a distinct state with its own contract. Apply one restriction at a time, prove it is active, trigger the production path, capture app, scheduler, and backend evidence, then release the restriction and verify recovery. The release question is simple: when Android delays or stops background execution as designed, does the app preserve the user’s intent and recover to a correct, explainable state?

If your release depends on reliable background jobs, alarms, sync, or recovery across an Android device matrix, Codoid’s mobile app testing services and mobile test automation services can help turn these state-based checks into repeatable release evidence. Keep the engagement scoped to the product’s actual supported Android versions, OEMs, and background-work risks.

Need Help Testing Android Background Restrictions?

Talk to a Mobile Testing Expert

Frequently Asked Questions

Local Network Testing: A QA Checklist for Mobile App Discovery

by Rajesh K | Oct 13, 2026 | Mobile App Testing, Blog, Latest Post | 0 comments

Imagine tapping Cast and seeing no television, even when it is powered on. Or opening a smart-home app that cannot control a nearby lamp after the internet drops, even though both devices remain on Wi-Fi. Did discovery fail? Was local access denied? Did the app confuse an internet outage with a LAN outage? These are different failures and require different tests.Local network testing for mobile apps verifies how an app discovers, connects to, authorizes, and controls nearby devices, and how it reports and recovers from interruption. This guide provides copy-ready test cases and fault-injection checks for Android, iOS, casting, and IoT workflows.

Start with the test checklist, then validate network paths, platform permissions including Android 17, discovery, casting, IoT access, and offline recovery. Codoid’s mobile app testing services apply this same discipline to production releases.

Table of Contents

• What Is Mobile App Local Network Testing?
• Copy-Ready Mobile Local Network Test Cases
• Build a Test Environment That Separates Failure Types
• Validate Local Network Permissions on iOS and Android
• iOS: Test Direct Access and System-Managed Features
• Android: Include Both OS Version and Target SDK
• Test Device Discovery Beyond the Happy Path
• Validate Casting Across Discovery, Playback, and Recovery
• Test IoT Access From Onboarding to Confirmed State
• Test Offline Recovery Without Losing the Meaning of an Action
• Automate the UI, Network Conditions, and Device Assertions
• Capture Evidence That Explains the Failure
• Define Release Gates Around User Outcomes

Local network testing checks device discovery, connection, permission state, authorization, command delivery, and recovery across a phone and nearby target device. In this article, a Cast receiver plays media. An IoT accessory executes a device command. The term “target device” covers either when a test applies to both.

Local network availability is not the same as internet availability. On a network with NET_CAPABILITY_INTERNET, the NET_CAPABILITY_VALIDATED flag indicates successful internet validation. It does not prove that a particular local accessory is reachable (Android API reference).

For testing purposes, assess these questions separately:

• Can the app use the relevant network and discover the target?
• Can it establish an authorized connection and complete the requested operation?
• Can it determine the outcome and recover when communication is interrupted?

A connected Wi-Fi icon cannot answer all three. Neither can a successful request to a cloud API.

Before testing, agree which features must work on the LAN without cloud access, which need a backend, and which may fall back to another transport. The expected behavior below is conditional on that contract.

Use one pass or fail verdict for the app and another for the target device. Run each scenario with known permission, cellular, and network states. Retain the listed evidence.

Rule: Evidence that a cloud probe failed does not prove the LAN still works. Record a separate discovery or control-path probe and a receiver or accessory assertion.

Use representative phones, casting receivers or IoT accessories, and an AP or router you can configure. Record build, OS version, Android target SDK, accessory firmware, AP or router firmware, network segments, IP family, baseline permission grants, and whether cellular data is disabled.

In every fault test, prove the fault was isolated. “App looks offline” is not evidence of whether the WAN, multicast discovery, or target endpoint is unavailable. Also test a backend-only outage while independent WAN and LAN probes succeed.

Probe selection depends on protocol. mDNS packet capture is relevant only if the product uses mDNS. SSDP, BLE, Wi-Fi Direct, and proprietary protocols require corresponding observability. ICMP ping alone does not prove that an app’s control port is usable.

Test AP and client isolation. The phone may still reach the internet while the access point blocks communication with nearby devices. Record whether the router isolates wireless clients, Ethernet-connected devices, or both (Google Cast troubleshooting).

Cover the supported mix of 2.4 GHz and 5 GHz clients, mesh handoff, Ethernet receivers, IPv4 and IPv6, and representative router firmware. Wi-Fi frequency band alone does not establish network segmentation. Add captive-portal, VPN, or roaming cases when the product supports them.

For segmented or guest networks, separately verify multicast discovery forwarding and routable access to the control endpoint. Bonjour discovery does not automatically cross subnet boundaries. A successful discovery response is not a connection guarantee.

Figure 1. Isolate discovery, local control, WAN media, and optional Thread paths.

Test first-use prompts, approvals, denials, Settings changes, and existing grants according to the exact OS, target SDK, and discovery API. A successful device list is not proof that the permission flow was correct.

On iOS, direct Bonjour browsing or advertising typically requires NSLocalNetworkUsageDescription and appropriate NSBonjourServices entries in Info.plist. Certain custom multicast operations need an additional entitlement. System-managed AirPlay can follow a different path. Do not assume one dialog model for all features (Apple TN3179).

For Google Cast iOS senders, verify NSBonjourServices contains both _googlecast._tcp and the receiver-app-specific service entry, for example _ABCD1234._googlecast._tcp, along with NSLocalNetworkUsageDescription. Test the point at which SDK discovery actually begins (Google Cast iOS permissions).

Exercise the complete permission journey: first use, approval, denial, later approval in Settings, and revocation after a successful connection. Repeat important cases after an app update and after relaunching the process.

Check that the explanation names the actual feature, such as finding televisions or connecting to a camera, rather than presenting a vague request. Also verify that declining access does not block unrelated app functionality.

Permission unresolved, access denied, no compatible device, and a discovered but unreachable endpoint require different diagnostics. When iOS has not yet resolved the request, allow for asynchronous discovery rather than immediately declaring denial (Apple local network privacy).

The OS version, app target SDK, and whether the app uses direct sockets or a system-mediated picker determine the expected Android permission behavior. Android 17 makes this decision especially important.

Read these tests against the official Android 17 permission guidance. A missing permission dialog is not by itself a defect. Target SDK, existing Nearby devices grants, and use of a supported picker all matter (Android Developers documentation).

Android 13 and later Wi-Fi management APIs may involve NEARBY_WIFI_DEVICES. Some scanning operations still require location permission. That API-specific rule should not be used as a blanket rule for direct Android 17 LAN sockets (Android Wi-Fi permissions).

Android 16 supports an optional compatibility mode for local-network restrictions. In that mode, NEARBY_WIFI_DEVICES is temporarily used. APIs operating outside the app process, including some NsdManager paths, may not be affected in the same way. Test the opt-in limitations explicitly.

Starting with Android 17, apps targeting SDK 37 or higher that use broad local-network access must declare and request ACCESS_LOCAL_NETWORK, unless they adopt an applicable privacy-preserving picker. The system can skip a new prompt when permission in the Nearby devices group is already granted (Android 17 behavior changes).

Android 17 supports privacy-preserving approaches such as the media output switcher for supported casting and the NsdManager system-run service picker using FLAG_SHOW_PICKER for appropriate mDNS discovery. A picker can avoid the broad local-network permission, but it does not authorize arbitrary unrelated sockets.

Apps targeting SDK 36 or lower retain a temporary legacy path with INTERNET-based implicit LAN access. Do not request ACCESS_LOCAL_NETWORK in that build. Migration to target 37 must be tested independently.

First identify the actual discovery stack: mDNS or Bonjour, SSDP, BLE, Wi-Fi Direct, a vendor protocol, or a hybrid. Choose probes and cache-expiry expectations for that stack rather than applying mDNS-specific assumptions to every product.

For mDNS only, multicast DNS uses UDP port 5353 and supports time-to-live-based record expiration. A clean shutdown may advertise a goodbye record, while unexpected power loss cannot. Evaluate stale-list behavior against the implemented stack (RFC 6762).

Appearance, Updates, and Disappearance

Start discovery with no devices available, then bring a compatible device online. Repeat with several devices, including two with identical display names.

Rename a device, change its network address, restart its discovery service, and reconnect it after an outage. Check that the app updates the correct entry instead of creating duplicates or retaining an obsolete endpoint.

Test clean disconnection and sudden power loss separately. Define an acceptable stale-device interval based on the protocol and product behavior. Do not require every device to disappear instantaneously.

Compatibility and Identity

Advertise a device that lacks a required capability or uses an unsupported firmware version. Verify whether the product should hide it, label it as incompatible, or explain the limitation during connection.

Do not use a display name or cached IP address as proof of trusted identity. A test device advertising a familiar name must not automatically inherit another device’s authorization.

Include unusually long names, non-Latin characters, missing metadata, and malformed discovery responses in a controlled test environment. The app should remain responsive and avoid displaying untrusted metadata unsafely.

Discovery Versus Connection

Test these as separate outcomes. A device can appear in the list while its control service is unavailable.

Block the control endpoint after successful discovery. Conversely, interrupt discovery while an authenticated session is already active. Validate the behavior promised for each condition instead of assuming that discovery and session connectivity always fail together.

For Cast troubleshooting, compare your app with a suitable reference sender. Google cautions that YouTube and Netflix may use specialized discovery methods, so they are not reliable generic discovery baselines.

Diagnose the Symptom Before Filing a Network Defect

A successful device selection is not a complete casting test.

Google Cast has a sender app that selects and controls a receiver and a receiver that handles playback. Verify the receiver session and content delivery independently from sender-side UI and device discovery (Google Cast overview).

Test the full journey: select the intended receiver, establish the session, load content, confirm playback, change playback state, disconnect, and reconnect.

Verify What Happens on the Receiver

For play, pause, seek, volume, subtitles, and content changes, compare the mobile UI with the receiver’s reported and observable state. A button changing appearance proves only that the interface changed.

Include unsupported media, expired authorization, unavailable content, and receiver-side load failures. Confirm that the application reports the failed stage rather than remaining indefinitely in “Connecting.”

Interrupt the Sender and Receiver Independently

Background the mobile app, lock the phone, terminate its process, disconnect the phone from Wi-Fi, and restart the receiver.

For each interruption, define whether playback should continue, pause, or stop. On return, require the app to reconcile with the active receiver session rather than blindly replaying its previous local state.

Test a second controller joining or changing an existing session where the product supports it. Verify that stale sender state does not overwrite a more recent action.

Avoid a Single Rule for Every Casting Technology

Receiver-fetched streams, phone-hosted media, and mirroring rely on different content routes. Test each supported mode separately. A reachable local control session does not imply that a media URL is accessible.

AirPlay also needs separate coverage. Apple supports discovery and peer-to-peer modes with device and deployment constraints, so “same infrastructure Wi-Fi is always required” is not a universal AirPlay test oracle (Apple AirPlay deployment).

For an IoT companion app, discovery is only the beginning. Extend testing through onboarding, authorization, command execution, state reporting, and device removal.

Separate Onboarding From Normal Operation

Interrupt setup at each documented phase: invalid pairing code, rejected Wi-Fi credentials, denied network permission, accessory restart, and app termination. A canceled permission or onboarding request must not leave an apparently commissioned device.

After each interruption, verify that retrying does not create duplicate device records, leave misleading “Setup complete” messages, or require an unnecessary factory reset.

Matter uses IP, including IPv6, for operational communication, while Bluetooth Low Energy may be used for commissioning. Passing BLE setup alone does not prove the subsequent IP control path (Matter primer).

For Thread products, include the border router, which connects the Thread mesh with infrastructure IP networks. Restart the border router separately from the phone and accessory to isolate topology-specific failures (OpenThread border router).

Confirm the Device’s Actual State

Use a safe, observable test action, such as setting a lamp to a known brightness.

Verify the requested state, the device’s reported state, and the visible result. Where the app uses optimistic updates, require a clear pending state and an accurate correction after failure.

Also change the accessory through another controller or its physical controls. Confirm that the app reflects the new state rather than repeatedly restoring an outdated value.

Test Authorization Boundaries

In a controlled, authorized lab, try an unpaired app instance, an accessory with a spoofed display name, a removed household member, and an account that has lost access. Check certificate or key or pairing-identity validation where used, expired tokens, saved credentials, and safe credential storage.

Offline access after ownership changes requires a defined product policy. Document the allowable revocation delay if devices cannot reach a cloud authority. Do not assume that sharing a LAN or reusing a cached IP address establishes identity or authorization.

Offline recovery means determining whether the target device applied the action, not simply reconnecting a socket. The most dangerous case is a command that executes before its acknowledgment is lost.

Consider a command that reaches an accessory just before the response is lost. From the app’s perspective, the outcome may be unknown, not necessarily unsuccessful.

Classify each command attempt as confirmed success, confirmed failure, or unresolved. These outcomes require different UI messages and safe-retry policies.

For unresolved operations, reconcile using a fresh device readback, a durable operation identifier, or a protocol-supported status query. If the outcome cannot be established, preserve uncertainty and offer a controlled retry path. Do not silently execute a second action.

Where supported, test a repeatable “set brightness to 40%” action separately from a relative “increase brightness” action. Repeating those requests can have different consequences.

For queued actions, test expiry, canceling, ordering, and ownership. A command canceled by the user must not run after reconnection, and an old queued command must not execute in a different account or household context.

Finally, restore connectivity and verify the entire recovery sequence: rediscovery if required, endpoint refresh, authorization, state reconciliation, and a usable interface. Remove stale error banners only when the relevant condition has actually recovered.

Worked WAN-Outage Walkthrough

• Establish baseline. Query the lamp directly through an authorized device fixture and change brightness. Capture app UI plus confirmed lamp state.
• Inject only a WAN fault. Disconnect the router uplink or block its upstream route, without switching off the AP, LAN switching, or phone Wi-Fi.
• Prove isolation independently. Cloud request must fail. mDNS or other discovery and the known local control endpoint must remain reachable. Record the phone cellular-off state and router rule.
• Exercise the promised offline action. Set a new brightness in the app. Verify a fresh direct lamp state readback and confirm no duplicate execution.
• Relaunch during WAN failure. Confirm that the app uses the product’s authorized local recovery path and labels cloud-only features accurately.
• Restore and clean up. Remove router rules, confirm cloud recovery, resynchronize state, and check that canceled or unresolved commands were not silently replayed. Repeat the scenario separately with cellular data enabled. That second test evaluates network selection and fallback. It should not replace the controlled WAN-outage test.

Use Appium to drive mobile UI and inspect app feedback, but use separate network fixtures and receiver or accessory assertions to prove the real effect. UI-only success is insufficient for local-device QA (Appium drivers).

Keep the three layers distinct: UI driver for actions, router or AP controller for repeatable fault injection, and receiver or accessory fixture for independent state confirmation. Codoid’s QA automation services explain the broader role of scalable mobile test automation.

    prepare(phone, target, permissions, expected_state)
    inject_fault(router, scope="WAN_ONLY")
    assert_probes(cloud="DOWN", lan_control="UP")
    appium.tap("Set brightness")
    assert_target_state(expected_state); reconcile_if_unknown()
    finally: restore_router(); reset_target(); save_evidence()
    

Use observable conditions instead of long fixed delays. Wait for a device to become selectable, a session to reach its expected state, or an accessory to report the requested value, with a defined timeout for each.

Keep permission tests separate from suites that automatically grant permissions. Otherwise, the automation may bypass the very behavior it is supposed to validate.

For repeatability, reset network rules, app state, accessory state, permissions, and queued commands as appropriate. Place cleanup in a guaranteed teardown path so a failed run does not contaminate the next one.

Use mocks for malformed discovery records and controlled edge cases, but keep representative physical receivers and accessories in release-critical suites. Confirm that a remote device lab can actually observe peer discovery, not merely call the backend.

“Device not found” is a symptom, not a sufficient defect report.

For each run, record app build, device OS and target SDK, permission path, router or AP and receiver firmware, protocol, IPv4 and IPv6 setup, cellular state, fault rule, independent probes, and device-side observations. Preserve screenshots and correlated app and accessory logs.

Correlate application logs, receiver or accessory logs, network observations, and screen recordings through a test-run identifier and aligned timestamps.

When packet evidence is needed, first verify that the capture point can observe the relevant traffic. Collect only what is necessary, and redact credentials, pairing material, household information, and device identifiers from shared reports.

A useful defect description is specific.

After upstream internet access is removed, local discovery still returns the lamp, but the app disables its control screen before attempting a local command. The same authorized command succeeds through the test fixture.

That evidence directs investigation toward the app’s connectivity decision rather than an assumed discovery failure.

Replace “local networking works” with measurable acceptance criteria.

Measure discovery latency starting after permission resolution, authorized-session establishment, command confirmation, stale-device cleanup, and reconnection. Count every initiated attempt separately from successful latency samples. Report failures, blocked tests, aborted runs, and timeouts explicitly.

Set thresholds using product requirements and representative-device measurements rather than presenting arbitrary timings as industry standards.

Block release for unauthorized control, wrong-device connections, false success, unsafe replay after canceling, or violation of a documented offline promise. Agree numerical time limits with the product owner based on supported hardware and measured risk.

Also test the recovery experience for accessibility. Permission guidance, device selection, connection status, and retry controls should remain understandable and usable with the supported assistive technologies.

Codoid’s outsourced mobile testing scope and deliverables guide covers engagement expectations for teams building this capability.

Need Help Building Your Mobile Local Network Testing Strategy?

Talk to a Mobile Testing Expert

Frequently Asked Questions