CrosswareContact Us →
Home / Case Studies / Android Intercom Master Station
Case Study · Connected Devices

From video phone to native master station.

One Android application adds the intercom protocol, professional audio, automatic door video, server failover and device lockdown required for dependable operator communication.

Critical communicationsAndroid video phoneKotlin · RTP · RTSP

The challenge

Commercial Android video phones provided capable displays and cameras, but they could not behave as native stations in a centrally managed intercom system. Push-to-talk, server-driven messages, key status, audio mixing and controlled failover depended on a proprietary station protocol. The generic Android interface also exposed settings and applications that operators should not access.

Engineering approach

Crossware developed a single Android application that becomes the device launcher and dialler, speaks the station protocol natively, and controls the complete operator experience. Protocol, business logic, hardware integration and UI are separated through a maintainable Kotlin architecture. Network and media work run asynchronously so calls and screen interaction remain responsive.

Control systemPrimary and standby serversStation state, display content, key labels and call control
Control / TCP
RTP audio
Android applicationNative master stationProtocol client · call logic · audio engine · kiosk UI · failover
SDK
RTSP / H.264
Device and videoPhone hardware + door cameraKeys, handset, speaker, display and call-associated video
Delivered capabilities

Everything the operator expects from a native station.

01Native call controlPush-to-talk, open conversation, group calls and server-driven station behaviour.
02Professional audioG.722 and G.711 with one-to-one audio, multicast and two-stream mixing.
03Automatic door videoThe matching RTSP stream opens with the call, even across large camera directories.
04Server-controlled UIMessages, direct-access keys, labels and status lights reflect the central system.
05Safe failoverPrimary and standby connections follow configurable timing without switching mid-call.
06Locked-down deviceKiosk mode, protected settings, hidden system UI and controlled hardware access.
07Simple deploymentOne application supports two target phone models and installer-friendly configuration.
08Target validationUnit tests, automated UI tests and a multi-device system reproduce real-site behaviour.
Engineering depth

Multimedia engineering, proven on the target hardware.

01MultimediaRTP audio engine, G.722/G.711 codecs, multicast and mixing, plus RTSP/H.264 video through Media3.
02Android platformKotlin application development with Clean Architecture, MVVM, Hilt and Room.
03QualityUnit tests, automated instrumented Espresso tests on target devices and a multi-device test system.
Field-hardened connectivity

One state machine owns every connection decision.

Network changes, timers, server heartbeats and call activity report to a single connection owner. The application prefers the primary server, moves to the standby after a configurable timeout and returns only after the primary is stable and the active call has ended.

Preferred pathPrimary serverUsed whenever the connection is stable and no failover condition is active.
Single source of truthConnection state machineCoordinates network events, heartbeats, timers, call activity and status shown to the operator.
1 · Primary first2 · Standby after timeout3 · Safe failback
Continuity pathStandby serverKeeps the station operational when the primary cannot provide a reliable session.

Turning Android hardware into a dedicated product?

We can help with protocols, audio and video, kiosk operation, hardware SDKs and target-level validation.

Learn more →