2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC)

A Comparative Analysis of Wearables Operating

Systems Based on Functional Constraints
Vicente J. P. Amorim, Saul E. Delabrida and Ricardo A. O. Oliveira
Computing Department (DECOM)
Federal University of Ouro Preto (UFOP)
Ouro Preto, Brazil
Email: vjpamorim@gmail.com, saul@sdelabrida.com, rrabelo@gmail.com

Abstract—A wide variety of wearables are now being sold
on the market. Improvements in hardware performance and
miniaturization allowed the creation of new advanced devices.
Despite this focus on hardware optimization, the software part
may also have an essential role inside wearables continuous
development. There is a need to understand the main impacts of
operating systems in this ecosystem, particularly on performance
aspects. This work presents a functional comparison between
some of the most common operating systems used by wearables.
In the absence of a standardized benchmark, authors have
created a set of evaluations to figure out the system with the best
performance. Results presented at the end helps to determine
the best operating system in each scenario, forcing designers and
developers to choose the software solution taking into account
this environment-specific features.
I. I NTRODUCTION
The wearables devices are increasingly gaining market
space, taking advantage of electronic components miniaturi-
zation. As these elements become smaller and smaller, the
hardware performance evolves, and the range of existing wear-
ables increase. Devices like watches (smartwatches), fitness
trackers, smart bands, augmented reality (AR) / virtual reality
(VR) glasses and others can be easily found on stores [1][2].
Some of these products have also led to new performance
requirements, demanding more hardware processing power
(e.g. devices with an interactive display that provides real-
time feedback to the end user). In contrast, other solutions are
using simple approaches (e.g. fitness trackers that commonly
act as a single vital signal monitoring equipment, without
having any visual interface). For the connectivity side, there
are wearables with local connectivity needs (e.g. Bluetooth or
NFC), while others, aim to support a broad range of networks
and protocols. Briefly, the greater the device connectivity
degree and processing power the greater are the hardware
resources necessary to sustain the whole system [3].
From the software perspective, complex wearables solutions
commonly consider the use of operating systems (OS’). Many
proposals vary from real-time approaches [4] to mobile OS’
adaptations [5][6], providing more or less performance ac-
cording to its purpose. This fact may be associated with the
broad range of applications covered by wearables solutions,
making tough to decide the optimization focus an OS must
have. Despite that, an OS commonly has peculiarities that must
be considered when applying it to a specific function or area,
such as real-time constraints that take into account preemption
and context switching times as critical variables. In the same
way, input/output (I/O) efficiency, memory management and
graphics drawing time may be addressed [7].
In this paper, the authors present a comparison between a
set of different OS’ used by wearables solutions. In a lack
of a proper benchmark to evaluate them, an assortment of
tests was built covering complex and straightforward scena-
rios that enclose I/O data performance, graphical operations,
simple/parallel processing and general processing tasks. This
research helps to demonstrate the impact of an OS designed for
wearables, decoupling software from hardware, and analyzing
the first one separately. Still, the authors general objective is
not to define “which is” the best OS for wearables, but examine
the popular ones and describe the best scenario where each one
can be applied. The main contributions of this paper are:
• A characterization of wearables according to its functio-
nalities;
• An initial set of benchmark tests to evaluate wearables
OS’;
• An OS comparison based on specific constraints, mea-
suring performance and impact of each one;
• A comparative review of hardware available to be used
by wearables.
II. M OTIVATION AND BACKGROUND
A. Main Challenges
One of the main ways to quickly improve wearables
performance is the addition of better hardware. However,
this is not the only way to achieve the same result, with
several researches being conducted in software part, including
approaches to offload processing of heavy tasks to the cloud
(or to devices in the neighborhood) [8] and others [9].
Analyzing the software side, an OS is in charge to control
and manage system resources. Embedded Linux (raw version),
Google Android Wear, Samsung Tizen, Linux Foundation
Zephyr, RIOT OS, Google Android Things and Apple Watch
OS are some examples that fit the wearables universe. Many
of them are adaptations from smartphones/tablets versions,
what may force final products to consider a more powerful
hardware. These facts can be used as motivation to investigate
the best OS’ to be employed in each wearable device appli-
ance. A correct OS choice can improve system performance

978-1-5386-4790-5/18/$31.00 ©2018 IEEE

 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC)
