NetKit: WiFi analysis as a pure-Kotlin library

Most of the interesting logic in a WiFi app is trapped. The part that models RF propagation, picks a better channel, or judges whether your security is any good is usually welded directly to Android's WifiManager, tangled up with the platform, and impossible to test without a phone in your hand. The brains and the body are fused, so the brains can't go anywhere.

NetKit is what happens when you pull them apart. It's the WiFi analysis engine I built for the WiFi Intelligence Android app, extracted into pure Kotlin with zero Android dependencies and open-sourced as seven modules on Maven Central. The RF math is the RF math whether it runs on a phone, a server, or a laptop, so now it can run on all three.

The idea: Separate the intelligence from the platform

This is the whole point, so it's worth saying plainly. Capturing a WiFi scan is platform-specific work. Android has its APIs, a desktop has others, and that part genuinely belongs to the platform. But everything you do after the scan, the modeling and the diagnosis and the optimization, is just computation over data. It has no business depending on Android, and when it does, three good things become impossible.

You can't test it properly, because the logic only runs inside an emulator or a device. You can't reuse it, because it's chained to one platform. And you can't reason about it cleanly, because the analysis and the plumbing are knotted together. Pull the analysis out into plain Kotlin and all three problems dissolve at once. NetKit runs on any JVM, it's covered to around ninety percent by ordinary unit tests, and you can read a module and understand exactly what it does without an Android manual open beside you.

You bring the scan results. NetKit does everything after that.

What's in it

NetKit is seven focused modules, and you take only the ones you need. core is the one everything builds on, and the rest are optional:

• core: The foundation. WiFi data models (access points, scan results, channels), RF propagation and signal modeling, an Information Element parser, and network topology mapping. Zero external dependencies.
• diagnostics: Why is this connection bad? Connection-quality analysis, performance metrics, and issue detection that categorizes what it finds.
• wifi-optimizer: How do I make it better? Channel-selection algorithms, interference analysis, band-steering and power recommendations.
• security: Is this network safe? WPA, WPA2, and WPA3 analysis, posture assessment, and encryption recommendations.
• analytics: What's the trend? Historical processing, statistics, and performance benchmarking over time.
• intelligence: What should I do? ML-based optimization suggestions, anomaly detection, and context-aware recommendations.
• export: Now show someone. Report generation and data export in multiple formats.

The split matters because a project rarely needs all seven. A diagnostics tool can pull core and diagnostics and nothing else. An app that only audits security takes core and security. You're not dragging a monolith in to use a corner of it.

A taste of the API

The shape of it is exactly what you'd hope: Build a model from your scan data, then ask the engines questions about it.

val accessPoint = AccessPoint(
    bssid = "00:11:22:33:44:55",
    ssid = "MyNetwork",
    frequency = 2437,
    rssi = -65,
    securityTypes = listOf(SecurityType.WPA3_PERSONAL),
)

val analysis = ChannelAnalyzer().analyzeChannel(accessPoint.channel)
val issues = DiagnosticEngine().analyzeSignalQuality(accessPoint)
val best = ChannelOptimizer().findOptimalChannel(listOf(accessPoint))

No Android types in sight. That code runs in a plain JVM test, which is the entire argument in five lines.

What NetKit is good for

The app it came from. WiFi Intelligence is the proof. The whole reason NetKit exists is that an Android app needed this analysis, and building it as a clean library made the app better, not just the library. The platform layer captures scans and draws the UI, and NetKit does the thinking in between.

Server-side and fleet analysis. Once the logic is pure Kotlin, it doesn't need a phone at all. Feed it scan data collected from a fleet of access points and run the same optimizer and security analysis on a server, in batch, over a whole building.

Command-line and automation. The same modules drop into a CLI for one-off audits or into a CI job that checks a deployment's channel plan and security posture without a human watching.

A tested core for your own app. If you're building something WiFi-related on any JVM platform, you can take core plus whatever modules you need and skip reinventing RF modeling and IE parsing, which are exactly the parts that are tedious to get right and easy to get subtly wrong.

Where the line is

NetKit is deliberately not a scanner. It does not capture WiFi data, because capturing it is the platform-specific job that genuinely belongs to Android, to a desktop OS, or to whatever hardware you're on. You hand NetKit the scan results, and it gives you back models, diagnoses, optimizations, and reports. That boundary is the feature. It's the line that keeps the analysis pure, portable, and testable, and it's why the same code works everywhere.

Try it

NetKit is on Maven Central under io.lamco.netkit, Apache-2.0 licensed, with Dokka API docs. Add core and the modules you want, hand it your scan data, and see what it tells you. If you've been doing WiFi analysis the hard way, welded to a platform and untestable, I think you'll like having the brains as a thing you can hold on their own.