Testing Android Offline Mode and Sync with Claude Code and MCP

Testing offline resilience, airplane mode transitions, local Room database caching, and background network reconciliation on physical mobile hardware represents one of the most critical yet neglected frontiers in mobile software engineering. Modern smartphone users interact with mobile applications across highly volatile environments—subway tunnels, commercial flight ascents, elevators, remote field facilities, and intermittent roaming zones. When network connectivity abruptly drops, an application must degrade gracefully: the user interface must remain fully responsive, local mutations must be committed securely to persistent SQLite or Room stores, and optimistic updates must reflect pending state without displaying cryptic HTTP failure dialogs. Once connectivity restores, background workers orchestrated by Android's WorkManager must reconcile local mutation outboxes with remote servers, ensuring strict data integrity without duplicating financial records or overwriting concurrent modifications. However, mobile engineering teams have historically lacked automated mechanisms to evaluate real physical radio disconnections without breaking the automated testing harness itself. By pairing terminal-based AI coding agents like Claude Code with the Model Context Protocol (MCP) via ScreenSync MCP, developers can automate deterministic network cutoff, evaluate offline UI degradation, assert local database persistence, and verify idempotent server reconciliation directly on physical Android smartphones.

Key Takeaways

• Hardware-level network state manipulation: ScreenSync MCP enables Claude Code to toggle Wi-Fi, cellular radios, and airplane mode deterministically via Android Debug Bridge (ADB) without severing local test communication.
• Physical USB and local LAN resilience: Unlike remote cloud device farms that terminate WebRTC or VNC video streams when device connectivity drops, ScreenSync MCP maintains display streaming over local area networks (LAN) or USB reverse tethering.
• Real-time non-invasive display capture: Display frames stream continuously via Android's native MediaProjection API (Android 7.0+, zero root, zero ADB overhead) at approximately 94 milliseconds median latency.
• Dual visual and semantic node inspection: Claude Code verifies offline UI banners, disabled checkout triggers, and cached lists by combining structural node hierarchies from get_ui_hierarchy with pixel verification from get_latest_screenshot.
• Outbox pattern and mutation queue validation: The agent triggers offline write operations, inspects Room SQLite tables, terminates app processes to verify cold-start cache persistence, and evaluates conflict resolution strategies.
• Unified 226-tool verification ecosystem: ScreenSync MCP bridges 29 mobile and desktop tools (including 12 control_*, 3 os_*, and 14 capture tools) with 197 browser tools to validate end-to-end multi-surface data synchronization.

Why Cloud Device Farms Fail at Mobile Offline Testing

Cloud device farms fail at mobile offline testing because remote device clouds depend on active internet connections to stream interactive video frames and relay commands. Disabling device network interfaces severs the remote WebRTC or VNC streaming pipeline, locking out test runners and causing synthetic automation sessions to terminate prematurely.

Automating offline resilience testing has historically posed an intractable paradox for cloud-based continuous integration environments. Modern device testing platforms—such as BrowserStack, SauceLabs, and AWS Device Farm—host physical smartphones inside remote data centers. Developers interact with these remote devices through high-bandwidth streaming channels (typically WebRTC, WebSockets, or proprietary VNC tunnels). When an automated test script issues a command to disable the network interface—such as adb shell svc wifi disable or adb shell cmd connectivity airplane-mode enable—the remote device immediately drops its connection to the host gateway. The video feed freezes, the control daemon loses telemetry, and the cloud orchestrator flags the test execution as an unexpected session timeout.

To circumvent this limitation, mobile developers have traditionally relied on in-memory network mocking frameworks such as MockWebServer, OkHttp Interceptors, or WireMock. While HTTP mocks are valuable for unit tests, they operate inside the application process and fail to replicate real hardware and operating system behaviors:

