Android Hotspot Device Discovery in Kotlin: A Modern No-Root Approach

What Inspired This Deep Dive Into Android Hotspot Device Resolution?

During a recent project for a logistics and field service management provider, we were tasked with modernizing a mobile diagnostic application. Field technicians used ruggedized Android tablets, functioning as mobile hotspots, to provision and configure headless IoT tracking devices in remote areas without internet connectivity. The core functionality required the Android tablet to detect the IP addresses and hostnames of all IoT devices connected to its local hotspot, allowing the technician to select a specific device and initiate the provisioning sequence via a local TCP socket.

While working on the migration of this legacy Java codebase to Kotlin and targeting newer Android OS versions, we realized the core network discovery module had completely failed. Technicians reported that the connected device list was returning empty, effectively halting field deployments. The legacy code relied on reading system files that Google had restricted in recent OS updates. This challenge required us to fundamentally rethink how network discovery operates within the sandboxed environment of modern Android systems. We encountered a situation where maintaining offline operational capability meant finding a reliable, high-performance workaround without requiring rooted devices. This architectural pivot inspired this article, providing a blueprint for teams facing similar networking constraints in modern mobile environments.

Why Did Device Discovery Fail In Our Mobile Architecture?

To understand the business impact, one must understand the operational environment. In remote logistics yards, field technicians do not have access to corporate Wi-Fi. The standard operating procedure dictates that the technician turns on the Android device’s portable Wi-Fi hotspot, powers on the IoT sensors, and waits for them to connect automatically using pre-shared credentials. The mobile application then acts as a localized dashboard, polling connected clients.

In older versions of Android (specifically API 28 and below), any application could easily extract the IP addresses and MAC addresses of connected clients by reading the underlying Linux ARP (Address Resolution Protocol) table. Once the IP was identified, a simple reverse DNS lookup would yield the device’s hostname. However, as the client upgraded their fleet to modern Android 12 and 13 tablets, this architectural assumption became a critical point of failure. The application was running on unrooted hardware to comply with mobile device management (MDM) security policies, meaning we had no elevated privileges to bypass the newly imposed OS-level privacy sandboxing.

How Did The Privacy Restrictions Impact Our Network Logs?

When the modernized application was deployed to the staging environment, the network discovery service began throwing silent failures. Our crash reporting tools did not register an app crash, but the diagnostic logs revealed the bottleneck. The legacy implementation utilized a standard file reader aimed at /proc/net/arp.

The logs showed a recurring java.io.FileNotFoundException: /proc/net/arp (Permission denied). Starting with Android 10 (API 29), Google severely restricted access to hardware identifiers and network state files to prevent unauthorized user tracking. The ARP table, which maps IP addresses to hardware MAC addresses, was locked behind root-level permissions. Furthermore, executing terminal commands like ip neigh show via Runtime.getRuntime().exec() returned empty strings or permission errors. Without access to the ARP cache, the application had no way of knowing which IP addresses had been assigned by the hotspot’s internal DHCP server, completely breaking the hostname resolution pipeline.

What Were The Alternatives For Unrooted Android Device Resolution?

Faced with a hard OS-level limitation, our architecture team had to evaluate alternative network discovery methods that complied with Android’s sandboxed permissions. We considered several solutions to restore the provisioning workflow.

Could We Rely On ARP Table Parsing?

As established, parsing /proc/net/arp is highly efficient and synchronous, but it is effectively dead on modern Android. While it remained in our codebase as a fallback for legacy tablets running older OS versions, it could not serve as the primary discovery mechanism for the new fleet.

Was Reading DHCP Leases A Viable Option?

Another approach we investigated was reading the /data/misc/dhcp/dnsmasq.leases file. When an Android device acts as a hotspot, it runs a lightweight DHCP server (often dnsmasq) to assign IP addresses. The lease file contains the exact mapping of IPs, MACs, and hostnames. However, accessing the /data/misc/ directory requires root access. Since enterprise MDM policies strictly forbid rooting devices, this approach was immediately discarded.

How Did Subnet Sweeping With mDNS Compare?

The only viable solution for an unrooted device was to actively scan the local subnet. When an Android hotspot is enabled, it typically assigns itself a predictable gateway IP (e.g., 192.168.43.1 or 192.168.49.1). By identifying the gateway, we could initiate an asynchronous ping sweep across the /24 subnet (scanning 1 to 254). Once an active IP address responded, we could query it for its hostname. To make this robust, we paired the ICMP/TCP ping sweep with Android’s NsdManager (Network Service Discovery), allowing the IoT devices to broadcast their hostnames over mDNS (Multicast DNS). This combination proved highly reliable without violating any OS security constraints.

How Do You Implement Hostname Resolution In Kotlin?

