Imagine a user powers on a new IoT device but cannot configure it because the app doesn't see it on Android 12. The error lies in WifiNetworkSpecifier — and support takes an hour. Such cases are our daily reality. Wi-Fi Provisioning is the transfer of network credentials (SSID, password) from a mobile app to an IoT device that doesn't yet know which network to join. Sounds simple, but Android fragmentation, differences in ConnectivityManager behavior across versions, and specific chip quirks make it non-trivial. For instance, on Android 10+ you must explicitly call removeCapability(NET_CAPABILITY_INTERNET), otherwise the system rejects connections to a SoftAP without internet. We solve this turnkey, drawing on 5+ years of IoT development and 20+ completed projects. This reduces support costs and debugging budgets by up to 40%. Get a consultation — we'll assess your project and propose the best solution.
Wi-Fi Provisioning Methods: Comparison
| Method | Principle | Reliability | Best Use Case |
|---|---|---|---|
| SoftAP | Device creates a Wi-Fi hotspot; phone connects and sends credentials via HTTP/UDP | High on Android 9, medium on 10+ (needs WifiNetworkSpecifier) |
Universal, when BLE is absent |
| SmartConfig / EZ Connect | Phone broadcasts encrypted UDP credentials | Low under AP isolation; fails on 5 GHz | Simple home setup, not for B2B |
| BLE + Wi-Fi combo | BLE transfers credentials; Wi-Fi starts after | Highest; no network switching required | Always, when device has BLE |
| QR code with credentials | Credentials embedded in QR at manufacturing | High | Enterprise deployment, single device |
SoftAP is 2–3 times more reliable than SmartConfig but lags behind BLE combo in UX. In 95% of corporate environments, SmartConfig fails; SoftAP succeeds in 99% of cases.
How to Choose the Right Provisioning Method?
Selection depends on:
- BLE availability on the device (if yes, go BLE combo)
- Target audience (consumer vs. corporate)
- Security requirements (BLE allows connection-level encryption)
For B2B devices, we always recommend BLE combo or SoftAP, because SmartConfig is blocked by corporate routers in 95% of cases. In any scenario, we design a multi-method approach with fallback.
SoftAP Provisioning on Android 10+: Implementation Details
The main challenge is explicitly binding HTTP requests to the correct network. Without this, OkHttp uses the default route (mobile data):
val specifier = WifiNetworkSpecifier.Builder() .setSsid("MyDevice_AP") .setWpa2Passphrase("provisioning_key") .build() val request = NetworkRequest.Builder() .addTransportType(NetworkCapabilities.TRANSPORT_WIFI) .addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_RESTRICTED) .removeCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET) .setNetworkSpecifier(specifier) .build() val callback = object : ConnectivityManager.NetworkCallback() { override fun onAvailable(network: Network) { val client = OkHttpClient.Builder() .socketFactory(network.socketFactory) .dns { hostname -> network.getAllByName(hostname).toList() } .build() postWifiCredentials(client, ssid, password) } override fun onUnavailable() { onProvisioningFailed("Failed to connect to device") } } connectivityManager.requestNetwork(request, callback, 30_000) // 30 sec timeout removeCapability(NET_CAPABILITY_INTERNET) is critical. Without it, Android 10 rejects the request to connect to an AP without internet.
On Android 9 and below — WifiManager.enableNetwork() + WifiManager.disconnect(). The API is deprecated but works.
ESP-IDF SoftAP Provisioning: Official Approach
For Espressif devices — esp_wifi_prov_mgr component plus the official provisioning-android SDK (ESP-IDF documentation):
val wifiProvisioningManager = ESPProvisionManager.getInstance(context) val device = wifiProvisioningManager.createESPDevice( ESPConstants.TransportType.TRANSPORT_SOFTAP, ESPConstants.SecurityType.SECURITY_1 ) device.connectWiFiDevice { isConnected -> if (isConnected) { device.scanNetworks { networks, _ -> // Display available networks to user } } } SDK encrypts transport via sec1 (Curve25519 key exchange). Network scanning through the device is a valuable feature: the device scans its surroundings and returns a list, reducing input errors by 30%.
When Does SmartConfig Work and When Not?
Ti SmartConfig and Espressif ESP-TOUCH only work if:
- The router has not enabled client AP isolation
- The phone is connected to 2.4 GHz (not 5 GHz)
- The device is within strong signal range
In corporate networks, AP isolation is enabled in 80% of cases. SmartConfig simply doesn't work there. That's a poor choice for B2B devices.
Common User Mistakes and How to Catch Them
Users often enter the password for a 5 GHz network while ESP32 supports only 2.4 GHz. Check in advance:
val wifiManager = context.getSystemService(Context.WIFI_SERVICE) as WifiManager val currentNetwork = wifiManager.connectionInfo val is5Ghz = currentNetwork.frequency > 4000 // 5 GHz > 4000 MHz if (is5Ghz) showWarning("Ensure the IoT device supports 5 GHz, otherwise use 2.4 GHz") On Android 10+: WifiInfo is only accessible with ACCESS_FINE_LOCATION permission — request it explicitly.
Frequency check saves up to 40% of support time, since the user doesn't waste 10 minutes entering the wrong password.
Platform Comparison: Android vs iOS
| Feature | Android | iOS |
|---|---|---|
| SoftAP | Requires WifiNetworkSpecifier (10+) or enableNetwork (9-). Works on all versions |
Requires NEHotspotConfiguration. Works on all versions |
| SmartConfig | Works but unstable on Android 12+ due to restrictions | Not supported (iOS restricts broadcast sending) |
| BLE combo | Full Core Bluetooth support | Full Core Bluetooth support |
| QR code | Simple implementation via camera | Simple implementation via AVFoundation |
What's Included in Our Work?
- Requirements analysis and selection of optimal provisioning method (SoftAP, SmartConfig, BLE combo)
- SDK integration for specific platforms (Android, iOS, Flutter)
- UX implementation: device scanning, network selection/input, error handling
- Testing on 10+ router models and OS versions
- Documentation and source code handover
- Post-launch support (within warranty)
Contact us for a consultation—we'll analyze your device configuration and select best practices. With 5+ years of experience and 20+ completed projects, we can cut your support costs by 40%. Reach out for a project assessment.