1. Operating System Connectivity Callbacks: In-memory mocks do not trigger Android's system ConnectivityManager.NetworkCallback events (onLost, onAvailable, onCapabilitiesChanged). As a result, code paths listening to Android system network state changes remain completely unexercised.
2. WorkManager Constraint Triggering: Android's WorkManager defers background sync jobs based on system-level network constraints (NetworkType.CONNECTED, NetworkType.UNMETERED). When testing with HTTP interceptors, the device's actual network interface remains active, meaning WorkManager never tests queueing, exponential backoff, or batched execution upon real radio reconnection.
3. Hardware Socket State Changes: Synthetic HTTP 500 or timeout mocks do not simulate sudden TCP connection resets, half-open sockets, DNS lookup failures (UnknownHostException), or SSL handshake terminations caused by cellular handoffs.
4. Battery and Radio Power States: Modern Android systems transition cellular modems between high-power (DCH), low-power (FACH), and idle states. Mocking libraries completely bypass modem power management and kernel radio telemetry.

ScreenSync MCP resolves this paradox through an architecture built specifically for physical hardware on a local developer workstation. When testing physical devices connected via USB or local Wi-Fi, the communication channels between Claude Code and the Android device are physically decoupled from the device's public WAN internet access. Claude Code can command the device to turn off cellular data, sever public Wi-Fi access, or enter complete airplane mode while preserving the local ADB daemon channel. By establishing an adb reverse socket over the physical USB connection, display streaming and control commands remain fully operational even when the smartphone has zero external internet access.

Architecture of Offline-First Android Systems: Cache, Outbox, and WorkManager

Offline-first Android architecture pairs a local Room database as the single source of truth with an outbox mutation table and Android WorkManager. When network connectivity drops, repository operations write directly to local SQLite tables, register pending synchronization jobs, and dispatch optimistic UI updates to Jetpack Compose collectors. For an in-depth breakdown of simulating Doze mode and App Standby Buckets during background synchronization, see our architectural walkthrough on testing Android WorkManager with Claude Code and MCP.

Building resilient mobile software demands an offline-first architectural mindset. Rather than treating local storage as an optional cache for remote network responses, an offline-first architecture treats the local database (typically Room backed by SQLite) as the authoritative Single Source of Truth (SSOT). All user interface components observe local database tables through reactive streams (such as Kotlin Coroutines Flow or LiveData), while network responses write exclusively to the database. To ensure persistent local schemas evolve safely across app updates without data loss or crashes, explore our guide on testing Android Room database migrations with Claude Code and MCP.

To handle user write actions—such as creating an order, updating a profile, or sending a message—offline-first systems employ the Transactional Outbox Pattern:

1. Atomic Local Mutation: When a user triggers an action, the repository writes the entity to the local Room database with a temporary sync status (e.g., SyncStatus.PENDING). Concurrently, within the same SQLite database transaction, an entry is inserted into a dedicated SyncQueueEntity table containing the HTTP method, endpoint URL, JSON payload, timestamp, and a unique cryptographic idempotencyKey (UUIDv4).
2. Optimistic UI Presentation: Because the local database updates immediately, the reactive Flow emits the updated entity to Jetpack Compose composables. The user interface reflects the user's input instantaneously, displaying a subtle badge (such as a pending clock icon) indicating that synchronization is pending.
3. Background Sync Scheduling: The repository enqueues a one-time or periodic synchronization request with Android's WorkManager, configuring constraints that require active network connectivity.
4. Idempotent Network Execution: When connectivity is detected, WorkManager instantiates a CoroutineWorker. The worker reads pending items from SyncQueueEntity in chronological order, executing HTTP requests that include the X-Idempotency-Key header.
5. Reconciliation and Deletion: Upon receiving an HTTP 200 or 201 response, the worker marks the entity as SyncStatus.SYNCED and purges the processed entry from the outbox table. If the server returns a temporary error (such as HTTP 503 or a connection timeout), WorkManager returns Result.retry(), applying exponential backoff.

Here is a production-grade Kotlin architecture demonstrating an offline-first repository, Room entities, and WorkManager integration:

package com.example.screensync.offline.data

import androidx.room.*
import androidx.work.*
import android.content.Context
import kotlinx.coroutines.flow.Flow
import java.util.UUID
import java.util.concurrent.TimeUnit

enum class SyncStatus { PENDING, SYNCING, SYNCED, FAILED }

