push.tt / Solutions
Partly shipping

Keep the radio. Lose the range limit.

Run push.tt on rugged Android PoC hardware from Inrico, Hytera, Telo and others. Keep the side paddle, loud speaker and glove-friendly form factor, then talk wherever Wi-Fi or cellular data reaches.

Partly shipping. The paddle, the target logic and encrypted transmission are verified on a device. The Bluetooth path, the boot receiver and the small-screen layout are written and NOT yet confirmed on healthy hardware — they are listed as such below rather than folded in.
Rugged PoC radioStudio hardware render
The current push.tt talk screen shown at its original 720 by 1605 proportions on a rugged Android handset
Real app screen · original proportions
Physical controlsSide PTT and SOS buttons stay under the thumb
Fleet readySideload, MDM and no Google Play Services required
Private channelsEnd-to-end encryption on member devices
01

Change the software. Keep the hardware.

A PoC radio is an Android device with the parts a phone leaves out, and the way they are usually deployed happens to match how push.tt is built.

  • No Google Play Services required anywhere in the app — a lot of this hardware ships without them, and a lot of it is deliberately kept off Google's network
  • A foreground microphone service, so a transmission survives the screen going off in a pocket
  • Sideload and MDM friendly. These fleets are provisioned by an administrator, not from a store — see device management
  • End-to-end encryption, which the incumbent in this market does not offer at all. On hardware bought specifically because the work is sensitive, that is the whole argument
The current push.tt talk screen running at its original proportions on a rugged Android PoC handset
push.tt on rugged AndroidActual product screen
02

One paddle. Three possible signals.

This is the part that quietly defeats software written for phones. There is no common way for a rugged handset to tell an app that the big orange button was pressed — vendors do it three different ways, and the codes are not reliably discoverable.

  • A key event — works only while the app is in the foreground, which is not how a radio is used
  • A broadcast — works with the screen off, and is what most of this hardware actually sends
  • A media button — which never reaches an app that only overrides key handling, because the platform routes it to whatever holds the active media session. An app that misses this looks dead to every wired speaker mic
  • All three are handled, and the built-in table leads with the pair that PoC firmware ships for the incumbent's sake — the closest thing this market has to a convention
  • Plus a learn mode. Press your radio's paddle in Settings and it binds whatever that radio actually sends. PTT and the SOS key are learned separately, because they are separate buttons with separate consequences

Verified on a device: a broadcast paddle driving a 4.3-second encrypted transmission, the app choosing the right conversation with nothing on screen (open conversation, then default channel, then the only channel, then most recent), and a held paddle not firing repeatedly.

Rugged PoC radioStudio hardware render
01 Key event 02 Broadcast 03 Media button
03

Know the data cost before you buy

One real limitation, stated plainly because it affects your data bill rather than ours.

  • Older handsets can hear the small format but not send it. Anything from Android 10 sends it too — and PoC radios typically ship Android 8 to 11, so check before you buy a fleet
  • So an older handset sends about nine times the data when it talks — on exactly the pay-per-megabyte connection you were trying to protect. It still hears everyone else at the smaller size
  • Fixing it properly means bundling the codec ourselves rather than using the platform's. That is real work and it is not done
  • Ask us what your specific model reports before committing to a fleet. It is one number and it decides your monthly data
Transmit data

The Android version changes the bill.

Android 10+Opus
Older AndroidPCM16~9×

Older handsets still receive Opus. Their transmit path is the part that uses more data.

04

Prove the model before deployment

Listed rather than implied, because "supported" and "we wrote the code" are different claims and only one of them is honest here.

  • Bluetooth and wired speaker-mic buttons — the media-session path is implemented and has not been confirmed on a real accessory
  • Restart after a power blip — a radio in a vehicle cradle should come back by itself; the receiver exists and is unverified
  • Small screens. The talk button was sized from screen width alone, which on a 240×320 display made it taller than the space available. It now sizes from the shorter axis, and that has not been seen on the actual screen

These are unverified because the test device degraded rather than because they were skipped. If you have hardware in hand, that is the fastest way to close this list — and we would rather do it with you than claim it in a datasheet.

Verified on device Physical paddle Target selection Encrypted transmission
Confirm on your model Speaker-mic buttons Restart after power loss Small-screen layout
Model-by-model compatibility

Tell us the model

The make, the Android version and how the paddle behaves in the incumbent app is enough for us to say whether it works today, what your data cost looks like, and what would need doing. Bringing legacy radios along too? See connecting existing radio systems.