How to Get a Bluetooth Device Name Over Wi-Fi in Kotlin Using NSD & mDNS

HOW DID WE ENCOUNTER THE CROSS-PROTOCOL BLUETOOTH NAME DISCOVERY CHALLENGE?

While working on an enterprise smart office platform, our engineering team encountered a deceptively complex networking requirement. The architecture involved a central Android-based hub functioning as a local Wi-Fi hotspot. Employee mobile devices would connect to this hotspot upon entering the facility to trigger automated check-ins and synchronize localized data. To make the kiosk UI user-friendly, the client wanted the system to display the connecting device’s Bluetooth name (e.g., “Alex’s Smartphone”) rather than an obscure IP or MAC address.

During the initial integration, we realized that resolving a device’s Bluetooth name purely from its Wi-Fi network connection was fundamentally restricted by modern operating systems. There is no native Kotlin package or API endpoint that accepts an IP address and returns a Bluetooth name. The TCP/IP stack and the Bluetooth stack operate in complete isolation. This issue matters heavily in production environments, as attempting to forcibly map network layers without the right architecture leads to severe battery drain, security exceptions, and unreliable device tracking.

We encountered a situation where standard networking libraries failed to deliver the required business value. This challenge inspired the following article to help engineering teams navigate protocol isolation, avoid common pitfalls with hardware identifiers, and implement secure, cross-protocol discovery mechanisms using Kotlin.

WHY IS RETRIEVING A BLUETOOTH NAME OVER A WIFI NETWORK SO COMPLEX?

The business use case required seamless device identification to personalize the enterprise hub experience. In the intended architecture, the mobile application acted as a background client, while the hotspot hub acted as the server. The issue surfaced immediately at the network layer.

When a device connects to a Wi-Fi network or a mobile hotspot, it is assigned an IP address. The standard network packet only contains IP headers and the Wi-Fi MAC address. The Bluetooth adapter on the exact same device has its own distinct MAC address, its own broadcasting protocol (BLE/Classic), and its own friendly name. The operating system explicitly sandboxes these two hardware interfaces. Furthermore, modern Android and iOS devices implement strict privacy controls, randomizing MAC addresses and blocking access to hardware identifiers without explicit user permissions.

WHAT NETWORK SYMPTOMS AND ARCHITECTURAL LIMITATIONS DID WE OBSERVE?

When we first attempted to resolve the device identities using native network scanning techniques, the symptoms of protocol isolation became evident. Our initial diagnostic logs painted a frustrating picture.

• Generic Hostnames: Reverse DNS lookups on the connected IP addresses returned generic vendor strings like “android-1a2b3c4d” or simply returned null, rather than the user-configured Bluetooth name.
• ARP Table Blocking: In older OS versions, developers could read the ARP cache to map an IP to a Wi-Fi MAC address. Modern OS updates block application access to the ARP table, rendering our logs full of Permission Denied exceptions.
• Decoupled Hardware IDs: Even when we successfully retrieved a Wi-Fi MAC address via socket connections, there was no deterministic way to guess the Bluetooth MAC address, as vendors no longer assign them sequentially.

It became clear that relying on lower-layer networking tricks was an architectural oversight. We needed an application-layer solution that respected user privacy while satisfying the business requirement.

WHAT WERE THE ALTERNATIVE SOLUTIONS FOR DEVICE NAME RESOLUTION?

Understanding that a direct Kotlin package for “IP-to-Bluetooth-Name” did not exist, we evaluated several workarounds. Diagnosing the problem required us to weigh battery consumption, user experience, and network reliability.

CAN WE RELY ON ARP TABLE MAPPING FOR BLUETOOTH MAC DISCOVERY?

We considered using legacy ARP scanning to find the Wi-Fi MAC, and then querying a known vendor database to estimate the Bluetooth MAC. We immediately discarded this approach. Not only is the ARP cache restricted in modern environments, but MAC randomization means the hardware address changes constantly. Building a robust enterprise application on deprecated security loopholes is an anti-pattern.

DOES CORRELATING BLUETOOTH LE RSSI WITH IP ADDRESSES WORK?

Another approach involved dual-scanning. The hub would scan for all local IP addresses while simultaneously scanning for Bluetooth Low Energy (BLE) advertisements. We attempted to correlate the moment a device connected to the hotspot IP with a spike in BLE signal strength (RSSI). While mathematically interesting, this proved highly unreliable in a busy office environment with dozens of devices connecting simultaneously.

IS NETWORK SERVICE DISCOVERY THE BEST ARCHITECTURAL CHOICE?

We concluded that the most stable, privacy-compliant way to resolve the Bluetooth name over a network was to have the client application deliberately broadcast it over the TCP/IP layer. By utilizing Network Service Discovery (NSD) or mDNS (Multicast DNS), the client app could read the device’s Bluetooth name locally (with the correct permissions) and advertise it as a service on the hotspot network. The hub would simply listen for these localized broadcasts.