and diminish energy consumption demand, besides reducing
unnecessary expenses.
Considering the research context, there are studies covering
wearables benchmarking, enclosing proposals for specific [10]
and general [11] solutions. In the same way, OS’ area also
has a relevant number of researches covering its performance
evaluation through benchmarks [12]. However, an OS evalu-
ation inside wearables context is particularly difficult to find
in the literature, once most of the time the hardware is tightly
coupled to the software. This challenge was addressed by this
paper isolating the OS’ inside virtual machines as a way to
run performance tests and parametrize the obtained resulting
data. Another issue was the absence of a benchmark covering
wearables context, what motivates the creation of an initial set
of tests applicable to this embedded environment.
B. Wearables Overview
On the past, [13] has characterized a wearable device as
being a head-mounted display providing virtual information
to the end user. Nowadays, these devices evolved to AR
equipment, presenting an additional layer of information con-
textualized to the real world. Recent evolution of integrated
circuits allowed the design and creation of small products
affording the wearable devices to be applied on different areas
[14][15]. As a result, a more complex hardware is being
taken into account, requiring a higher processing power. By
the software side, OS’ have been applied to reach a more
efficient and robust control of device resources, what most
of the time requires a hardware upgrade. Once wearables
OS’ do not have all the features as in its desktop version,
some system specific variables must be optimized, such as
process scheduling, drawing, input/output (I/O) performance
and energy management to enhance user experience [7].
1) General Characterization: Wearables on the market em-
brace different applicability areas: fitness activities monitors,
health, gaming, rescue, entertainment, activity recognition and
so on. Each device may have its functional requirements, with
software and hardware sharing a set of demands. [7] provides
an initial characterization of wearables, which can be extended
to cover hardware components, software requirements, and
embedded functionalities. Additionally, as presented in [16],
these solutions may be classified according to its dependency
level of I/O and graphical operations: “User Interface (UI)
dependent”, “I/O dependent” and “Hybrid”. Indeed, these
classes can be extended to a more detailed characterization
considering whether the device has a graphical interface and
provides more or less interaction with the users, forcing the
hardware requirements to be increased or decreased. In the
same way, I/O requirements commonly focus on sensors data
retrieval and transmission, a fact that frequently does not
request user interaction. In this way, considering the inter-
activity level, a more accurate characterization can be given
respecting the following layers, from the most basic one (Layer
0 – bottom) to the most complex one (Layer 4 – top). Top
layers may reuse functionalities from bottom ones, creating
an extensible concept: Layer 0: Devices without a visual
display that has its focus on data gathering and transmission
(e.g.: health monitors and fitness trackers). This is the closest
point to simple Internet of Things (IoT) devices; Layer 1:
Wearables using a simple display to show a layer of text
and 2D graphics (squares, circles, icons, and pre-processed
images) on the screen to represent physical places or points
of interest; Layer 2: Addition of interaction to the features
provided by Layer 1. Users can manipulate graphics on screen
overlaying the real world; Layer 3: Equipment with 3D-
rendering capabilities that may (or may not) be able to process
user interaction (used by AR/VR solutions); and Layer 4:
Use of pattern recognition, machine learning and other AI
techniques to extract and recognize real-world objects. The
GPU hardware may help graphics processing tasks to reach
real-time execution.
III. W EARABLES AND E MBEDDED O PERATING S YSTEMS
A wearable device performance is directly related to the
software it runs. Here it is presented a description of main
OS’ that eventually can be used by some wearable. IoT OS’
were considered by this work once they commonly have a low
footprint and are prepared for environments with moderate and
heavy resources constraints.
The following embedded OS’ have been examined by this
work: Generic Embedded Linux: The Embedded Linux has
a generic build for a broad range of embedded devices.
Build tools like Yocto Linux and Buildroot can ease the
task of creating an embedded distribution. Although it can
reduce development time, there is no directive to support the
wearable environment explicitly; Samsung Tizen: Samsung’s
open source OS encloses mobile, wearable, and In-Vehicle-
Infotainment (IVI) devices [5], being currently embedded on
smartwatches companys version. Tizens latest release (3.0) de-
livers a common software base between all the environments.
However, until now, there is no real-time constraints specifica-
tion or more details regarding wearables context-specific vari-
ables that were optimized for this OS; Google Android Wear:
Supporting smartwatches devices, this Googles open-source
OS provides a development environment to build specific
applications. Most Android Wear features are anchored in an
interface with Android smartphones [6], being used as a soft-
ware base by other manufacturers to customize new devices;
Linux Foundation Zephyr: Designed for IoT environment,
Zephyr [4] OS has a small footprint. It is an open-source OS
and was developed as a real-time operating system (RTOS),
providing a network stack, device management capabilities
and support to hardware sensors; Google Android Things:
Developed to speed-up IoT solutions to the market, this OS
trusts in a set of prototyping boards already compatible. It
uses the same Android mobile infrastructure and libraries as
a way to reduce the system learning curve. Currently, there is
only a Software Development Kit (SDK) preview available
for download [17]; RIOT OS: Focused on IoT solutions,
RIOT OS [18] provides an open-source system with real-time
support and low memory footprint, running on most common
architectures and boards in the market.; and Apple Watch
 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC)
