Smartwatches are becoming the newest platform for application development. Even Apple is putting more and more focus on the Apple Watch on their annual Keynotes instead of on the iPhones. Other companies also tried to get in the business of smart wearables, so to this day, we have two major operating systems running on these devices, watchOS by Apple, and wearOS by Android. In 2019 we at Kitchen Budapest also started to implement ideas to these devices, since they were presenting good opportunities for industry 4.0.
Canary was our first project, which can be summed up as an ‘alert watch’ designed for hearing impaired people. For development, we chose Huawei Watch 2, because it supported eSIM, wearOS, and regarding price and value it was the best option on the market at the time. It also had a pretty decent battery. The device’s only purpose was to run this application.
Working in an industrial environment can be dangerous. In case of emergency (e.g. fire) the alarm goes off with some sort of audible instructions to signal the workers. In order to make these workplaces safe for hearing impaired people, the alert now sends an SMS to the watch, which starts to vibrate on the worker’s wrist, giving them a tactile alert substituting the audible one. At this point, the user has to push a button on the UI, which sends feedback to the admin platform, signaling that they saw the alert. The admin platform is a simple website we’ve created in order to monitor the alert’s feedback status, whether the worker is wearing the device or not, the battery state and the heart rate.
To achieve continuous communication between the app and the admin platform Google provides multiple solutions, including Firebase. which is integrated into wearOS and it provides a real-time messaging solution with its own server. Firebase is a battery efficient solution because using it implementing a separate connection with the admin platform would become unnecessary.
In our case, we were prohibited to use any third party service due to GDPR. We used a WebSocket for communication, which contributed to battery drainage. As mentioned before our watches served the only purpose to run this application, so we have restricted the cellular network to only use 2G, because checking battery history data it seemed that the cellular is consuming a lot of battery. It had no effect on the connection, but we’ve spared some battery this way.
At this point, Canary had a two-way communication channel with the admin platform, so it seemed like a logical next step, to use that connection to send the alerts to the watch. But as tested inside factories, there was barely enough mobile network. SMS proved to be a more reliable solution in case of delivering an alert to the watch. (Again, Firebase integration could have also served this purpose). SMS also reached the watches with lower battery, by the time the network connections were already dropped by the device itself. It was also very easy to react with vibration to an incoming SMS using BroadcastReceivers.
Starting from Android 6.0 Google introduced Doze mode, which killed our WebSocket connection pretty easily on the watch, in order to save battery, but this behavior wasn’t suiting our needs for this project since we had to take care that the watch is always online (has an open WebSocket connection) on the admin platform. To avoid this, we introduced a foreground service to the app, which makes sure that our application is up and running, even when the user is not interacting with it. But there is a reason, that doze mode kills your application, and you are right: battery. The average smartwatch packed with features doesn’t last longer than a day with heavy usage.
Besides the above-mentioned feedback we also used the WebSocket to inform the admin panel about the worker’s heart rate, the battery status and whether the watch is worn or not. Since an average work shift can go up to 9 hours, it definitely served as a challenge to design everything to fit inside our application, without killing the battery after 5 hours. After a lot of brainstorming, I’m pretty sure we have achieved every possible way to save battery.
For scheduling messages to be sent to the admin panel, we used Handler. Because of the foreground service, scheduling only took part while the application was running. AlarmManager and JobScheduler use system resources to schedule tasks. Handler is only using application resources, so it was more efficient.
Scheduling tasks in Android:
- JobScheduler: good when the timing is not important, or you want to declare any criteria for the execution, like network type or charger connection (e.g.: you want to schedule a bigger download when the device is connected to a power source)
- AlarmManager: intended to use when you want a task to run at a specific time (e.g.: every morning at 8 am).
- Handler: optimal to use for timing operations (ticks, timeout), as we did in Canary.
Also for scheduling repeating tasks under 10 seconds, only Handler guarantees exact(ish) execution. In order to save battery, we prolonged the Handler’s repeating time. At first, we sent heart rate messages every 3 seconds and the battery every 30 seconds, but it didn’t provide more useful data about the user or the watch’s state. So we optimized message scheduling and decided to only send the battery’s state every 10 minutes, and the heart rate every 7 seconds. We have also taken advantage of the on/off sensors and made sure to turn off the heart rate sensors every time the user is taking off the watch.
We made sure to make the UI as simple as it must be in regard to UX since complex interfaces probably with animations drain the battery quicker. We didn’t use any animations on the watch, only designed simple and not complicated UIss containing just the right amount of information. Skeletonizing the Huawei watch 2 to its bare minimum also saved us a lot of battery. We have turned off everything using system resources on the watch: watch face, Bluetooth, wifi, always-on screen, gestures, android services, and basically anything using the battery, that was not needed, then tested the watch for a day checking we didn’t turn off something essential. At this point, with the forced 2G, we have improved the watch’s lifespan significantly. If your smartwatch is having battery issues, Google also recommends letting your watch go to sleep, turn off notifications and adjust screen brightness.
When a user receives an alert, the watch’s screen is turned on, and it vibrates until the user notices it and sends feedback to the admin platform. To make sure to turn on the watch, display the correct interface and avoid it to go to sleep we used wake-locks. Without acquiring a wake lock, the watch would start to vibrate, but the screen would be still black, the user still had to navigate to the application in the menu, open the app, and then push the correct button. After sending the feedback, the wake lock is released, so the watch can go to sleep again to save battery. It is important to hold wake locks only when they are needed and release them as soon as the job has finished.
We have tested our application with Battery Historian. As Google says “this tool provides a system-wide visualization of various app and system behaviors, along with their correlation against battery consumption over time.” We used it to make sure we are not holding any unnecessary wake locks at any time, which could cause battery loss. It also helped check how cellular is impacting the battery. Battery Historian proved to be a very helpful way to check if we are making any mistakes and check how Canary is improving after every iteration.
It was quite challenging to squeeze every feature into the application. In the beginning, the biggest problem was solving the vibration. Since the application tends to kill itself, for my first android project it was very challenging to figure out every scenario and test if the proper UI is popping up and the watch stars to vibrate when receives an SMS. The watch reacted differently for example if another app was opened, or I was browsing the menu while receiving a message.
For testing, we have sent more than 2000 messages, so after some months I could even hear the distinctive vibration even at home all the time. After we came to the realization, that the battery dies after 5 hours, it took quite a lot of googling and brainstorming to figure out every small detail to achieve a 10–12 hour lifespan. Better software design, better solutions, helpful colleagues all helped to create this project, which made its proper debut at last year’s T-Systems Symposium.