HOW DID WE IMPLEMENT THE FINAL KOTLIN NSD SOLUTION FOR DEVICE DISCOVERY?

Our final implementation abandoned hardware-level spoofing in favor of an application-layer service broadcast using Android’s native NsdManager. We built a solution where the client app securely reads its user-friendly name and publishes an mDNS service containing that name when connected to the enterprise hotspot.

For engineering teams looking to hire kotlin developers for networking apps, understanding how to implement custom NSD services is crucial for modern IoT architectures. Below is a generic, sanitized version of the Kotlin implementation used on the hub to discover these devices.

class DeviceDiscoveryManager(context: Context) {
    private val nsdManager = context.getSystemService(Context.NSD_SERVICE) as NsdManager
    private val serviceType = "_enterprise_iot._tcp."
    private val discoveryListener = object : NsdManager.DiscoveryListener {
        override fun onDiscoveryStarted(regType: String) {
            // Logging discovery initialization
        }
        override fun onServiceFound(service: NsdServiceInfo) {
            if (service.serviceType == serviceType) {
                nsdManager.resolveService(service, resolveListener)
            }
        }
        override fun onServiceLost(service: NsdServiceInfo) {
            // Handle device disconnection logic
        }
        override fun onDiscoveryStopped(serviceType: String) {
            // Cleanup resources
        }
        override fun onStartDiscoveryFailed(serviceType: String, errorCode: Int) {
            nsdManager.stopServiceDiscovery(this)
        }
        override fun onStopDiscoveryFailed(serviceType: String, errorCode: Int) {
            nsdManager.stopServiceDiscovery(this)
        }
    }
    private val resolveListener = object : NsdManager.ResolveListener {
        override fun onResolveFailed(serviceInfo: NsdServiceInfo, errorCode: Int) {
            // Handle resolution failure gracefully
        }
        override fun onServiceResolved(serviceInfo: NsdServiceInfo) {
            val deviceIp = serviceInfo.host.hostAddress
            val friendlyName = serviceInfo.serviceName
            
            // The friendlyName broadcasted by the client app reflects its Bluetooth name
            registerDeviceInSystem(deviceIp, friendlyName)
        }
    }
    fun startDiscovery() {
        nsdManager.discoverServices(serviceType, NsdManager.PROTOCOL_DNS_SD, discoveryListener)
    }
    private fun registerDeviceInSystem(ip: String?, name: String?) {
        // Business logic to update the kiosk UI
    }
}

Validation and Performance Considerations: We validated this by running concurrent device connections. Because mDNS operates over UDP multicast, it adds negligible overhead to the hotspot. Security-wise, the client app only broadcasts the name when connected to the specific enterprise SSID, preventing privacy leaks in public networks.

WHAT STRATEGIC LESSONS CAN TEAMS LEARN ABOUT BLUETOOTH AND WIFI NETWORKING?

Solving this issue highlighted several engineering realities regarding modern mobile ecosystems. Companies looking to hire software developer talent for IoT must ensure their teams understand these fundamental principles:

• Respect Protocol Boundaries: Do not attempt to bridge Wi-Fi and Bluetooth at the hardware layer. They are decoupled by design. Use application-layer protocols (like HTTP, WebSockets, or NSD) to share data between them.
• Anticipate Privacy Restrictions: Never architect a system assuming access to static MAC addresses or ARP tables. Always build around the assumption that hardware IDs will be randomized or hidden.
• Use mDNS for Local Discovery: Network Service Discovery is incredibly powerful for smart home and enterprise IoT. It allows devices to negotiate identity without relying on centralized cloud servers.
• Stateful Network Monitoring: Handle network lifecycle events carefully. NSD discovery listeners can silently fail or duplicate events; ensure your connection states are idempotent.
• Decouple Identity from Hardware: Instead of relying on a Bluetooth MAC or an IP address to uniquely identify a user, rely on a secure, app-generated UUID mapped to the broadcasted friendly name.

HOW CAN YOU APPLY THESE NETWORK DISCOVERY PATTERNS TO YOUR SYSTEM?

Attempting to force legacy networking techniques onto modern mobile operating systems will inevitably lead to brittle architectures and production failures. By shifting the device discovery mechanism to the application layer using Network Service Discovery, we delivered a highly reliable, privacy-compliant feature that satisfied the enterprise use case. Whether you are building smart office platforms or industrial IoT workflows, aligning with OS-level privacy patterns is the only path to scalable networking.

If your organization is tackling complex protocol integrations and needs to hire iot developers for smart systems, our pre-vetted remote engineering teams have the architecture experience to deliver robust solutions. contact us to learn how we can support your next enterprise initiative.

Social Hashtags

#Kotlin #AndroidDevelopment #AndroidDev #NetworkServiceDiscovery #mDNS #IoTDevelopment #Bluetooth #WiFiNetworking #EnterpriseIoT #AndroidNetworking #MobileDevelopment #SoftwareArchitecture #AndroidEngineers #KotlinProgramming #DeviceDiscovery