OS: Apple’s wearable OS used by Apple Watch products.
Works synchronized with iOS through a Bluetooth connection.
Developers can use an SDK to design and build watch OS
applications [19].
IV. O PERATING S YSTEMS C OMPARISON M ETHODOLOGY
A. Selection Criteria
Three of those previously presented OS’ were chosen to
have a detailed evaluation: Generic Embedded Linux: Se-
lected due to its customization capabilities. Buildroot tool was
used to generate a customized embedded Linux. Only strictly
necessary software modules were selected to be inside the
kernel and root filesystem. For graphics side, Direct Frame
Buffer (DFB) library (version 1.7.1) was selected, once it is a
lightweight solution with low overhead on drawings. As a way
to reach a good coverage, Linux OS was considered in three
different architectures: X86, ARM and RISC-V, despite this
latest one still in an “under development” phase; Samsung
Tizen: A specific solution for wearables environment and
currently embedded on market products, such as Samsung
Gear S2 smartwatch. Tests were made using Tizen Wearable
OS version 2.3.1; and Google Android Wear: Provides a
wearable environment specific solution. Android Wear version
taken into account was based on Android 5.1 API 22.
Operating systems other than those listed above were not
deeply examined due to particular reasons, such as limitations
on provided SDK, lack of an SDK (or its documentation),
low images maximum resolution, and a display with a limited
number of colors.
B. Environment Setup
Selected OS’ were configured inside five similar virtual
machines with identical hardware arrangements running on
the same host. For every platform, no hardware acceleration
or external intervention was allowed (except in cases it was
the test object), in a way that even graphics processing was
made through software. Furthermore, network interfaces (Wi-
fi, Bluetooth, and NFC) and cameras (front and rear) were
disabled as well as any emulated sensor, such as gyroscope,
accelerometer, proximity, heartbeat, and GPS. Indeed, the
virtual machines have been configured with a single core
processor, QEMU Virtual CPU version 2.0.0 with 2.4GHz,
4096KB of cache memory and 1024MB of RAM inside a host
machine with the following configurations: CPU Intel Core
i5 with 2.5GHz - Dual-core, 4096KB of cache memory and
16GB of RAM. Additionally, tests were also executed into four
different real hardware platforms, commonly used to prototype
wearables solutions for research and market purposes: Texas
Instruments TI Beagle Bone Black (running ARM Linux)[20];
NXP i.MX6 Quad Wandboard (running ARM Linux) [21];
Raspberry Pi 2 Model B (running ARM Linux) [22]; and
Intel Edison (running X86 Linux) [23]. Evaluations made
by this work considers a similar QEMU virtual machine
configuration as a standard for all the virtual platforms. Even
that, it is reasonable to consider that some variations may
have some performance influence. Therefore, data presented
by this research should be compared only between them, once
some variation may be observed when contextualizing with
real platforms.
C. Test Applications
Eight sets of tests focusing on I/O, graphics drawing,
parallelism, and data processing were created. Except for
Embedded Linux OS, which has used DFB library and GNU C
library (glibc), SDK functions provided by the manufacturers
were taken into account.
• I/O: Test I/O operations reading/writing data to the local
filesystem. It was divided into two different sets: Latency:
Evaluate the time spent to read and write 30MB of raw
data, separated in 512bytes-size packets; and Through-
put: Evaluate the time spent to read and write 30MB of
raw data, distributed in five different packets;
• Image rendering time: Render time was verified through
an application that draws an image to the display. Same
800x600 pixels image was considered for every scenario.
When available, graphics processing unit (GPU) was
enabled to evaluate the OS behavior when receiving
external help;
• Graphics drawing time: Check OS performance when
drawing vector figures. It was assessed the time needed
to serially draw on the screen, 200 squares of the same
size. Like the previous test, GPU was also enabled when
available;
• Processing time: Evaluate how OS’ deal when a high
processing task is executed: Matrix multiplication: Mea-
sure the time spent to multiply two different 600x600
matrices of integers; and Matrix transpose: Measure the
time spent to transpose a 600x600 matrix of integers;
• Parallelism: Assess the time to process two heavy
tasks:I/O latency + Graphics drawing: A test appli-
cation with two parallel tasks: The first one running
“I/O latency” test, and the second one running “Graphics
drawing time” test; I/O throughput + Graphics drawing:
A test application with another two parallel tasks: The
first one running “I/O throughput” test, and the second
one running “Graphics drawing time” test;
I/O test applications were considered as a way to verify
the OS behavior when dealing with external devices (e.g.
wearable sensors or network interfaces). Data size (30MB)
was estimated as being the size of a heavy data payload
to transfer when dealing with a wearable device. Graphics
test applications have its focus on verifying OS behavior
when drawing an image to a screen (e.g. AR/VR devices
or smartwatches). Processing time and parallelism tests were
run to figure out the OS behavior when dealing with those
two requirements on interactive systems. Applications’ per-
formance was calculated using execution time, considering
only instructions and function calls associated with the related
functionality. For instance, only routines related to drawing
preparation and rendering were taken into account when
evaluating “Image rendering time”. Additionally, data results
were collected considering 34 runs of every application in each
 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC)