@Entity(tableName = "customer_notes")
data class NoteEntity(
    @PrimaryKey val id: String = UUID.randomUUID().toString(),
    val title: String,
    val content: String,
    val updatedAt: Long = System.currentTimeMillis(),
    val syncStatus: SyncStatus = SyncStatus.PENDING
)

@Entity(tableName = "sync_outbox")
data class OutboxEntity(
    @PrimaryKey val idempotencyKey: String = UUID.randomUUID().toString(),
    val entityId: String,
    val endpoint: String,
    val httpMethod: String,
    val payloadJson: String,
    val createdAt: Long = System.currentTimeMillis(),
    val retryCount: Int = 0
)

@Dao
interface OfflineDao {
    @Query("SELECT * FROM customer_notes ORDER BY updatedAt DESC")
    fun observeAllNotes(): Flow<List<NoteEntity>>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertNote(note: NoteEntity)

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertOutbox(outbox: OutboxEntity)

    @Transaction
    suspend fun saveNoteWithOutbox(note: NoteEntity, outbox: OutboxEntity) {
        insertNote(note)
        insertOutbox(outbox)
    }

    @Query("SELECT * FROM sync_outbox ORDER BY createdAt ASC")
    suspend fun getPendingOutboxEntries(): List<OutboxEntity>

    @Delete
    suspend fun deleteOutboxEntry(outbox: OutboxEntity)

    @Query("UPDATE customer_notes SET syncStatus = :status WHERE id = :id")
    suspend fun updateNoteSyncStatus(id: String, status: SyncStatus)
}

class OfflineRepository(
    private val dao: OfflineDao,
    private val context: Context
) {
    val notes: Flow<List<NoteEntity>> = dao.observeAllNotes()

    suspend fun createNote(title: String, content: String) {
        val noteId = UUID.randomUUID().toString()
        val idempotencyKey = UUID.randomUUID().toString()
        val note = NoteEntity(id = noteId, title = title, content = content, syncStatus = SyncStatus.PENDING)
        val outbox = OutboxEntity(
            idempotencyKey = idempotencyKey,
            entityId = noteId,
            endpoint = "/api/v1/notes",
            httpMethod = "POST",
            payloadJson = "{"title":"$title","content":"$content"}"
        )

        dao.saveNoteWithOutbox(note, outbox)
        scheduleSyncWork()
    }

    private fun scheduleSyncWork() {
        val constraints = Constraints.Builder()
            .setRequiredNetworkType(NetworkType.CONNECTED)
            .build()

        val syncRequest = OneTimeWorkRequestBuilder<SyncOutboxWorker>()
            .setConstraints(constraints)
            .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 15, TimeUnit.SECONDS)
            .addTag("offline_sync_work")
            .build()

        WorkManager.getInstance(context).enqueueUniqueWork(
            "unique_offline_sync",
            ExistingWorkPolicy.APPEND_OR_REPLACE,
            syncRequest
        )
    }
}

When building apps with modern reactive UI toolchains, developers can apply testing Jetpack Compose apps with Claude Code and MCP to verify that composable state holders (collectAsStateWithLifecycle) respond instantaneously to Room database mutations without UI flicker or state loss.

How ScreenSync MCP Bridges Claude Code to Physical Network State Triage

ScreenSync MCP bridges Claude Code to physical Android network triage through decoupled media and control planes. While MediaProjection streams low-latency display buffers over local LAN without consuming ADB bandwidth, device control tools dispatch ADB shell commands to toggle network interfaces, inspect SQLite databases, and query system job schedulers.

To understand why ScreenSync MCP enables flawless automated offline testing, one must inspect how the architecture isolates communication from public network availability. The system operates across three decoupled planes:

The Local MediaProjection Streaming Advantage

The ScreenSync MCP Android client runs on Android 7.0 (API level 24) or higher and initializes an interactive display capture session using Android's native MediaProjection API upon user authorization. Screen frames are encoded and transmitted directly across your local Wi-Fi subnet to the desktop hub running on port 3000. Because this pipeline operates entirely within your local local area network (LAN), turning off public internet access on the router or terminating cellular connections on the phone has zero impact on frame streaming.

