An API connection is only the entry point. A useful pipeline also has to identify the device, route the work through the right channel, and return evidence that stays connected to the run.
A mobile AI data pipeline cannot interact with a physical Android device by intention alone. It needs a way to find an eligible device, submit or configure work, communicate with software running on the device, and bring observations back into the system that will store or evaluate them.
Those steps often use more than one interface. A backend API may expose device inventory and accept a command. A persistent connection or message broker may deliver that command to the device. A separate part of the pipeline may collect screenshots, state changes, timestamps, or other evidence. Treating all of this as one generic “device API” makes the integration harder to reason about.
Consider a benchmark runner with a set of mobile tasks and several Android devices. Before assigning work, it needs to know which devices are available. After choosing one, it needs to route the requested action to that device, observe what happened, and attach the resulting evidence to the correct task attempt. Each interface has a different part to play.
Start with an addressable device
The first connection is often an inventory query. A pipeline needs stable identifiers and enough current device information to decide whether a device is a candidate for a task. A display name alone is not sufficient: names can change, and several devices may share the same model or configuration.
A device-list request can return a collection of device records. The response may include a UUID, board or software context, connectivity status, and a last-seen time. The pipeline can use those values to select a device and retain the identity with the run record. Sensitive addresses and credentials do not belong in downstream task metadata or client-side code.
For example, a simplified inventory exchange looks like this:
GET /api/devices HTTP/1.1
Host: backend.example
Accept: application/json{
"devices": [
{
"uuid": "[redacted]",
"board": "[redacted]",
"status": "online",
"last_seen_at": "[timestamp]"
}
]
}The request and response are separate parts of the exchange: HTTP describes the request method, target, and response semantics; JSON carries the returned representation. The pipeline should preserve the device UUID as the stable link between selection, execution, and evidence, while recording the task and attempt identifiers at its own level.
Use each connection for the work it carries
An HTTP API is a natural integration point for querying inventory, updating configuration, or submitting a control request. HTTP uses request-response semantics, which makes each interaction explicit and straightforward to audit. A response can confirm that a request was received or routed, but that alone does not establish what the device displayed or whether a task succeeded. HTTP Semantics (RFC 9110)
Physical devices also need channels that stay available between requests. WebSocket provides a bidirectional connection that can carry device registration, heartbeats, control messages, or an interactive session. MQTT uses a publish-subscribe model that can distribute messages between a backend and device-side components. The choice depends on the interaction: a discrete management request, a persistent control session, and a message delivered to a subscriber are different operations. The WebSocket Protocol (RFC 6455) · MQTT Version 5.0 specification
In a documented real-device integration, Backend HTTP APIs provide device inventory, configuration, and command entry points; device WebSocket and MQTT connections carry their respective control and messaging traffic. A discovery path can also help with initial device registration or configuration delivery when the normal cloud connection is not yet available. That discovery mechanism is a bootstrap or compensation path, not a replacement for the pipeline’s normal task and evidence flow.
The key design question is therefore not “Which protocol is best?” It is “Which component owns this operation, and what does its response guarantee?” Keeping those answers explicit prevents an HTTP acceptance response, a delivered message, and a verified task outcome from collapsing into the same status.
Keep the pipeline identity across every hop
The device UUID identifies the physical resource. The task ID identifies the requested work. The attempt ID identifies one execution of that work. Those identifiers should remain linked, but they should not be interchangeable.
This matters when a task is retried, routed to another device, or split across several devices. A pipeline should be able to answer which device handled each attempt, what request was sent, which observations were collected, and which outcome was assessed. If an execution message has a command ID, that ID can help trace delivery; it does not automatically replace the higher-level task or attempt identity.
The same relationship should appear in stored evidence. A screenshot without a device and attempt association can be difficult to interpret later. A status event without a timestamp or task context may be impossible to connect to the requested outcome. At ingestion time, attach the relevant identifiers and timestamps before transforming events into a dataset record.
Return evidence to the system that evaluates it
The device-control layer and the data-capture layer serve related but distinct roles. The control path gets work to a physical device. The collection path captures what happened: the observations before and after an action, relevant app or device state, timestamps, and the evidence used to assess the result.
A robust integration sends those records back to a system that can store, inspect, and link them to the originating task. It should preserve partial results when a device disconnects or an attempt ends without a conclusive outcome. This makes it possible to distinguish “the command was accepted,” “the device received it,” “the action ran,” and “the requested result was verified.”
The exact evidence depends on the question. A UI task may need a screenshot and a visible state check. A task about persistence may require reopening the app and observing the state again. A data pipeline should capture what is needed to support its evaluation, rather than treating every successful transport response as task evidence.
Put trust boundaries around the connection
Integration design also determines where credentials and device access live. Keep service credentials on the backend, use access controls for viewing, configuration, and command submission, and route public access through the intended gateway. A device-local RPC endpoint may be useful inside a controlled network while remaining unavailable to public clients.
The pipeline should expose the minimum interface needed by each component. A task scheduler may need a device identifier and availability status; it does not need MQTT passwords or a local RPC address. A data consumer may need observations and outcomes; it does not need permission to issue device commands. Separating these responsibilities reduces accidental exposure and makes each integration easier to operate.
Connect physical execution to usable data
An API makes a physical device addressable from software. A pipeline becomes useful when it preserves identity and intent across selection, control, observation, and assessment. HTTP, WebSocket, MQTT, and discovery can each contribute to that path, provided their responsibilities and guarantees remain clear.
This extends the programmable run model described in What Makes a Real-Device Data Collection System Programmable? and the state boundaries discussed in Device State Management: The Overlooked Problem in Mobile AI Data Collection. The result is not merely a command sent to a phone, but a traceable connection between a data request, a physical execution, and the evidence used to understand it.