scenario, with the two higher and two lower outliers being
removed. At every test, applications were restarted to ensure
no OS optimization/cache has remained in the background.
V. R ESULTS
Information presented by Table I makes possible to conclude
that, an OS has its focus in IoT or wearables area, the majority
of OS’ are open-source and have an SDK available. Figures
1,2,3 and 4 compare the OS’ running in virtual machines
and real hardware. Although this kind of comparison is not
technically correct, here it is used as a way to mensurate the
impact of real hardware. The data shown here considers 95%
of confidence interval.
A. I/O Latency and Throughput
Figure 1 summarizes the OS’ I/O performance tests results,
where the first graph is related to I/O latency, and the second
one describes I/O throughput data.
1) Latency: No matter the operation is being executed (read
or write) Android Wear has the lowest latency between the
three OS’, followed by the Linux Embedded (X86, ARM, and
RISC-V, respectively). Tizen OS reached the highest values
for latency, with its average value greater than four times the
value obtained during Android Wear experiments. Still, Tizen Fig. 1. I/O performance results of evaluated operating systems.
error rate is the highest one, letting us conclude that it also has
a high jitter on this type of I/O. Additionally, all OS’ spent
less time reading than writing data (even when considering 2) Graphics Rendering: In this set of tests, Embedded
real hardware). Linux OS’ got the worst average time, while Tizen and
2) Throughput: I/O throughput execution time is signifi- Android Wear presented the better results. This data may
cantly smaller than I/O latency. As happened in latency tests, also lead to conclude that Tizen and Android Wear has been
Tizen OS got the worst performance, with Android Wear and optimized to prioritize tasks that draw on the device display.
Embedded Linux (ARM) achieving best results, even when Unlike previous tests, real hardware platforms have performed
compared to real hardware platforms. Again, the time spent much better when compared to solutions running in a virtual
reading data is much smaller than the time spent writing this. machine. However, they were not good enough to surpass the
On both previous cases, Embedded Linux (RISC-V) has not behavior presented by the two best OS’ (Tizen and Android
performed well, a fact that could be due to its “under de- Wear).
velopment” status. In general, real hardware performed better
than OS’ running in virtual machines. However, Android Wear C. Processing Time
reached a performance in the same level of real hardware, Figure 3 depicts the OS’ processing time performance
suggesting that the SDK was modified with optimizations. results. The first graph is related to matrix multiplication, and
the latest one describes matrix transpose.
B. Graphics 1) Matrix Multiplication: It is possible to verify an “al-
Figure 2 summarizes the OS’ graphics performance results, most” homogeneous behavior when considering only OS’
where the first graph is related to image rendering, and the running on virtual machines. Due to the hypothesis raised
latest one describes graphics drawing. before, Embedded Linux (RISC-V) architecture had the worst
1) Image Drawing: Unlike previous results, the average performance. Embedded Linux (X86) architecture reached the
time spent to draw an image on the screen was statistically best results, a behavior the authors believe is due to internal
equivalent on Tizen and Android Wear OS’. Given the execu- configurations of caching. Performance presented by Intel
tion time difference when comparing Tizen/Android Wear with Edison and Wand boards are much better than the other two
Linux version, it is possible to affirm that some optimization platforms. This fact can be easily explained analyzing the
was made on the first two OS’. By its turn, both versions of hardware configuration of each board.
Embedded Linux with DFB library had not performed well, 2) Matrix Transpose: Execution time presented by matrix
even when GPU hardware was enabled. Another interesting transpose tests maintain the same behavior verified on matrix
point is the poor performance obtained by real hardware multiplication results, despite it takes less time: Embedded
platforms that were as bad as the Embedded Linux OS’ Linux (X86) has the best performance, while Embedded Linux
running on virtual machines. (RISC-V) the worst one. The explanation rises when analyzing
 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC)

