App detail · VoxShield Mobile

How a call
is checked

VoxShield Mobile works with call audio on the phone and asks two questions: does this voice match what is known about this contact, and does it show signs of being AI-generated. Both models run inside the app.

Product detail The Console pipeline

Product-level overview. The stages below describe what the app does, not how it is implemented internally. Model details and test results belong to the Mobile repository's own documents, which stay the source of truth for them.

The flow

From audio to an on-screen warning

Every stage runs on the device. The dashed path is the enterprise hand-off, which is specified and not built.

Runs on the phone Gate — rejects chunks not worth scoring Specified, not built
Product-level flow. Detection runs in the Android app; this website never performs or proxies any detection.

Stage by stage

What happens, in order

  1. Call audio

    Audio is taken in short chunks at 16 kHz mono. There is no permanent recording step and nothing to upload afterwards.

  2. Silence rejection

    An energy-based check discards chunks that contain no speech, so silence never reaches a model and never becomes a confident answer.

  3. Speaker check

    ECAPA-TDNN produces an embedding for the chunk and compares it against the enrolled voiceprint for that contact, and against the phone owner's own voice.

  4. Caller gate

    Speaker similarity decides whether the chunk is worth scoring at all. Rejected chunks stop here and the next chunk is analysed instead — the same refusal principle the Console uses.

  5. Synthetic-voice check

    RawNet2, exported to ONNX and run through ONNX Runtime Mobile, scores whether the speech looks synthesised rather than spoken live.

  6. Risk score and alert

    Scores are smoothed across chunks with an evidence floor, so a single noisy chunk cannot swing the result. A high score raises an on-screen warning while the call is still open.

  7. Console hand-off Specified

    Sending a recording to the Console for enterprise review is designed — metadata and a content hash only, never audio bytes — and is not built.

Input paths

Four ways audio reaches the models

All four share the same ONNX models and the same decision logic. They differ in where the audio comes from.

Recording analysis

Supported

A call recording on the device is scanned after the call. This is one of the two primary supported paths today.

Test-file mode

Supported

A WAV file is fed straight to the models — the path used for demonstrations and for reproducing a result.

Live-call capture

Device dependent

The architecture runs end to end, but capturing far-end audio during a call is governed by Android's audio policy. On the one device tested (Samsung SM-A166P, Android 16, 2026-09-07) the OS silences the app's microphone for the whole call.

Microphone capture

Partly verified

Capture outside a call works, but the trigger stages were last verified in an earlier session and were not re-exercised in the most recent diagnostic run.

Why this is stated so plainly. A second, non-Samsung device has not been tested yet, so “works during live calls” is not a claim this project is willing to make. The measurements behind that sentence are in the Mobile repository's feasibility document.

Design constraint

What stays on your device

Everything inside the APK

Built

Both models ship in the app and run through ONNX Runtime Mobile. No server, no Python process, no network round trip — installing the APK is the whole setup, and airplane mode proves it.

This website

You're here

Informational only. No demo widget, no upload field, no backend and no tracking. Nothing on this site receives or processes audio.

Android

Try it on the app

A stable public release is not published yet, so the APK is handed out at the demo.

Download APK (240 MB, models included) See the products