The narrowest thing we do, and the one with the least competition.

Android's telephony APIs are sparsely documented, inconsistently implemented across manufacturers, and full of values that are subtly wrong on particular devices. Few developers have had to care. We have, for six years, across a very large device population.

Where the knowledge comes from

VoLTE Check and 5G Check have been downloaded over 200,000 times, reporting VoLTE and IMS registration state, network generation including NSA versus standalone, device radio capability, carrier readiness, and dual-SIM behaviour.

Running that at scale means dealing with the awkward reality: the same API returning different things on different OEM builds, and states the documentation does not describe.

What we help with

Reading telephony state correctly — which APIs give trustworthy answers and where the OEM traps are. Diagnostic and field-test tooling for support teams and QA. Device certification and validation across carriers. And sometimes just a clear answer on why a handset behaves differently on a particular network, which is often worth more than code.

Honest scope

We are software people, not RF engineers. We work at the layer where Android reports what the modem and network are doing — not at protocol stack, chipset firmware or radio planning level. If your problem is a modem defect or spectrum planning, you need a different specialist and we will say so.

Who it suits

Carriers and MVNOs needing device-side visibility, manufacturers validating behaviour across networks, and enterprises with device fleets and connectivity problems nobody can pin down.

Questions we get asked

The work is usually a specific question rather than a project. A few that recur:

Why does this handset show VoLTE on one network and not another? Almost always carrier configuration and device whitelisting rather than anything in the app — but proving which requires reading the right state in the right order.

Our app reports the wrong network type on some devices. Frequently a documented API returning a value that particular OEM builds populate differently, or not at all.

How do we tell standalone 5G from non-standalone reliably? Harder than it looks, and the naive approach gives wrong answers on several common devices.

Our support team cannot tell whether a customer problem is the phone, the SIM or the network. This one is usually solved with tooling rather than analysis — which is what our own apps do.

How engagements run

A written answer. For a specific question, often the most valuable thing is a clear explanation with the caveats attached, delivered in days rather than a project spanning months.

Diagnostic tooling. An internal app or field-test build that reads and reports device and network state for support teams, QA, or engineers doing site work. This is the closest to what we build for ourselves.

Validation across devices and carriers. Establishing how a device population actually behaves on real networks rather than how the specification says it should.

Review of existing code. Where a team has already built telephony handling, going through it for the traps — APIs used that are unreliable, states not handled, assumptions that hold on the test devices and fail in the field.

What the data looks like

Reading telephony state on Android means combining several sources that do not always agree: the telephony manager, registration callbacks, carrier configuration, and in places system properties that are technically internal but are the only place a particular fact is exposed.

Some values are authoritative, some are best-effort, and some are simply wrong on particular builds. Knowing which is which for a given API on a given manufacturer is not documented anywhere — it is accumulated by running software on a large device population and comparing what it reports against what is actually true.

That is the substance of what we sell here. Not a framework or a library, but knowing where the floor is solid.

Limits, stated plainly

We work at the layer where Android reports what the modem and network are doing. Below that — protocol stack behaviour, chipset firmware, RF performance, spectrum planning — is somebody else's specialism, and we will tell you so rather than take the work and learn on your budget.

We also cannot make a device do something its modem or carrier configuration does not permit. A good deal of telecom diagnostic work ends with an accurate explanation of why something is impossible, which is less satisfying than a fix but considerably cheaper than pursuing one.