TABLE I
O PERATING S YSTEMS C LASSIFICATION ACCORDING TO F EATURES

OS / Characteristic Graph. Support User Interface IoT Focus Wearab. Focus RTOS Open Source SDK Available
Samsung Tizen OS
Linux Found. Zephyr OS
Embedded Linux
Google Android Wear OS
Google Android Things
RIOT OS
Apple Watch OS

Fig. 2. Image rendering and graphics drawing performance of evaluated OS’. Fig. 3. Processing performance tests results.

real hardware platforms: Wand board hardware has the best
execution time. Still, Linux (X86) has a performance near to
the real hardware platform. This behavior is impressive when
considering the context and previous results, once no particular
optimization was made on this Linux distribution.
D. Parallelism
Figure 4 depicts the tests results of OS’ parallel processing.
The first graph is related to “I/O latency + graphics drawing”,
and the second one describes “I/O throughput + graphics
drawing”.
1) I/O Latency + Graphics Drawing: On most of OS’, the
addition of a new simultaneous task had no significant impact
when comparing the results presented here to those one listed
by I/O latency tests on Figure 1. When considering GPU-
enabled, the execution time was reduced, however without
a notable variation. Additionally, results on real hardware
platforms show the hardware impact on performance, once
Wand board platform has a quad-core processor.
2) I/O Throughput + Graphics Drawing: It is possible
to verify the same behavior as in previously presented I/O
throughput tests. As the execution time was reduced on
throughput tests, Android Wear and Tizen have almost equaled
its behaviors. Embedded Linux (ARM) presented the worst
execution time, followed by Embedded Linux (X86). The
authors believe this behavior is due to the lack of optimizations
on Embedded Linux versions. In real hardware Wand board
platform still leading as the best scenario. Indeed, when
comparing the top graph with below graph, it is possible to
verify the same behavior.
E. General Analysis
Results presented in previous subsections allow verify-
ing the real impact of software on wearables environment
performance. On almost every scenario (I/O, Graphics and
Processing Time) there was a significant difference between
the best versus the worst OS/platform. For instance, the
 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC)
