When architecting a custom Android device, or any new electronic product, the most important pre-development decisions involve negotiating benefit trade offs. What’s the priority: speed to market, cost, power savings, reliability, etc. A product can usually achieve some benefits, but not all. In energy constrained, battery powered, IoT products, it’s most common to base the system around a low power RTOS driven MCU rather than Android hardware.
Simple MCUs are low power, low cost, and can control an integrated system of peripheral electronics. They also limit excess power consumption by turning on or off specific components as needed. Android hardware isn’t this efficient for several reasons, so it usually gets overlooked for use in products that require ultra low power. But depending on the trade offs, Android can offer certain competitive advantages.
In this article we’ll look specifically at the use of custom Android hardware when long battery life is a key product requirement. There are 2 straightforward ways to get a product to work longer between charges. Either use less power or get more of it. Attaching a palm-sized Android PCBA to a basketball size battery isn’t going to work in most IoT products. Because of size constraints, the main opportunity to reduce power consumption rests in creative firmware engineering and hardware selection.
A custom Android solution can prove favorable when the product requires cellular data connectivity and cost is a limiting factor. Unlike WiFi or Bluetooth, cellular modems, like those controlled by an external MCU, often cost more than the complete electronics of an entry level Android system. Without fail, a properly configured MCU + telecom module architecture will consume less power than an Android alternative; it requires less energy to run than an Android CPU and starts up faster. This power saving comes with additional unit cost and development time. Depending on the product’s requirements, the difference in power savings may not justify the higher cost of the MCU + telecom module architecture.
An IoT product is rarely just a MCU and modem though. The product usually gets data from external electronics, like sensors, and sends commands to other electronics, like a speaker. Many external electronic components are already standard parts of an Android system’s reference design. That makes integration faster and possibly lower cost since those components are already tested and priced for high volume mass production. A few examples include cameras, BT, Wi-Fi, GPS, NFC, and certain sensors.
When lower price and faster development justify accepting higher power consumption, the focus turns to minimizing the Android product’s power consumption. In 2018 Google introduced a specialized slimmed down, power saving ‘Android Things’ OS specifically for IoT devices. Google terminated support for Android Things in 2021. Now the best option for running a low power, telecom-enabled Android system is using an Android based smartwatch solution. Existing smartwatch solutions have already been optimized for small form factor and efficient power consumption.
Hatch recently evaluated making a pocket-size product that requires a sensor, button, and 4G data plus voice. The client requested a run time of 96 hours between charges and the product had cost restraints. The client’s requirements are achievable using smartwatch hardware and optimizing the device’s operating habits through system settings customization. Our client’s app has the authority to control system settings, giving them the ability to quickly test and implement different logic. To reduce power consumption the device will make scheduled connections to the backend and put itself into flight mode when not in use. When in flight mode, power can be reduced to the minimum amount needed to keep the system running in sleep mode. The relatively small electronics size allows for the use of a larger battery.
Creating this kind of custom solution gives the product a fair balance between power efficiency, cost, features, and ease of development. All product development has some level of trade offs to consider. When beginning this process, a clear understanding of the product’s application and usage environment combined with a broad view of available technologies will lead to the best results!
