Simplified IoT Device Wi-Fi Configuration via Mobile

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 mo

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Simplified IoT Device Wi-Fi Configuration via Mobile
Medium
~3-5 days

Our competencies:

Frequently Asked Questions

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    897
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    784
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1218
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1081
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    1004
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    600

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?

  1. Requirements analysis and selection of optimal provisioning method (SoftAP, SmartConfig, BLE combo)
  2. SDK integration for specific platforms (Android, iOS, Flutter)
  3. UX implementation: device scanning, network selection/input, error handling
  4. Testing on 10+ router models and OS versions
  5. Documentation and source code handover
  6. 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.