Furthermore, if Wi-Fi must be shut off completely on the device to test total radio disconnection, developers configure USB reverse port forwarding:

adb reverse tcp:3000 tcp:3000

Through adb reverse, the Android device routes all HTTP video streaming packets back through the physical USB cable to the workstation's localhost port 3000. Screen capture requires no root access and requires zero ADB screen-scraping overhead, preserving high-speed visual mirror fidelity (~94 ms median latency) even when the smartphone's external radios are 100% silent.

The Complete 226-Tool Verification Surface

ScreenSync MCP exposes 226 total MCP tools to Claude Code:

• 29 Phone & Desktop Tools: Comprising 12 control_* tools (control_tap, control_swipe, control_type, control_key, control_open_url, control_launch_app), 3 os_* tools (os_mouse_click, os_type, os_hotkey), and 14 capture and telemetry tools (get_latest_screenshot, get_ui_hierarchy, get_logcat, record_screen, get_device_status).
• 197 Browser Tools: The web_* suite operates through an authenticated Chrome/Edge browser extension, allowing Claude Code to drive live desktop browser tabs, inspect cloud administrative dashboards, and verify that mobile mutations synchronize across web consoles when network connectivity returns.

Claude Code can manipulate device radio states with precision using Android Debug Bridge shell commands executed through workstation tools or ADB wrappers:

Step-by-Step Setup: Configuring Hardware, Local Hub, and Claude Code

Configuring ScreenSync MCP for offline testing requires launching the desktop hub on Node.js 18, registering the stdio MCP server in Claude Code, and connecting an Android 7.0+ physical device. Establishing an ADB reverse socket ensures display frames stream continuously even when external Wi-Fi and mobile data networks are disabled.

Engineering teams can establish this unattended testing harness on Windows, macOS, or Linux through five sequential steps:

Step 1: Workstation and Hardware Prerequisites

Ensure your test station satisfies the following baseline requirements:

1. Host Workstation: Windows 10/11, macOS, or Linux running Node.js 18 or newer with adb (Android Platform Tools) available in your system PATH.
2. Physical Smartphone: A real smartphone running Android 7.0 (API 24) or later connected to your workstation via a certified USB data cable.
3. Target Application: Debug build of your application installed with Room database and WorkManager compiled.
4. Local Subnet: Workstation and smartphone connected to the same Wi-Fi router for initial pairing.

Step 2: Launch the ScreenSync MCP Desktop Hub

Download the desktop hub archive from screensyncmcp.tech and unpack it to a permanent directory on your workstation. Launch the platform-specific hub starter script:

# On Windows (Command Prompt or PowerShell)
cd C:\tools\screensync-hub
.\start-hub.bat

# On macOS or Linux (Terminal)
cd ~/tools/screensync-hub
chmod +x start-hub.sh
./start-hub.sh

The desktop hub initializes an HTTP server on port 3000 to ingest low-latency MediaProjection video streams and prepares a JSON-RPC Model Context Protocol server over stdio. The terminal output displays your unique authentication token (SCREEN_SYNC_TOKEN) and an ASCII pairing code. For comprehensive initial configuration, refer to the official ScreenSync MCP setup documentation.

Step 3: Register ScreenSync MCP in Claude Code

Register the desktop hub with the Claude Code CLI in your terminal:

claude mcp add screensync node "/path/to/screensync-hub/screensync-hub.js"

If you are using Claude Desktop, open your claude_desktop_config.json configuration file (Settings > Developer > Edit Config) and add the server:

{
  "mcpServers": {
    "screensync": {
      "command": "node",
      "args": ["/path/to/screensync-hub/screensync-hub.js"],
      "env": {
        "SCREEN_SYNC_TOKEN": "your_secure_token_here"
      }
    }
  }
}

