android iot watch

Android IoT: How to Solve Your Problems with Android Studio

Learn from our recent experiences

Author: Louis, Products  
Last updated: April 24, 2018

With the immensely strong desire for effective digital transformation, IoT has become one of the greatest means to advance data collection and analysis.

In this use case, we had already built the architecture for a scalable Azure IoT health service. However, the next step was to find a device and operating system that could provide the necessary data for us to operate.

As such, here you will find our learnings and resources to build an Android IoT solution that enables a modern flow of data. This includes our discoveries around sensor access and UX developments.

iot guide

Choosing Android Wear

Firstly, we had the challenge of identifying a combined device and operating system that could meet the various demands of this project.

This involves the following fields:

  • Low latency sensor collection
  • Tooling that enables us to identify bugs and iterate quickly
  • Seamless disconnection recovery
  • Offline accessibility

Along this journey we built a few prototypes to explore the applicability of multiple operating systems – including the Microsoft Band and Samsung Gear S3.

However, we finally settled on the Huawei Watch 2 running Android Wear.

With this in mind, we believed that Android IoT was the most appropriate tool-set for the issues facing us. As such, the following is a breakdown of how we navigated Android Wear to arrive at our targeted outcome.

The familiarity of Android IoT

The first thing we recognised when beginning with Android Wear in Android Studio is how similar the entire process is to developing standard applications for Android.

APK’s, ADB, permissioning and debugging all work exactly as you would with a normal Android application.

This is a genius move by Google to leverage tried-and-tested technology. Equally, this also widens the audience of Android Wear developers that may have worked on standard Android applications before.

In conjunction, feel free to read about these other IoT examples.

Getting started with documentation

The documentation that most interested us was sensor access, which we will get into later.

We found that having solid documentation really accelerated the first few days of going from zero code to a background service retrieving a handful of sensors, multiple times per second.

But here’s the kicker:

In addition to general services, the documentation also proved useful for our data science team to be able to read into and request features for sensors to be enabled.

With the similarity between Android Wear and Android itself, any issues could be compared to the wealth of answered questions at Stackoverflow regarding Java, Android or Android Wear specifically – enabling us to quickly find solutions.

Sensor access for IoT Android

Many in similar situations will agree that direct sensor access is something that cannot be taken for granted.

Operating systems can be inconsistent in the way they provide access to sensors. Locking down sensor access to native services or the frequencies of sensors can be a real choke point on some gadget based OS’s.

This wasn’t the case in Android Wear.

Not only were we able to get full access to all the sensors we needed, but we were also able to utilise custom sensors specific to the device in the same fashion – another bonus 

With that said, one issue we faced with the SensorManager inside of Android Wear was such that it was actually reporting faster than we had requested in code. However, this is by design and as mentioned earlier the reasoning can be found within the developer documentation.

Smart connections

Having a reliable internet connection is ideal but not always achievable. Especially with a device attached to the user who is going about their daily business.

Ideally we shouldn’t have to concern the user with connectivity – we take the approach we have to expect disconnections and failed messages by design.

The first step to approaching this issue is to design through an offline-first architecture.

An offline-first approach at designing your application means that you embrace the fact that your application will be offline at least some of the time and treat internet connectivity as a bonus.

For us, this helped to design a pipeline through which live data is immediately logged to device storage.

Thus creating two processes: live sync and background sync.

Whereby live sync looks to upload the latest data from the device and background sync looks to gradually upload chunks of old data.

Once you have a solid synchronisation strategy in place you’ll actually find that the Android Wear OS actually aids you with disconnection issues.  Fortunately, the OS will automatically switch between its own Wi-Fi and its own built in sim card with little delay.  Better yet, the device will also then look to use a tethered phones own Wi-Fi or 4G connection.

For those developers concerned about using a customer’s phone data, fear not.  You can easily detect what type of network you are currently connected too.

Android Debug Bridge

This is the swiss-army knife of android development.

Throughout development you’re going to need to communicate with your device. This means that deployment, debugging and logging are the staples of the development process and a streamlined process is essential for helping you iron out those bugs in good time.

Therefore, the next step is to choose your preferred connection method: bluetooth, Wi-Fi or direct through USB.

These all act the same once you’ve connected to your device – you can deploy, add breakpoints and monitor logging easily within the studio.  Should you have issues debugging your application when you need to physically move the device away from your PC – no problem.

Connect through ADB Wi-Fi/Bluetooth and your debugging session will stay alive.

This really aided us when we wanted to debug our code away from our desk whilst testing things like activity recognition or step counter.

User Interface

In this example, there are times when the user will have to interact with our application.

This can be through alerts or they may themselves wish to turn sensors off/on or simply view their heart rate. Designing user interfaces for these screens becomes involved.

There are multiple screen sizes you need to cater for, especially for components that won’t necessarily sit well in the layout on smaller screens.  More so, there is the huge challenge regarding whether watches have square or circular screens.


Luckily, Android Wear implements a very similar material design that exists within the current Android ecosystem.

Having a well-structured design pattern already implemented for you takes a lot of the headache out of user interface design.

As such, designing for Android Wear really follows these core principles:

  • Simplicity (Cut the excess, show only what the user wants to see, use typography to highlight important implements)
  • Glance (show only the most relevant information or actions, keep this contextual)
  • Test your designs (screen sizes and shapes are easy to see in the studio and on watches themselves)

For us this was great, as we wanted to concentrate on the core application which was gathering of the sensors on the watch and sending them up to our Azure solution as quickly as possible.

Visual tools

Android studio has some subtle but great tools for seeing how your application would look on devices that have a different screen size or even different screen shape.

The user interface elements are standard Android ones so the transition into wear is almost instant.


As such, previewing changes in all sorts of orientations and resolutions was a huge time saver for us especially when debugging code first on the emulator and then on the watch.  We were quickly able to see if layouts worked well between these two.

Reaching many Android IoT devices

Similar to building an application for Android, building for Android Wear means your code will be compatible with a wide range of devices – bar a few compatibility issues with custom sensors.

However, if you follow best practises and only use these custom sensors to enhance your application on some watches then this shouldn’t be an issue.

This really empowers the user to pick a device and style that’s unique to them and prevents you from being locked into a specific device further down the chain if hardware such as the battery life becomes a real issue.

In regards to the breadth of Android IoT devices –

  • Android Wear is experiencing rapid growth right now, last holiday alone activation of new devices rose 72%.
  • The amount of brands partnering with Google to produce watches solely running Android Wear doubled from 12 to 24.
  • Choice of watches running Android Wear has also doubled from 23 last year to 46 this year.

This empowers businesses to build solid code bases whilst minimising the amount of time taken to move to newer devices.

Over to you

We hope that this article helps you understand the different matters that enabled us to build Android IoT with Android Studio.

We’d love to hear how your projects have got on, or if you have any further questions. Feel free to drop us a comment below.


New Call-to-action

Topics: Devices, IoT

KNOWLEDGE IS POWERGet weekly email insights from RedPixie

IT Partner Success Choose correctly and boost your value by 56% →
surface banner.jpg