I know it sounds overly dramatic, but when you are passionate about technology, it becomes like a human relationship. When things don’t go the way you would like, it can get emotional. I’ve been a Geek since way before it was fashionable and I can’t see myself changing any time soon. So, apologies in advance, even if none were necessary.
Android 1.0 first appeared in 2008. It was basic and didn’t even have a code name. The Apps were baked into the Operating System rather than the more modern stand-alone updatable Apps we have now. All a little clunky, but the potential was clear. Then came 2.0/2.1 in late 2009, when Android entered the mainstream with its implementation on the Motorola Droid and the associated marketing campaign. It grew and grew from then on, with new devices being supported, and notable Android tablets and laptops entering the world.
Through all this growth, it must be remembered that Android was originally developed to work as a smart mobile phone, not really an application platform like Windows or Linux. This has implications. Many things can interrupt an App—notifications, other Apps, phone calls, messages, etc. A mobile device runs, primarily, from battery power which means that power management is very important, requiring background processes to be tightly managed. Memory for processes can be on the low side, creating more issues for background Apps that may be terminated as Android wants the foreground App to keep going. Then there is the whole permissions management infrastructure, limiting what an App can do based on permissions granted by the user. In more recent versions of Android, permissions are even more restrictive in that some cannot even be granted by the user and are the preserve of “System” Apps. Oh, and the hell on earth that is the process of getting a complex App approved for the Google Play Store.
However, it must also be remembered that Android has many features that make it very attractive for Apps that need to communicate with the outside world, using reasonably simple and robust mechanisms. WiFi, mobile data, Bluetooth, SMS, VoIP, Internet APIs, etc. This is where the “heart rip” is. So many features, but so many restrictions. This has caused some Android device manufacturers to stick to old Android versions with most of the features and fewer restrictions, to allow them to run their custom IoT Apps without the hassle. But this is a bad thing as new features will be missed, and more importantly, security updates will be missed.
So, if you want an interactive Android App that will be an IoT Hub and run on the latest Android version, what do you have to worry about?
Many things will be out of the control of your App, such as keeping the App on top of everything else so your User Interface is always visible, taking control of the Power Button to stop accidentally putting the screen to sleep, granting permissions without user involvement, the App getting killed by Android for some often-unknown reason, and many more. The answer here is to use a Mobile Device Manager (MDM) authorized by Google to take over management functions on Android that deal with all that Device Management, so you don’t have to.
A special note about listening for broadcasts from Bluetooth Low Energy (BLE) devices. For some reason, Android considers it a bad thing to keep listening for these—CPU usage perhaps. BLE devices think it’s a good idea to periodically broadcast data from sensors (and it is a good idea). Android just stops listening for them and does not pass them to the App. So, you must keep restarting the listener.
Android is also very restrictive about getting access to anything that uniquely identifies the device the App is running on. Such as the International Mobile Equipment Identifier (IMEI), the GSM Phone Number, the device’s Android Hardware ID, the Network MAC Address, etc. So you must create your own unique identifier, to use in messages back to your cloud servers to identify where they came from, which of course you lose on a factory reset.
Android is so good at providing the features you need, but then takes it back with all the restrictions. My hope is that Google will realize the potential for Android as an IoT Hub and provide a version that is better suited to this task, as they have done for Automotive environments.
In the meantime, I will continue to use Android and hope for the best in the future.
“The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.”