To implement the subnet sweep and hostname resolution, we leveraged Kotlin Coroutines to handle the massive concurrent network I/O required to ping 254 addresses simultaneously without blocking the main thread.

Below is a sanitized, generic implementation of the network discovery engine we integrated into the platform.

import kotlinx.coroutines.*
import java.net.InetAddress
import java.util.concurrent.ConcurrentLinkedQueue
class HotspotNetworkScanner {
    data class ConnectedClient(val ipAddress: String, val hostName: String)
    suspend fun scanHotspotSubnet(gatewayIp: String): List<ConnectedClient> = coroutineScope {
        val activeClients = ConcurrentLinkedQueue<ConnectedClient>()
        val subnetPrefix = gatewayIp.substringBeforeLast(".")
        val jobs = mutableListOf<Job>()
        // Iterate through the typical /24 subnet space
        for (i in 1..254) {
            val targetIp = "$subnetPrefix.$i"
            if (targetIp == gatewayIp) continue // Skip the host device itself
            jobs += launch(Dispatchers.IO) {
                try {
                    val address = InetAddress.getByName(targetIp)
                    // isReachable uses ICMP Echo or TCP Echo on port 7
                    if (address.isReachable(800)) {
                        // Attempt reverse DNS lookup
                        val hostName = address.canonicalHostName
                        val finalName = if (hostName == targetIp) "Unknown Device" else hostName
                        
                        activeClients.add(ConnectedClient(targetIp, finalName))
                    }
                } catch (e: Exception) {
                    // Ignore unreachable hosts or timeout exceptions
                }
            }
        }
        
        // Wait for all ping operations to complete
        jobs.joinAll()
        return@coroutineScope activeClients.toList()
    }
}

Validation and Performance Considerations:

• Timeouts: isReachable(800) is capped at 800 milliseconds. Subnet sweeps can be inherently slow. By wrapping them in Dispatchers.IO, we execute the checks concurrently. The entire scan takes roughly 1-2 seconds rather than minutes.
• mDNS Integration: Because canonicalHostName often falls back to returning the IP address if a proper DNS server isn’t running on the hotspot, we instructed the IoT firmware team to implement Bonjour/mDNS. We then used Android’s built-in NsdManager.DiscoveryListener to capture the precise service names of the devices once their IPs were verified by the sweep.
• Permissions: This approach requires standard network permissions (ACCESS_NETWORK_STATE, ACCESS_WIFI_STATE, and INTERNET), which do not require dangerous permission prompts or root access.

What Are The Key Takeaways For Mobile Engineering Teams?

When organizations scale their mobile infrastructure, legacy assumptions often break under new security paradigms. Here are the actionable insights from resolving this architectural constraint:

• Assume OS Files are Off-Limits: Never rely on underlying Linux system files like /proc/ or system directories for critical application state. OS vendors are continuously tightening hardware abstraction layers.
• Leverage Concurrent I/O: Network sweeps are traditionally slow. By utilizing Kotlin Coroutines, you can turn a synchronous bottleneck into a highly concurrent operation that completes in a fraction of the time. This is a critical skill when you hire kotlin developers for custom solutions.
• Implement Graceful Degradation: We kept the ARP table lookup for legacy API versions but seamlessly fell back to the subnet sweep for modern devices. Your architecture should adapt based on runtime API checks.
• Control Both Ends If Possible: Because we had influence over the IoT device firmware, we mandated mDNS support. Network discovery is significantly easier when the client devices actively broadcast their presence.
• Embrace Standard APIs: Using NsdManager or standard InetAddress functions guarantees compliance with MDM policies and Android’s evolving permission models.

How Does This Impact Future Mobile Architecture?

Modern mobile development is no longer just about rendering UI screens; it involves orchestrating complex, secure, and asynchronous interactions with external hardware and evolving OS constraints. The transition from simple file reading to concurrent subnet sweeping demonstrates the necessity for robust architectural thinking in enterprise applications. When enterprises need to hire software developer talent, they must look for engineers who possess a deep understanding of networking protocols, OS-level security sandboxing, and asynchronous performance tuning.

Whether you need to hire android developers for enterprise mobility or modernize an aging mobile workforce platform, having a team that can navigate these low-level technical challenges is vital to maintaining operational continuity. If your organization is facing similar mobility or network discovery bottlenecks, contact us to discuss how our dedicated engineering teams can help stabilize and scale your architecture.

Social Hashtags

#AndroidDevelopment #Kotlin #AndroidDev #KotlinDevelopment #MobileDevelopment #AndroidNetworking #NetworkDiscovery #mDNS #KotlinCoroutines #NsdManager #IoT #IoTDevelopment #SoftwareEngineering #EnterpriseMobility #MobileAppDevelopment