Fig. 4. Parallel processing tests results.
performance reached by Android Wear and Samsung Tizen
on graphics assessments is relevant, especially when taking
GPU support into account. This behavior can also be ob-
served when isolating and analyzing only the results from real
platforms. However, in this scenario, it is possible to infer
that hardware configuration also has some importance and
influence on general results. Finally, results present the real
impact an optimized OS can have on the overall performance
of a wearable appliance. Indeed, an optimized system can
even avoid the need for performance increase through new
hardware, reducing product/solution general costs.
VI. C ONCLUSION
Wearables are currently becoming more and more attractive
to the end users, once many types of devices can be found
on the market at lower prices. The wearables optimization
and development commonly go through the hardware opti-
mization, while little work is employed on the software side.
A software evaluation on these devices is hard work, once
it is challenging to detach the hardware from the software
components. In this work, the authors presented a compar-
ison between wearables OS’ through the software isolation
on virtual machines, helping to understand their strengths
and weaknesses. While Embedded Linux had an excellent
performance on I/O, Samsung Tizen and Google Android
Wear performed well on most of the tests, sometimes being
equivalent to the results presented on real hardware. As a
general conclusion, considering only the wearables context,
these two OS’ appear to be optimized and can be listed as the
current best OS’ options among those compared in this work.
As future researches, a closer investigation of the reasons
behind some great/poor performances may help to understand
the OS’ and wearables devices relationship.
R EFERENCES
[1] Microsoft. (2017) Hololens. https://www.microsoft.com/en-us/hololens.
Accessed: 12 april 2017.
[2] Samsung. (2017) Gear vr. http://www.samsung.com/us/mobile/virtual-
reality/. Accessed: 12 april 2017.
[3] E. Shiu and S. Prakash, “System challenges and hardware requirements
for future consumer devices: From wearable to chromebooks and devices
in-between,” in 2015 Symposium on VLSI Circuits (VLSI Circuits), June
2015, pp. 1–5.
[4] L. Foundation. (2017) Zephyr project. https://www.zephyrproject.org/.
Accessed: 12 april 2017.
[5] Samsung. (2017) Tizen project. https://www.tizen.org/. Accessed: 12
april 2017.
[6] Google. (2017) Android wear. https://www.android.com/wear/. Ac-
cessed: 12 april 2017.
[7] S. Delabrida, T. D’Angelo, R. A. Oliveira, and A. A. Loureiro, “Building
wearables for geology: An operating system approach,” SIGOPS Oper.
Syst. Rev., vol. 50, no. 1, pp. 31–45, Mar. 2016.
[8] H. Qian and D. Andresen, “Extending mobile device’s battery life
by offloading computation to cloud,” in 2015 2nd ACM International
Conference on Mobile Software Engineering and Systems, May 2015,
pp. 150–151.
[9] M. Hooshmand, D. Zordan, D. Del Testa, E. Grisan, and M. Rossi,
“Boosting the Battery Life of Wearables for Health Monitoring through
the Compression of Biosignals,” IEEE Internet of Things Journal, vol.
4662, no. c, pp. 1–1, 2017.
[10] R. Jafari, O. Dehzangi, C. Zong, and V. Nathan, “Bcibench: A bench-
marking suite for eeg-based brain computer interface,” in Proceedings
of the 11th Workshop on Optimizations for DSP and Embedded Systems,
ser. ODES ’14. New York, NY, USA: ACM, 2014, pp. 19–24.
[11] R. Beckmann, C. Bertelsmeyer, E. Dueselder, H. Iben, E. Koch, and
H. Kenn, “Wearable games as a benchmark method for wearable
computing research,” in 3rd International Forum on Applied Wearable
Computing 2006, March 2006, pp. 1–7.
[12] S.-H. Chen, H.-M. Lin, K.-Y. Chen, Y.-H. Chang, P.-C. Yew, and C.-C.
Ho, “A systematic methodology for os benchmark characterization,” in
Proceedings of the 2013 Research in Adaptive and Convergent Systems,
ser. RACS ’13. New York, NY, USA: ACM, 2013, pp. 404–409.
[13] I. E. Sutherland, “A head-mounted three dimensional display,” in Pro-
ceedings of the December 9-11, 1968, Fall Joint Computer Conference,
Part I, ser. AFIPS ’68 (Fall, part I). New York, NY, USA: ACM, 1968,
pp. 757–764.
[14] A. Merkouris and K. Chorianopoulos, “Introducing Computer Program-
ming to Children through Robotic and Wearable Devices,” WiPSCE
2015: The 10th Workshop in Primary and Secondary Computing Ed-
ucation, 2015.
[15] H. Ye, M. Malu, U. Oh, and L. Findlater, “Current and future mobile and
wearable device use by people with visual impairments,” in Proceedings
of the SIGCHI Conference on Human Factors in Computing Systems,
ser. CHI ’14. New York, NY, USA: ACM, 2014, pp. 3123–3132.
[16] V. J. P. Amorim, S. Delabrida, and R. A. R. Oliveira, “A constraint-
driven assessment of operating systems for wearable devices,” in 2016
VI Brazilian Symposium on Computing Systems Engineering (SBESC),
Nov 2016, pp. 150–155.
[17] Google. (2017) Android things. https://developer.android.com/things/index.html.
Accessed: 12 april 2017.
[18] R. OS. (2017) Operating system for the internet of things. https://riot-
os.org/. Accessed: 12 april 2017.
[19] A. watch OS. (2017) Apple watch operating system.
https://www.apple.com/br/watchos/. Accessed: 30 oct 2017.
[20] T. Instruments, “Beagle bone black,” https://beagleboard.org/black,
2017, accessed: 13 april 2017.
[21] Wandboard, “Wandboard i.mx6 quadcore,” http://www.wandboard.org/,
2017, accessed: 13 april 2017.
[22] Raspberry, “Raspberry pi 2 model b,”
https://www.raspberrypi.org/products/raspberry-pi-2-model-b/, 2017,
accessed: 13 april 2017.
[23] Intel, “Intel edison,” https://software.intel.com/en-
us/iot/hardware/edison, 2017, accessed: 13 april 2017.