(Note: Claude Code, Claude Desktop, Cursor, and VS Code agent mode communicate via local stdio processes and are fully supported. ChatGPT's web application requires remote HTTPS endpoints and does not support local stdio MCP servers).

Step 4: Install the Android App and Authorize Permissions

On your physical Android smartphone:

1. Download and install the free ScreenSync MCP application (com.screensync.mcp) from Google Play.
2. Open the application. Allow mDNS discovery to automatically detect your desktop hub on the local Wi-Fi network, or scan the pairing QR code from the hub console.
3. Tap Start Projection and confirm Android's native MediaProjection screen capture consent prompt.
4. Navigate to Android Settings > About Phone, tap Build Number 7 times to unlock Developer Options, and enable USB Debugging (or Wireless Debugging). If you prefer wireless operation, review our guide on pairing Android wireless debugging to an MCP server without USB.
5. Verify ADB connectivity by running adb devices in your workstation terminal.

Step 5: Configure USB Reverse Port Forwarding for Zero-Wi-Fi Testing

To guarantee that Claude Code continues receiving live screen updates when you instruct it to turn off the smartphone's Wi-Fi radio completely, configure reverse port forwarding over the USB cable:

adb reverse tcp:3000 tcp:3000

With this reverse socket configured, the ScreenSync MCP mobile application delivers MediaProjection frames directly across the USB physical link to the hub, even when the phone has airplane mode enabled and Wi-Fi disabled.

Practical QA Workflows: Disconnection, Mutation Queuing, and Reconnection Sync

Practical offline QA workflows validate three distinct lifecycle phases: instantaneous UI degradation upon network loss, optimistic mutation persistence during process termination, and idempotent background reconciliation upon reconnection. Claude Code coordinates ADB radio toggles with UI hierarchy dumps and logcat telemetry to verify data integrity.

Workflow 1: Validating UI Degradation on Sudden Airplane Mode Drop

When a user loses network connectivity while actively viewing a screen, the application must immediately inform the user without freezing the interface or hiding cached content.

Developer Prompt:
"Claude, launch our app com.example.screensync.offline, navigate to the CustomerNotesScreen, verify that existing cached notes appear, then enable airplane mode via ADB. Assert that a non-intrusive offline snackbar appears and that the 'Sync Now' button disables automatically."

Step 1: Launch Application and Assert Initial State

Claude Code invokes control_launch_app with package com.example.screensync.offline. Once launched, Claude Code calls get_ui_hierarchy to assert that previously cached database entries render on screen:

<node text="Customer Notes" resource-id="com.example.screensync.offline:id/text_screen_title" />
<node text="Acme Corp: Renewal Q4" resource-id="com.example.screensync.offline:id/text_note_title" />
<node text="Sync Now" resource-id="com.example.screensync.offline:id/btn_sync" enabled="true" />

Step 2: Trigger Airplane Mode via ADB

Claude Code issues the system connectivity command:

adb shell cmd connectivity airplane-mode enable

Step 3: Verify Structural and Visual Degradation

Claude Code calls get_ui_hierarchy to inspect the updated accessibility node tree:

<node text="You are currently offline. Changes will sync automatically." resource-id="com.example.screensync.offline:id/snackbar_offline_warning" />
<node text="Sync Now" resource-id="com.example.screensync.offline:id/btn_sync" enabled="false" />

To complete the assertion, Claude Code invokes get_latest_screenshot to confirm that the offline warning snackbar rendered with high contrast and did not obscure the bottom navigation bar.

Workflow 2: Testing Offline Optimistic Mutations and Outbox Persistence

The critical test of an offline-first system is whether user actions taken while disconnected survive unexpected application termination before synchronization occurs.

Developer Prompt:
"Claude, while airplane mode is still enabled, create a new note with title 'Offline Meeting Note' and content 'Follow up on architecture'. Confirm that the note appears in the list with a pending sync indicator. Then, force-stop the app process, relaunch it, and verify that the note is still present in the local database."

Step 1: Input Data While Disconnected

Claude Code calls control_tap on btn_create_note, uses control_type to input text into the title and body fields, and taps btn_save.

Step 2: Assert Optimistic UI Presentation

Claude Code calls get_ui_hierarchy:

<node text="Offline Meeting Note" resource-id="com.example.screensync.offline:id/text_note_title" />
<node text="Status: Pending Sync" resource-id="com.example.screensync.offline:id/badge_sync_status" />

The note is visible immediately because the repository committed the record to the local Room database table.

Step 3: Simulate Unexpected Process Death

Claude Code executes an aggressive process kill to test cold-start persistence:

adb shell am force-stop com.example.screensync.offline

Step 4: Relaunch and Verify Database Integrity

Claude Code calls control_launch_app to restart the application. It immediately calls get_ui_hierarchy to inspect the initial composables. The node Offline Meeting Note with Status: Pending Sync is present in the hierarchy, proving that the transaction was written to persistent disk storage and did not reside solely in volatile RAM.

To verify the underlying database directly, Claude Code executes an SQLite query through ADB run-as:

adb shell run-as com.example.screensync.offline sqlite3 databases/app_database.db "SELECT id, title, syncStatus FROM customer_notes WHERE title = 'Offline Meeting Note';"

Output:

7c81a2f9-3d12-4a90-8e12-b98129481234|Offline Meeting Note|PENDING

Workflow 3: Reconnection, Idempotency, and WorkManager Reconciliation

Once network connectivity is restored, the application must process queued outbox entries in background threads without blocking user interaction or dispatching duplicate requests.

Developer Prompt:
"Claude, disable airplane mode, re-enable Wi-Fi, trigger the pending WorkManager sync job, and monitor logcat. Verify that the server receives the sync request with an X-Idempotency-Key header, returns HTTP 200, and updates the UI badge to 'Synced'."

Step 1: Restore Network Connectivity

Claude Code issues the restoration command sequence:

adb shell cmd connectivity airplane-mode disable
adb shell svc wifi enable

Step 2: Force Immediate WorkManager Execution

Rather than waiting for Android's system JobScheduler periodic poll, Claude Code can trigger the worker immediately:

adb shell cmd jobscheduler run -f com.example.screensync.offline 1001

Step 3: Telemetry Verification via Logcat

Claude Code calls get_logcat with filter: "SyncOutboxWorker", parsing recent runtime logs:

D SyncOutboxWorker: Network constraint satisfied. Processing 1 pending outbox entries.
D SyncOutboxWorker: POST /api/v1/notes [Idempotency-Key: 9b28a1c4-8219-4b21-88f1-a12984920192]
D SyncOutboxWorker: Server returned HTTP 200 OK. Remote note ID: srv_89201.
D SyncOutboxWorker: Updated local note 7c81a2f9 to SYNCED. Purged outbox entry.

Step 4: Final Visual and Structural Assertion

Claude Code queries get_ui_hierarchy on the mobile device:

<node text="Offline Meeting Note" resource-id="com.example.screensync.offline:id/text_note_title" />
<node text="Status: Synced" resource-id="com.example.screensync.offline:id/badge_sync_status" />

The pending sync indicator has cleared, confirming end-to-end reconciliation across physical hardware. When testing notification alerts triggered upon background sync completion, developers can also apply testing Android push notifications with Claude Code and MCP to verify the system notification shade lifecycle.

Common Offline Sync Pitfalls and Logcat Diagnostics

Common offline sync pitfalls include unhandled network exceptions on the Android main thread, infinite WorkManager retry loops caused by missing backoff policies, and stale in-memory state divergence. Claude Code diagnoses these defects by analyzing logcat stack traces and inspecting SQLite outbox tables via ADB.

1. The Main-Thread Network Exception Trap

If repository code inadvertently attempts a synchronous network call or initiates network dispatch from a Dispatchers.Main coroutine scope without wrapping the call in appropriate exception handling, Android throws a fatal exception when the device goes offline:

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: java.net.UnknownHostException: Unable to resolve host "api.screensyncmcp.tech": No address associated with hostname
E AndroidRuntime:     at java.net.Inet6AddressImpl.lookupHostByName(Inet6AddressImpl.java:156)
E AndroidRuntime:     at com.example.screensync.offline.data.NetworkClient.dispatch(NetworkClient.kt:48)

Claude Code detects this crash instantly via get_logcat, pinpoints the unprotected call site in NetworkClient.kt, wraps the network dispatch in a runCatching block, and re-routes the mutation to the local Room outbox.

2. Infinite WorkManager Retry Storms

When an outbox worker fails due to an authentication error (HTTP 401) or a malformed request body (HTTP 400), returning Result.retry() causes WorkManager to loop continuously, rapidly draining the smartphone's battery and flooding device logs. Claude Code inspects get_logcat and flags when workers lack exponential backoff limits or fail to distinguish between transient network drops and permanent HTTP 4xx failures:

// Defective Worker Implementation: Retries indefinitely on permanent 400 errors
if (response.code == 400) {
    return Result.retry() // BUG: Will loop forever
}

// Corrected Worker Implementation: Distinguish transient vs terminal failures
return when {
    response.isSuccessful -> Result.success()
    response.code in 500..599 -> Result.retry() // Transient server error: retry with backoff
    else -> Result.failure() // Client error: mark as failed, alert user
}

3. Outbox Table Bloat and Zombie Records

If a synchronization worker commits HTTP calls to the server but fails to execute dao.deleteOutboxEntry(outbox) due to a local database lock, the processed records remain in the outbox. Upon the next connectivity event, the worker re-dispatches the identical payloads. Claude Code audits outbox table counts using ADB shell commands before and after sync runs:

adb shell run-as com.example.screensync.offline sqlite3 databases/app_database.db "SELECT COUNT(*) FROM sync_outbox;"

If the count fails to reach zero after a reported HTTP 200 success, Claude Code alerts the engineering team to the missing transaction commit.

Implementation Checklist for Offline Mobile Testing

• [ ] Ensure host development workstation runs Node.js 18+ with Android Platform Tools adb configured in system PATH.
• [ ] Unpack the ScreenSync MCP desktop hub and execute start-hub.bat (Windows) or start-hub.sh (macOS/Linux).
• [ ] Register ScreenSync MCP in Claude Code CLI via claude mcp add screensync node "/path/to/screensync-hub.js".
• [ ] Install the ScreenSync MCP client (version 2.5.7+) on physical Android 7.0+ hardware from Google Play.
• [ ] Connect the smartphone and workstation to the same local Wi-Fi subnet; complete mDNS pairing or QR code authentication.
• [ ] Authorize native MediaProjection display recording on the Android phone for low-latency (~94 ms) local screen mirroring.
• [ ] Execute adb reverse tcp:3000 tcp:3000 over USB to guarantee uninterrupted video streaming during complete Wi-Fi shutdowns.
• [ ] Verify that all user write actions commit atomically to a local Room SQLite outbox table before scheduling network sync.
• [ ] Confirm that WorkManager synchronization requests specify NetworkType.CONNECTED constraints and exponential backoff.
• [ ] Include unique cryptographic idempotencyKey UUID headers in all outbox mutation requests to prevent server duplicate writes.
• [ ] Assert that cold-start application termination (am force-stop) preserves pending outbox mutations without data corruption.
• [ ] Validate that restoring connectivity via cmd connectivity airplane-mode disable automatically flushes pending sync queues.

Conclusion

Automating Android offline mode and data synchronization testing with Claude Code and ScreenSync MCP eliminates one of the most perilous blind spots in modern mobile application engineering. By pairing non-invasive, low-latency screen capture via Android's native MediaProjection API with deterministic ADB radio toggles over physical USB connections, engineering teams can validate offline UI degradation, Room database outbox persistence, and WorkManager network reconciliation in seconds rather than hours of brittle manual testing. To expand these automated workflows to spatial and GPS persistence across radio disconnects, see our deep dive on testing Android location and geofencing with Claude Code and MCP. To test how your application handles erratic connectivity, HTTP 5xx spikes, and OkHttp timeout retries before the network drops completely, explore our engineering guide on testing Android network resilience with Claude Code and MCP.

ScreenSync MCP provides the ScreenSync MCP Android app, ScreenSync MCP hub, and ScreenSync MCP browser extension for development teams worldwide. Explore our comprehensive technical documentation at screensyncmcp.tech, contact our engineering group directly at [email protected], and Get it on Google Play to start automating real physical Android hardware today.