Yes—building an Android app for IoT is very achievable today, but the modern approach no longer uses Android Things and instead relies on standard Android, Bluetooth Low Energy (BLE), MQTT, and Google’s Matter/Google Home ecosystem for smart-home integrations.
Android Things, Google’s IoT OS, is discontinued, Weave was replaced by the Matter standard, and developers now ship Android companion apps that connect to devices over BLE/Wi‑Fi and the cloud, or build Matter-compatible products that work seamlessly with Google Home.
What changed in IoT for Android
- Android Things was announced in 2015 (as Brillo) and launched 1.0 in 2018, but the console stopped accepting new projects on January 5, 2021 and was fully shut down on January 5, 2022.
- Google’s Weave protocol has been superseded by Matter, an open smart home standard supported in Google Home with dedicated SDKs and tools for device and app developers.
- Google Home’s developer tooling and Home APIs now provide the recommended path to integrate smart devices with Google across Android and Nest hubs.
- If a cloud back end is required, note that Google Cloud IoT Core was retired in August 2023; teams either run their own MQTT brokers or use third‑party IoT platforms instead.
The modern Android + IoT paths
- Companion app + device: Build a Kotlin/Android app that talks to microcontrollers or SoCs via BLE/Wi‑Fi and streams data through MQTT or HTTP to a cloud broker or service.
- Matter smart home products: Build devices with the Matter SDK and integrate through the Google Home Developer Center to reach Google Assistant, Android, and Nest hubs.
- Embedded Android (AOSP derivatives): Where Android runs on the device, treat it like a standard Android app platform and rely on BLE, network APIs, and secure update workflows.
This guide explains how to make an Android app for IoT using today’s supported stacks, with step‑by‑step instructions, code patterns, security, and deployment best practices.
Android Things recap and why to move on
Android Things began as Brillo, was rebranded and released as Android Things 1.0 in 2018, and later narrowed focus to smart speakers and displays before being turned down.
The console stopped new registrations in January 2021 and was fully shut down with all project data deletion by January 2022.
Given its end‑of‑life, new projects should not target Android Things and should instead use standard Android with BLE/MQTT or build Matter devices for Google Home.
From Weave to Matter with Google Home
Google transitioned from Weave to Matter by contributing Weave to the Connected Home over IP effort that became Matter, halting Weave’s development in favor of the new standard.
Matter is an open standard enabling devices to interoperate across major ecosystems; Google offers SDKs, testing, and “Works With Google Home” certification paths.
Google Home provides end‑to‑end tools for Matter device and app developers, accelerating time‑to‑market and ensuring compatibility across Android and Nest hubs.
Architecture options for Android + IoT
- Device + mobile app + broker: A Bluetooth/BLE device sends data to an Android app, which processes and publishes it via MQTT to a cloud or edge broker for dashboards and automation.
- Device + Matter + Google Home: A product built on the Matter SDK integrates via the Google Home Developer Center and appears in Assistant and Google Home apps.
- Android device as edge gateway: An Android tablet/phone aggregates BLE sensors, applies local logic, and bridges to MQTT, handling background tasks with WorkManager.
Core technologies to use
- Bluetooth Low Energy: Android provides BLE APIs to scan, connect via GATT, and exchange data efficiently with low power devices.
- MQTT messaging: Eclipse Paho Android client enables reliable MQTT publish/subscribe, including TLS and WebSocket support for mobile connectivity.
- Background work: WorkManager reliably schedules deferrable, guaranteed tasks across app restarts and device reboots.
- Foreground services: Android 12+ restricts background starts of foreground services; use WorkManager or exemptions where applicable.
- Permissions on Android 12+: Nearby devices and Bluetooth permissions require explicit runtime grants for discovery, advertise, and connect.
Step‑by‑step: Build an Android IoT companion app (BLE + MQTT)
1. Set up the environment
- Install Android Studio, create a Kotlin app with minSdk per BLE needs, and enable required Bluetooth features.
- Plan the data flow: GATT characteristics from the device mapped to JSON payloads for MQTT topics on connect or at intervals managed by background work.
2. Define permissions and features (Android 12+)
- Request and declare Bluetooth permissions for scanning, advertising, and connecting, along with Nearby Devices where applicable.
- Explain foreground service rules for long‑running user‑visible tasks; avoid starting foreground services from the background unless exempted.
3. Implement BLE scanning and GATT
- Use the platform’s BLE central role to scan and filter by device name, service UUID, or manufacturer data.
- Connect to the device’s GATT server, discover services/characteristics, and read/notify as required.
4. Add MQTT connectivity
- Integrate Eclipse Paho Android client to publish sensor telemetry and subscribe to control topics, using TLS where supported.
- Configure automatic reconnect and offline buffering for flaky networks to maintain reliable delivery.
5. Schedule background sync with WorkManager
- Use WorkManager for reliable, deferred uploads, retries, and constraints such as network availability and charging.
- For user‑visible, time‑sensitive operations, combine WorkManager expedited work or a properly launched foreground service when policy allows.
6. Handle Android 12+ foreground service changes
- Targeted apps can’t start a foreground service from the background unless a special case applies; handle exceptions and fallbacks gracefully.
- Prefer WorkManager for non‑urgent background operations and prompt the user to enter the app for tasks that require foreground execution.
7. Secure data and privacy
- BLE pairing can expose data to all apps on the phone; add app‑layer encryption or tokenization where data sensitivity demands it.
- Use TLS for MQTT and manage credentials securely, rotating keys and limiting topic access per device.
Example: BLE read + MQTT publish (Kotlin)
-
This snippet reads a GATT characteristic when available and publishes to MQTT with a retained topic for last‑known value.
CHECK OUT THE CODE HERE KOTLIN
- Pair this with WorkManager tasks to periodically reconnect and backfill logs if connectivity drops, respecting network constraints and retries.
Matter path: Build smart devices for Google Home
- Matter lets one device work across ecosystems with a single protocol, while Google provides SDKs, validation, and Works With Google Home branding.
- Devices integrated and tested through Google Home Developer Center gain faster time‑to‑market and a consistent user experience on Android and Nest hubs.
- For mobile apps, Google’s Home APIs expose access to hundreds of millions of devices and automation capabilities, opening new smart‑home use cases.
Cloud and messaging choices (post IoT Core)
- Google Cloud IoT Core was retired in 2023, so select alternatives like self‑managed MQTT brokers or third‑party IoT platforms for device ingestion.
- The Paho Android client works with standards‑compliant MQTT brokers and supports features like auto‑reconnect and persistence for robust mobile links.
- Design topic hierarchies per device and function, enforce least‑privilege credentials, and secure brokers with TLS and client certificates.
Background work and Android 12+ compliance
- Use WorkManager for guaranteed, deferrable, and constraint‑aware tasks across restarts and app closures, avoiding brittle background behaviors.
- Android 12 adds restrictions to foreground services launched from the background; rely on documented exemptions or redesign for WorkManager where possible.
- Foreground services remain appropriate for user‑noticeable, ongoing tasks, but always confirm policies for API level 31+ and handle exceptions.
Security and privacy essentials
- Add app‑layer protection for sensitive BLE data, since paired data can be accessible to all apps on the device without extra safeguards.
- Use TLS for MQTT, rotate credentials, and segment topics so a compromised client cannot publish/subscribe beyond its scope.
- Align permissions with Android 12+ requirements by requesting only the Bluetooth and Nearby Devices capabilities actually needed.
Practical checklist (planning to production)
- Define use cases: telemetry, control, automation, and alerts across BLE and MQTT or via Matter integration for smart‑home scenarios.
- Select device connectivity: GATT characteristics for BLE devices or Matter endpoints for certified smart‑home products.
- Choose cloud/messaging: Standard MQTT brokers and event pipelines since IoT Core is retired, with TLS and observability from the outset.
- Implement Android background tasks: use WorkManager, and apply foreground services only when policy allows for user‑visible work.
- Validate permissions: ensure Nearby Devices and Bluetooth runtime prompts are clear, and handle denial gracefully.
- Test across devices: verify BLE stability, reconnection behavior, and MQTT resilience under network changes and app lifecycle events.
Frequently asked questions
Q1. Can Android Things still be used for new products?
No—Android Things is discontinued; the console stopped new projects in 2021 and fully shut down in 2022, so new projects should target standard Android, MQTT/BLE, or Matter.
Q2. What replaced Weave for Google smart‑home development?
Matter is the new standard, and Google supports it via the Google Home Developer Center with SDKs and the Works With Google Home program.
Q3. How should an app connect to IoT devices over short range?
Use the Android BLE APIs for scanning, GATT connections, characteristic reads/writes, and notifications to exchange data efficiently with battery‑powered devices.
Q4. What’s the recommended Android library for background tasks?
WorkManager provides reliable scheduling, constraints, retries, and persistence across reboots, making it ideal for deferred IoT syncs and maintenance jobs.
Q5. Is it okay to start a foreground service from the background on Android 12+?
Generally no—Android 12 blocks background starts unless exempted, so plan to use WorkManager or trigger from a user‑visible state when needed.
Q6. Which MQTT client is commonly used on Android?
The Eclipse Paho Android client is a widely used open‑source MQTT library supporting TLS, offline buffering, and asynchronous operations.
Q7. What happened to Google Cloud IoT Core?
It was retired in 2023, so teams now choose third‑party IoT platforms or run their own brokers for device ingestion and messaging.
Conclusion
The fastest, future‑proof route to Android IoT today is a standards‑based stack: BLE for device connectivity, MQTT for messaging, WorkManager for background reliability, and Matter/Google Home for smart‑home reach.
With Android Things retired and Weave replaced by Matter, this approach aligns with Google’s current ecosystem and ensures compatibility, scalability, and secure operation across modern Android versions.