About this policy
This Privacy Policy describes the ELMA IoT Android application, labeled ELMA IoT – ESP32 Toolkit, developed by Elnur Mehdiyev under ELMA IoT. Its Android application ID is com.elmaiot.app. It also explains privacy when visiting this website or contacting support.
Contact the developer at elik745i@gmail.com for privacy questions or requests.
Release availability. Version 1.0.47 is free, with ad requests and new checkout disabled. Google Play purchase checks, included Google SDK components, privacy options and online radio-directory requests remain present. The advertising and purchase sections below describe a future update only when those features are enabled; they do not mean that this release displays advertisements or sells purchases.
Data stored on your phone
The app uses private Android app storage and WebView browser storage for saved configurations and interface preferences. Depending on what you use or enter, these can include:
- Device names, board and peripheral settings, Wi-Fi network names and passwords, MQTT broker details and credentials, and device web-access settings.
- The last device address you opened, locally compiled firmware artifacts, compiler caches and build logs. Legacy PC-pairing credentials are removed by the updated app.
- Designer layout, selected tabs and profiles, radio selections, recent playback entries, and file-browser preferences or caches when those interfaces are used.
- A verified Google Play purchase record and signature, when available, to restore an ad-free entitlement.
Wi-Fi scan results, active USB connections, firmware bundles and operation logs are also processed during the relevant session. The app does not automatically upload your saved configuration to a developer cloud account.
Private app storage is access-restricted by Android. The app does not add its own encryption to saved preferences. Its manifest disables Android backup, and its extraction rules exclude app data from cloud backup and device transfer.
Permissions & device access
Wi-Fi and location
On request, the app uses Android’s precise and approximate Location permissions to scan nearby Wi-Fi networks. Android also requires Location services to be enabled. The app reads network names (SSIDs), signal strength, frequency and security capabilities to show compatible networks; it can also display the connected Wi-Fi name and local IP address. It does not request GPS coordinates or background location tracking. The app targets Android API 36 and supports API 26 onward. It requests ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION together at runtime, requires the fine grant for scanning, and declares ACCESS_WIFI_STATE and CHANGE_WIFI_STATE. It checks whether Location services are enabled on API 28 and later. On Android 13 and later, it declares and requests NEARBY_WIFI_DEVICES when you ask it to connect to an ELMA access point. This permission is marked neverForLocation; the app does not use it to derive physical location. Although Android 13 introduced that permission for certain Wi-Fi operations, the startScan() and getScanResults() APIs used here still require fine location permission; it is not a replacement for this scan permission. See Android’s Wi-Fi permission documentation. Raw scan lists are not uploaded by the app. A network name you choose can become part of the configuration you later export or send to your ESP device.
USB and ongoing operations
Android asks you to grant access to a selected USB device. The app reads USB device, vendor, product and port information, and communicates with the ESP bootloader to identify the chip, check flash capacity, write firmware and apply configuration. Foreground-service permissions support ongoing data-transfer and connected-device operations.
Files and media
Import and export use Android’s system document picker. The app accesses files you select, such as configuration documents and firmware bundles; a connected device’s web interface can also offer file uploads or media controls. The app does not request broad storage, photo-library or camera permissions. It declares the optional microphone permission described below. Exported configurations and firmware bundles may contain credentials.
Other permissions
Internet and network-state permissions support the connections in this policy. Included SDKs add billing, advertising-ID, Ad Services and wake-lock permissions, as well as an internal receiver-protection permission. The app has no phone-side Bluetooth pairing feature. Bluetooth and microphone choices in the hardware Designer describe ESP peripherals. Nearby Wi-Fi access and optional phone microphone access are separate features described in this policy.
Optional phone microphone
When you use a connected device page for two-way audio, ELMA can request Android’s RECORD_AUDIO permission. The app first asks you to approve the displayed secure device origin, and Android asks for microphone permission if it has not already been granted. Microphone capture is denied in the Designer and for origins that do not match the selected secure device. Audio is provided to the approved device page for its communication feature; that page determines the destination and handling of the audio. ELMA does not send microphone audio to the developer or advertising services. You can deny access or revoke the Android permission at any time.
Where information is sent
Local firmware compilation
When you choose Compile, the app compiles firmware on your Android device using bundled source and compiler tools, plus SDK data downloaded from the project’s GitHub releases when required. No paired PC or cloud compiler receives your configuration. Build logs, compiler caches and completed artifacts are stored in private app storage. Save Firmware exports an application binary through Android’s document picker. Executable compiler tools are delivered with the app through Google Play. Required SDK data is downloaded from GitHub releases and cached locally, with integrity checks. GitHub and its delivery providers receive ordinary connection information, including your IP address and the requested asset. Your firmware configuration is not sent in these download requests.
When you choose Scan Local Network, the app probes local IP addresses for compatible ELMA status and OTA endpoints and displays responding devices. Manual IP entry is also available. Discovery results are not sent to an ELMA server.
Your ESP device
USB provisioning sends configuration and firmware to the selected ESP. Device mode opens the HTTP or HTTPS address you supply, initially suggesting 192.168.4.1. OTA sends a firmware image to the address you enter and can send device-login credentials using HTTP Basic authentication. It checks device status and upload progress. Local-network device discovery runs when you request it; Wi-Fi network scanning and USB enumeration are separate features. MQTT discovery publishing belongs to the connected ESP interface.
Your MQTT broker
The Android MQTT connection test sends authentication details you enter to your selected broker, with a randomly generated client ID for that connection. It checks connectivity; the phone-side test does not publish device discovery or runtime commands. The broker receives the network connection and handles it under its own practices.
Radio Browser
The packaged Designer requests the country list from all.api.radio-browser.info when it starts, if the network is available. A selected or previously saved country is sent when loading its station list. These requests expose your IP address and normal HTTP request information to the directory service. A selected country is a browsing preference, not a GPS reading. See Radio Browser.
Connected-device pages and external content
Device mode displays the web interface served by the address you choose. That page can make its own network requests. The shared interface includes an optional artwork lookup that sends track title, artist, album or filename search terms to Apple’s iTunes Search API and retrieves an artwork image. This is a media-preview feature; the packaged Android Designer hides device-storage views and does not run artwork searches at startup. When using a device page that offers it, the receiving service sees the search and connection information. See Apple’s privacy information.
External links, including GitHub project and support links, open the destination’s services. Their providers receive ordinary connection information. The app does not control the content or data practices of arbitrary device pages, brokers or external websites you choose.
ELMA IoT servers: the current app contains no developer-operated cloud account, configuration-upload, analytics or crash-reporting endpoint. Compilation and compiler caching are performed on the Android device. This does not mean that no information leaves your phone: Google services, Radio Browser and your chosen destinations receive the information described here.
Google services, ads & purchases
The Android project includes Google Mobile Ads (AdMob) 25.4.0, Google User Messaging Platform (UMP) 4.0.0 and Google Play Billing 9.1.0. Availability depends on the release configuration; the dated source-review note above distinguishes the checked build from the planned production release.
Advertising when enabled
In an advertising-enabled release, the app can request AdMob banner ads when no verified Remove Ads entitlement is active and Google’s consent controls permit requests. Ads are hidden while a firmware operation is busy or purchase ownership is unknown.
Google and its advertising services may process advertising and app-set identifiers, IP address (including approximate location inferred from it), device/application information, app and ad interactions, and diagnostic information. UMP handles consent choices and related consent status. These processes support ad delivery and measurement, service diagnostics, and fraud prevention. Advertising may be contextual/non-personalized or personalized, depending on consent, applicable requirements and Google configuration. Non-personalized advertising does not mean that no data is processed.
Where required and configured, UMP presents privacy messages before ad requests. You can revisit Files → Remove ads / purchases → Advertising privacy choices. The available form and ad behavior depend on Google’s configuration and consent status; rejecting a choice does not guarantee that every form of Google processing stops. The app does not pass saved Wi-Fi passwords or MQTT credentials to the advertising integration.
See Google’s Mobile Ads data disclosure, Google’s consent documentation and Google’s Privacy Policy. These explain Google processing; this policy does not characterize ELMA IoT as selling your personal data.
One-time Remove Ads purchase
When checkout is enabled and the product is available in Google Play, the app offers a one-time, non-consumable Remove Ads purchase using product ID elma_remove_ads. Google Play displays the price and processes the purchase and payment information. ELMA IoT does not receive your full card number or full payment-account details.
The app checks purchase status and entitlement through Google Play to determine whether ads should be removed. It queries purchases on startup/resume and when you select Restore purchases. It verifies the product, package and signed purchase record locally, acknowledges a valid purchase using its token, and may store the verified receipt and signature in private app storage. A pending or unverified transaction does not grant the entitlement. Restoration requires a valid purchase available through the relevant Google Play account and successful verification.
Purchase checks can occur even in a release where new checkout is unavailable. Removing ads stops the app’s banner requests for a verified owner; it does not remove Google Play purchase processing or unrelated network features such as the radio directory. Google controls its transaction records and retention. The app does not create an ELMA account or implement ELMA sign-in.
Checked build and provider components
In version 1.0.47 reviewed on 5 November 2026, the live-monetization flag was false: the normal ad-initialization, banner-request, consent-update and new-checkout paths were disabled, while Billing connection/restoration and the UMP privacy-options menu remained present. Public Google test ad IDs, delayed measurement initialization, SDK components and advertising permissions were still packaged. This source check is not a measurement of all SDK background traffic.
No separate Firebase Analytics, Firebase Crashlytics, Sentry or similar developer analytics/crash-reporting integration was found. Google services can perform their own diagnostics as described in their documentation.
Other included libraries
The local compiler includes an Android-native QEMU runtime, Espressif GCC toolchains, Arduino ESP32 SDK and guest runtime libraries. The app uses them for local compilation and does not configure a telemetry endpoint for them.
Eclipse Paho MQTT 1.2.5 makes the broker connection described above. Its app logger discards log messages. USB Serial for Android 3.10.0 and the packaged esptool-js code communicate with your selected USB device. fflate and @noble/hashes handle firmware archive and checksum processing locally. These library integrations do not add a developer telemetry endpoint.
The shared browser flasher source also references UNPKG and jsDelivr for browser-only dependencies. The native Android Build screen uses packaged libraries, and the packaged pages restrict scripts to their own origin. Those CDN references are not an automatic download by the native Android flashing flow.
Connection security
Compilation runs locally; obtaining required SDK data uses the GitHub connection described above. MQTT uses TLS on port 8883 or when the TLS option is supplied; ordinary MQTT uses unencrypted TCP. Device mode and OTA support both HTTP and HTTPS. On HTTP connections, device credentials, configuration and other transferred information may be readable on the network. USB communication is a direct connection to the selected hardware.
Not all app communications are encrypted in transit. Use trusted devices and networks, and choose HTTPS or TLS where the destination supports it. Keep device credentials, configuration exports and firmware bundles private.
Retention, deletion & your choices
Saved app data persists until you replace it, clear the app’s storage in Android Settings, or uninstall the app. Some session state and logs last only for the current session; a verified purchase may be restored again from Google Play.
- Revoke Location or Nearby Wi-Fi permission in Android Settings if you do not want the corresponding Wi-Fi features. Revoke Microphone permission to prevent phone audio capture. The app explains the permission before requesting it.
- Clear app storage to remove saved configurations, compiler caches, build files, receipts and WebView data held by the app.
- Delete exported files separately from the document provider or folder you selected. Clearing the app does not delete copies on an ESP, a broker or an external storage service.
- Manage Google account, purchase and provider records through Google. Clearing local app data does not cancel a purchase or erase Google’s records. Advertising ID controls are available in Android Settings.
- Contact the provider of a broker, device page or other external service about information that it holds. Their retention periods are not controlled by the Android app.
For information you have sent to the developer by email, contact elik745i@gmail.com to request access, correction or deletion. Support correspondence is used to respond to your request and retained as needed to resolve it or meet applicable obligations. There is no ELMA cloud account to delete.
This website & contacting support
This static website has no ELMA analytics scripts, advertisements, sign-in, tracking pixels or contact form. Its fonts and visual assets are served with the site. It is hosted on GitHub Pages: GitHub logs visitors’ IP addresses for security, as described in its Pages documentation and Privacy Statement.
When you email support, the developer receives your email address and whatever message or attachments you choose to send. Your email provider and the recipient’s email provider process that correspondence. GitHub issues are public; do not post credentials, private configurations, pairing tokens or purchase receipts there.
Policy updates
This policy reflects the Android version and practices described above. The conditional advertising and purchase sections cover the planned features when enabled. Before a production release, the actual configuration must be checked against these descriptions and Google Play disclosures; any different data handling requires a policy update. The effective date at the top will identify policy updates.
For questions, visit Support or email elik745i@gmail.com.