Table of Contents [606295]

Table of Contents
Chapter One. State of Art ………………………….. ………………………….. ………………………….. ………………………….. .. 3
Chapter Two. Platform Design ………………………….. ………………………….. ………………………….. …………………….. 4
2.1 Hardware ………………………….. ………………………….. ………………………….. ………………………….. …………… 4
2.1.1 Android Smartphones ………………………….. ………………………….. ………………………….. ……………….. 4
i. The Graphics Processing Unit ………………………….. ………………………….. ………………………….. ……….. 7
ii. The Central Processing Unit and SoC’s as a Whole ………………………….. ………………………….. ……. 12
2.1.2 Android Wear Smartwatches ………………………….. ………………………….. ………………………….. …… 16
2.1.3 Web Server – Hosting and Physical Considerations ………………………….. ………………………….. … 19
2.2 Software ………………………….. ………………………….. ………………………….. ………………………….. ………….. 22
2.2.1 Android OS Concepts and Paradigms ………………………….. ………………………….. ……………………. 22
2.2.2 Android Wear OS ………………………….. ………………………….. ………………………….. …………………… 30
2.2.3 Web Server Protocols and Communication ………………………….. ………………………….. ……………. 32
Chapter Three. Project Implementation ………………………….. ………………………. Error! Bookmark not defined.
3.1 Hardware ………………………….. ………………………….. ………………………….. ………………………….. …………. 37
3.2 Software ………………………….. ………………………….. ………………………….. ………………………….. ………….. 39
3.2.1 Android Wear Application ………………………….. ………………………….. ………………………….. ………. 39
3.2.2 Android Mobile Application ………………………….. ………………………….. ………………………….. ……. 42
3.2.3 Web Server ………………………….. ………………………….. ………………………….. ………………………….. .. 44

Introduction

As technology has evolved massively in the past 50 years, especially the IT sector, one
common paradigm has started to dominate the developed world in recent years: Inter-Connectivity.
The concept itself extends its origin to the first working prototype of an inter -connected
network of computers, ARPANET. Standing for Advanced Research Projects Agency Network , it
was among the first implementations of communication th rough packet switching. This represented
a new method of transmitting information that, unlike its circuit -switching predecessor, would not
rely in establishing end -to-end dedicated connections. Instead, it was based on truncating the
information in chunks of information, which would be encapsulated in packets, the essential building
blocks of the communication. These packets would not need a dedicated path to their destination,
and could each be assigned different paths to their destination, where the rece iver would collect all
the packets and rebuild the transmitter’s information. This would prove to be invaluable to the
creation of multi -device networking, as the lack of dedicated lines meant that each peer could
communicate to the other simultaneously. It also paved the way to the formation of the TCP/IP
protocols, which expand the packet switching idea to a usable, concrete form of reliable
communication. More -so, this represented the proof of concept needed to bring large scale inter –
connectivity to mor e and more devices across the world, leading to the genesis of the modern internet.
The next big thing on the path of network evolution was when t he ‘Internet of Things Global
Standards Initiative’ had defined the ‘Internet of Things (IoT)’, in Recommendat ion ITU-T Y.2060
(06/2012) as a “global infrastructure for the information society, enabling advanced services by
interconnecting (physical and virtual) things based on existing and evolving interoperable
information and communication technologies.” [1] In other words, it brought forth a shift in the way
networking is designed by deeming every object and tool in our possession capable of
interconnectedness and intelligent features. In this new, connected world, our terminal into the digital
realm is no longer restricted to a PC station, or even a smartphone, but expanded to everything in to
our environment, projecting a future of an increasingly ambiguous border between the real and the
virtual.
It was this idea that drove m e to a project such as this, that information should not be
segregated in any way. Information especially about one’s own well being should be easily accessible
anywhere at any time so as to work in the interest of health in the most efficient way possible . As
such, the project will concern the migration of personal medical data into a digital environment in
the cloud, capable of supplying needed biomedical information to both patients an d doctors. This
provides an intuitive platform to both parties which a llows them to act as fast and effective as possible
in order to offer the best medical care possible.
With this in mind, my project aims to drive the medical IT infrastructure further into this
digital interconnectedness by bringing information on a platfo rm that is readily available and easy to
use. It proposes the use of handheld devices, specifically smartphones and smartwatches, to collect
important bio -data, to be further passed on to a central server. This hub will support a web portal
from which both doctors and patients will be able to access their health history and medical
information. This will allow the placement of the hub anywhere in the world, as the users will have
digital access to it regardless of its position, and also adds to the redundan cy of such a solution. At
the same time, since data will be stored on a central cloud location, the patients and doctors will not
be locked to a single device, rather any kind of computer that can open a browser can act as the peer,
providing full freedom while also giving full access to information.

Chapter One. State of Art

It is a fairly public knowledge from the state of today’s healthcare information system which,
to put it bluntly, is primitive and dangerously obsolete. Many institutions still rely on paper records
in order archive and distribute information, making the entire process not only slow and highly prone
to errors, but also very susceptible to environmental factors such as fires and calamities.
An entirely digital solution would allow the information to be safely backed up in multiple
geographical sites, presenting not only rest of mind if s omething were to happen to the original site,
but also the possibility to expand the system not only for backup, but to synchronize and offer
immediate access to vastly distant locations, without sacrificing time and power.
The first steps towards this mor e connected, interoperable, seamlessly digital future have
already been taken, as a 2013 survey from “Health Affairs” explains [2]: between 2009 and 2013,
more and more organizations started adopting an EHR (E lectronic Health R ecord) system. To be
precise , the adoption rate had reached around 78% of medical specialists and healthcare facilities .
The same study however found that of these, only 14% also shared their data with entities outside
their organization. This is a factor just as important , because once shared, that information can be
cross -correlated, stacked with similar data from other sources, fed into machine learning systems or
any number of other intelligent algorithms in order to research and produce better, valuabl e results.
Furthermore, only 30% of doctors kept in touch through digital messaging with their patients, and
only 24% also presented their patients with a means to obtain or view their records in a secure, easily
available, online platform. This again is p art of a true inter -connected system, which should not only
collect medical data, but also share it, both with organization capable of putting it to use, to research
medical advances, and with the patients themselves, to offer them an easy way to manage th eir own
data, without the need to spend valuable time (both theirs and their doctors’) waiting in lines, or
traveling across the city.
In effect, while more and more medical entities drive forward towards this digital
infrastructure, progress is slow due to various factors, chief amongst which being money , but far
from the only one. A very important issue regarding this endeavor is the entire legal apparatus that
must first and foremost take care of the patients’ right to privacy and personal information. How will
the patients’ data be share securely, privately, without risk of theft? How will this distribution of
information work while maintaining the customer’s right to have complete control over all
information that pertains to them? This is an especiall y difficult matter to entertain, since the rise of
cyber -attacks and data theft has forced governments to strengthen policies regarding private
information crossing the internet, as well as extend and enforce the rights of citizens to exert their
wish over how their data is being handled. This means that such an inter -connected medical platform
would need a highly sturdy and scalable information and network security infrastructure, further
massively driving up the costs of such a project.
Another important issue is the socioeconomic situation of a population. In the 2014 Stanford
Medicine X event, California was given as an example of a society where only 43% of people served
by health organizations had access to smartphones [3]. Since a fully digital medical platform would
require the real -time exchange of information with patients, having them without access to an
internet -enabled smart device would severely hurt the effectiveness of the system. As such, a difficult
question ari ses: Is the world even ready to fully take advantage of an inter -connected platform, when
a significant part of the population doesn’t even have the means to participate in this digital exchange
of data?

Chapter Two. Platform Design

2.1 Hardware

This chapter refers to the collection of physical devices on which the networked system
resides. It is primarily composed of a central server hub, in this case a PC, and a client, represented
by an Android smartphone and its connected smartwatch.

2.1.1 Android Smart phones

Dating back to 2008, the first smartphone to bear the Android system was HTC’s Dream
(initially branded as T -Mobile G1). It represented the first attempt at a physical handheld terminal
operating on completely open -sourced software. This OS being s till nascent, it didn’t rely quite as
much on its touchscreen as modern phones, having 5 different navigation buttons on the bottom of
the phone as well as a physical QWERTY keyboard under the screen.
An important aspect of this phone represented its SOC, the Qualcomm MSM7201A, which
helped raise the company’s market coverage as the Android OS grew. While Qualcomm previously
released a number of mobile SOC’s, for various phones and smartphone attempts, they would never
compare to the success the company wo uld have after being widely adopted by Android smartphone
manufacturers. The MSM7201A SOC shipped with 192 MB of RAM and an expandable 256 MB of
internal storage. In terms of network access, it supported quad -band GSM (850/900/1800/1900 MHz)
and GPRS/EDGE, dual-band UMTS (1700/2100 MHz) and HDSPA/HSUPA. [4]
In terms of CPU, the MSM7201A had multiple cores, but they lacked the multiprocessing
capabilities of current mobile SOCs, instead delegating a single core (in this case the ARM1136J -S)
to be used by the OS and running applications. The others were dedicated processor cores, generally
on the following tasks [5]:
– A decoding/encoding DSP for media (specifically QDSP5000)
– An ARM9 base band processor
– A decoding/encoding DPS for telephony (specifically the QDSP4000)
The SOC also contained various other units and controllers such as dedicated 2D and 3D
graphics hardware, several interfaces and an AXI controller (Advanced eXtensible Interfa ces,
memory controller, used for its – at the time – high performance and clock frequency [6]).
Although later versions have come to support the x86/x64 and even MIPS (Microprocessor
without Interlocked Pipeline Stages) architect ures, to this day Android’s main hardware platform has
widely remained the ARM (ARMv7 and ARMv8 -A to be precise). Initially running on 32 -bit
systems, the recent Android 5.0 “Lollipop” update has added support for 64 -bit SOCs. As for
specifics, the officia l requirements state that for a current device running Android “Lollipop”, the
RAM memory should be a minimum of 512 MB and growing to 1.8 GB if the device utilizes a high –
density screen. Previous android versions such as Android 4.4 could support smartph ones with as
low as 340MB, but the system performance would be far from ideal. [7] Graphics acceleration is also
required, represented by an OpenGL ES 2.0 compatible GPU (graphics processing unit) [8].
In addition to the actual hardware necessary to run the OS, originally the physical platform
contained many other components such as orientation sensors, GPS, tools to measure acceleration,
pressure and proximity obstacles, not to mention the touchscreen itself. Some of these were even
required, since the entire system started as a mobile phone OS, and components like microphone,
camera, touchscreen, were mandatory to run Android. These all were loosened up in recent years, as
the OS has started to transit ion far beyond just smartphones.

It is important to bear in mind that an Android system, be it a mobile phone or a TV setup
box, is essentially a Personal Computer. This was however not always the intention, and the main
issue at its inception – and st ill is – is that of inserting hardware powerful enough to compute complex
tasks, on a small enough physical platform to be handheld. As such, a modular approach as in desktop
PC’s has always been deemed near impossible, in terms of both spatial consideratio ns and of
performance. A desktop PC has a dedicated Central Processor Unit mounted on a motherboard which
serves as a backbone for the storage medium and RAM components, as well as an optional dedicated
Graphics Processing Unit. This demands the use of a l arge amount of physical space. Since
modularity was no longer a driving concern, this has enabled the focus to be shifted on optimizing
and integrating dedicated hardware components in a single, inseparable physical platform.
Thus was born the idea of a System on a Chip . [9] They are integrated circuits that converge
all the needed hardware elements of a system onto a single chip of reduced size. Below is a ro ugh
diagram of a typical such So C and its main components.

Fig. 1 – Rough Diagram of SoC Components

Generally, though, a So C contains on its platform the following elements [10]:
o The CPU (single or multi -core processor), which is the most important part of the chip.
It is a computing component with one or multiple independent actual processing units
(usually called cores). Here is where the program instructions are read and executed. Most
commonly, the processors found in SoC’s are based on ARM architecture, as the key
feature of this structure is high efficiency, low power, ideal for use on devices where
available energy is an important issue.
o The GPU (graphics processing unit) or media p rocessors, the second most important
component, deals with the actual interface between the SoC and the user: the screen. It
renders the code dealt with by the processor, to present the imagery required for the user
to interact with the device. Unlike the CPU, it’s architecture is based on parallelism and
multi -processing, containing much more cores than the main processor, in the range of
hundreds. This is applicable as the GPU’s task is not to read and execute code Media Processor
(GPU)
Memory Vector Coprocessor (multi) -Core
Processor
Analog and Custom
Circuitry System components Interconnects

sequentially, but to render the numerous objects and visual data in a scene, and project
these onto the screen’s pixels.
o The Vector (Co)Processor or array processor, is a central processing unit that has an
instruction set which operates with vectors (as opposed to scalar objects in a regular
processor) and single data items. Offloading processes to this element greatly improves
the performance on certain workloads. [11]
o The Bus interconnects all the elements of the system. It is characterized as either
proprietary, or industry -standard. To further increase efficiency and reduce latency, the
data between interfaces and memory can be directly routed by DMA controllers,
completely bypassing the processors.
o The Memory the same purpose as it does on any other platform, to store the data that the
program needs as it runs. Since SoC’s are low -power, their processes were never that
memory intensive either, as such RAM capacity was never one of the bigger issues. The
introd uction of the 64 -bit processor, allowing more than 3GB of RAM, was not such a
momentous event as it was on the desktop/server side.
o Northbridge & Southbridge – these are chipsets which handle various communication
and I/O functions. The Northbridge is task ed with the communication between the central
processor and all the other components. The Southbridge, while not always present, is
responsible for some of the I/O connections.
o The Cellular Radios are also central to a smartphone SoC as they contain the ne cessary
modems for mobile operators to ensure the device’s phone connectivity. They are tasked
not only with the traditional analog voice messaging and the SMS (Short Messaging
System) communication, but also allow for wireless internet access through vari ous
standards. This technology started with GSM (Global System for Mobile
communications) and currently the most common standards are the 4G/LTE. [12]
o Other Radios – Common to smartphones and to a lesser extent, any SoC -based dev ice,
are any number of other dedicated radios, ranging from GPS/GLONASS (the GPS
standard used in Russia), Bluetooth, Wi -Fi, etc.
Below are the block diagrams of two common mobile SoC’s, the Tegra 3 ( Nvidia
manufactured mobile SoC, commonly found in high -end tablets) and the Snapdragon S4 (Qualcomm
SoC, operating mostly in smartphones). [13]

Fig. 2 – Block Diagram of nVidia Tegra 3 SoC (Left) and Qualcomm Snapdragon 4 MSM8960 SoC (Right)

What is worth noting is that Nvidia’s platform contains only the processing components of
the SoC, that is the CPU, GPU, memory controller, video -audio encoders and decoders, and output
streams. Qualcomm’s SoC however, managed to integrate various other e lements as well, such as
GPS, radio data modems, Wireless Antennas and modules, etc. The main reason for this is

Qualcomm’s advanced 28nm manufacturing process, while Nvidia still used a 40nm lithography at
the time. Since the latt er’s SoC was still among its first forays into mobile processing, it couldn’t yet
compete in power efficiency. Instead, Nvidia used its experience as one of the world’s largest
manufacturers of desktop and server Graphical Processing Units, to design a mob ile SoC that is still
decently efficient, but also built from the grounds -up with graphical performance in mind. As such,
the Tegra line of SoC’s have been mostly used on devices where battery life can be compromised in
favor of increased performance – android and windows tablets.
As mentioned before, the main two architectures used in SoC manufacturing have remained
largely unchanged, the ARM and x86 architectures, with the former dominating the mobile SoC
market. It did not, however, start as mobile syste m. Instead, the ARM architecture was initially
designed to be used in a PC, specifically the Acorn Archimedes. When this device was released, the
ARM2 processor it had installed – capable of using up to 4MB of RAM and 20MB hard drive storage
– contained a comparatively low number of transistors, making the system impressively simple. It
had 30000, while the competing processor from Motorola sported more than double this amount, at
68000. Besides the low transistor count, the ARM processor was also designed to use a different,
simpler instruction set, which would evolve to define the RISC (Reduced Instruction Set Computer)
architecture. All of this made ARM’s processor so efficient that it was able to outperform the 80286
from Intel while using less power.
The other architecture, the x86, had its name coined from the family of processors Intel
launched since 1978, all starting with the 16 -bit 8086 CPU. Presently, the x86 architecture is most
commonly 32 -bit and used in most personal computers. The main drawbac k of the architecture is that
because of its focus as mostly a desktop PC architecture, extreme breakthroughs in energy efficiency
were never successful – performance was always the sole desired element. As such, it was never able
to outperform the ARM arc hitecture in terms of performance/cost ratio , with the closest achie vement
being the Atom platform, which, although impressively efficient, lacks the power to compete with
ARM in raw performance.
The mobile SoC’s themselves are themselves broadly character ized by two things
specifically: the CPU (Central Processing Unit) and the GPU (Graphics Processing Unit).

i. The Graphics Processing Unit

In present day , a crucial component in any mobile SoC is the graphics processing unit, the
GPU. At the historical onset of SoC’s, the main task of the graphics card was rendering the 3D objects
and scenes, and projecting them onto the screen’s pixels. Presently however, GPU’s have grown to
be more and more central to the entire system. On one hand, their main job, tha t of screen rendering,
has moved beyond applications, and on Android systems it renders the entire user interface. On the
other, the GPU has intrinsically much more parallelism than the CPU, being designed from the
grounds up with many more cores in mind. Whilst not as universally powerful as its desktop
counterpart, modern mobile GPU’s do sport as much as 256 cores (in the case of Nvidia’s Tegra X1
chip) [14]. This native parallelism allows the GPU to receive certain thread -intensive tasks from the
CPU, thus giving the central processor the option to distribute the load better.
Among the first manufacturing lines of mobile GPU’s was the Mali , produced by ARM. A s
opposed to other mobile graphics units, this chip did not have an actual built -in display controller to
drive the monitor. Instead, the chip contained a dedicated 3D engine to process the graphical
rendering of 3D objects, scenes and effects (and, in the case of Android, the UI), and offload it into
the memory. While still maintaining a few models found in certain low to mid -range mobile devices,
the Mali has mostly been overshadowed in by its competitors. They have however undergone a
resurgence in recen t years thanks to Samsung, who paired a Mali GPU with their impressive

proprietary Exynos SoC on their flagship smartphones. This specific GPU, the T880MP12 , is Mali’s
singular presence on high -end devices, but it has been successful enough to compete agai nst
Qualcomm’s leading market SoC. [15]

Fig. 3 – GFX Benchmark 3.1 Manhattan Test of various devices, showing Exynos’s Mali GPU keeping up with market
leader Qualcomm S820.

Another early entran t in the mobile GPU market was Imagination Technologies’ PowerVR .
While having a strong lead at the beginning, it has since dropped to mostly certain low -end device,
focusing on low powered media chips. Unlike Mali however, PowerVR GPU’s aren’t actually
manufactured by PowerVR themselves. Instead, their design and patents are being licensed to other
companies like Intel, Samsung, Apple, etc. [13] Currently, the only high -performance PowerVR chip
is manufactured by Apple and used on their Iphone devices’ SoC.
Perhaps the most well -known mobile GPU remains industry leader Qualcomm’s Adreno.
Originally branded as Imageon , it was developed by ATI as far back as 2002 to be used in handheld
and mobile devices. After AMD’s acquisition of ATI in late 2006, it was rebranded as ADM
Imageon, only to be officially discontinued in 2008 due to AMD’s internal restructuring and compan y
problems. It was then finally bought by Qualcomm in late 2008 at the price of $64 million. Since
AMD still retained the preceding branding, Qualcomm change the chipset’s name to Adreno. The
GPU has since been the official integrated GPU in Qualcomm’s ser ies of mobile SoC’ s. In recent
years the Adreno line has seen massive advancements in hardware and software technology, with
Qualcomm aiming to bridge the gap between desktop and mobile graphics, while at the same time
striving to transition the GPU from a purely graphical drive, to a general purpose processor capable
of heavy parallelism. Key imaging and multimedia factors such as 4K recording, high framerate UI
and screen capture, decoding and encoding of high data streams, are all capable of using this t ype of
processing. [16]

Fig. 4 – History and Evolution of Qualcomm’s Adreno GPU [16]

Adreno’s 400 series brought even more improvements to the chip, especially addressing this
API transition. It was the first Qualcomm GPU to support graphics API’s DirectX 11.2, OpenGL ES
3.1, while also employing Google’s new AEP (Android Extension Pack). This extension enables
support for ASTC texture compression, compute and geometry shaders and hardware tessel lation, all
of which represent as of yet PC -specific techniques.

Fig. 4 – Adreno 400 series technical improvements over its predecessors [16]

Most notable is OpenCL 1.2 Full profile support, alongside Microsoft’s DirectCompute API,
which sets to further advance the GPU’s role as a general purpose processor. In terms of API’s, the
400 series has also improved RenderScript acceleration over its preceding 300 line.
Another area to be improved was the texturing perform ance, which received anisotropic
filtering support for higher levels, while maintaining a low energy footprint. Support for ASTC
(Adaptive Scalable Texture Compression) also improves the level of detail and overall texture quality

while keeping the same pe rformance levels. To aid this increase in texture capacity, Qualcomm has
increased the texture cache sizes as well, and the general purpose L2 cache.
Lastly, the ROP’s (Render Output Processors), have received performance enhancements and
polish. These ele ments are tasked with the final calculation of scene and object pixels and projecting
onto the screen. The Z stencil is a buffer used to manage image depth coordinates (as an object is
rendered, the buffer stores the depth of the generated pixel, the z coo rdinate). [17] This area has been
improved, allowing for faster depth rejection which lowers the number of pixels the GPU must
compute to render and draw any particular scene and in turn removing unused, hidden regions from
the pipeline. [16]
Qualcomm’s upcoming 500 series is expected to increase Adreno’s power even more. Barely
released and featured only on select mobile smartphones, the Adreno 530 pushed graphical
performance much further than its p redecessor. As seen below, the new GPU doubles the 430’s
performance. Even more interesting is the fact that the integrated SoC GPU is starting to match and
even outperform desktop -grade integrated GPU’s, like intel’s HD 520.

Fig. 5 – GFX 3.1 Manhattan (1080p offscreen) [15] Comparison Test (Left) and GFXBench 3.0 – Manhattan Offscreen OGL Off
Screen [18] Comparison Test (Right)

The 530 Adreno GPU is clocked at 624 Mhz and in terms of API’s, supports DirectX 11.1,
OpenGL ES 3.1 AEP, OpenCL 2.0, Direct3D 11.1. It also boasts the introduction of the Vulkan API
to mobile devices, allowing the rendering and execution of desktop -grade graphics programs, on a
Snapdragon 820 e quipped device. [18]
The last contender in the Android mobile GPU market is Nvidia’s famous Tegra X1
“Superchip”. The Tegra line was first announced and released within 2008, with its first chips mainly
aimed at smartbooks, smart media devices and general mobile internet devices, and only tentatively
at smartphones (they lacked their competitor’s power efficiency). [19] Eventually, in 2009, Nvidia
started supporting Android as an OS to run on Tegra and unveiled the first Android -specific Tegra,
the 250, in 2010. Its next iteration, the Tegra3, ventured further than mobile devices and was used in
Audi’s in -vehicle information and digital instruments displays in its entire line of cars since 2013.
The first to establish Nvidia’s chip as an Android powerhouse was the Tegra K1, which powered
both Nvidia’s proprietary Android devices, and the Nexus 9 Android tablet, all of which have
exhibited massive performance gains over their competing products.
The current chip, the Tegra X1, is set to overthrow the competing Android graphics SoC’s
once again. First and foremost, the “superchip” is the first Android GPU to provide a staggering 256
computational cores (branded CUDA cores) as well as using the company’ s proprietary desktop
architecture, the Maxwell architecture. [20] Compared to its predecessor, the X1 features support for
OpenGL 4.5, DirectX 12, AEP and CUDA 6.0 (their proprietary development environment [21]).
Where the chip impresses the most is its processing powering, being capable of over 1000 GFLOPS
for 16 -bit operation workloads, and more than 500 GFLOPS in fp32 operations (floating point

operations). Not only is the X1 able to deliver twice t he raw performance and efficiency of the K1,
but it also marks the chip as the world’s first TeraFLOPS mobile processor.

Fig. 6 – Block Diagram of Tegra X1 Maxwell Architecture [20]

The Tegra X1 SoC distinguishes its architecture with the following key features:
• ARM Cortex big.LITTLE A57/A53 64/32 -bit CPU architecture, used in most high –
end devices due to its high performance while maintaining low power consumption.
• Maxwell GPU architecture, c oupled with 256 cores.
• End-to-end 4k 60 fps pipeline , capable of decoding H.265 and VP9 streams in 4K,
60fps
• 20nm Lithography Process , a significant reduction from the K1 line.
What is interesting to note is the choice of investing development effort into the high
performance pipeline. While 4K displays are far from mainstream, especially so regarding mobile
Android devices, it is nonetheless the next evolutionary step regarding screen resolution. Full 4K
adoption is a significant distance away, more so whe n taking into account the adoption rate of FullHD
resolution, which is still competing against HD screens. A cautious and bold move at the same time,
Nvidia opted to architect their high performance, end -to-end 4k@60fps pipeline so it may be used
on genera l streaming services such as Youtube, Netflix, Amazon Now, Twitch, communication
services such as Google Hangouts, and to enable 4K screen casting with Google proprietary
Chromecast protocol. To achieve the desired 60 frames per second on this high resolut ion, Nvidia
has optimized most of its components specifically for this, from the high speed storage and memory
controllers, to the image signal and graphics processors, and video decoders. This is significant, as
to date no other mobile graphics processor has managed to produce 60 frames per second in 4K
streaming. Those that are even capable of 4K streaming are locked on 30 fps. [20]

Fig. 7 – Block Diagram Representing X1’s High Performance Video Pipeline [20]

ii. The Central Processing Unit and SoC’s as a Whole

In terms of CPU’s, disregarding the Chinese market, there are almost exclusively only two
SoC’s to use completely different architectures. The first of them, industry and market leader, is
Qualcomm ’s Snapdragon line. The first devices to contain this SoC were released in 2009, with
Qualcomm gradually gaining market momentum, culminating in 2014 when Android phones have
started using the company’s Snapdragon SoC almost exclusively.
The Snapdragon uses Qualcomm’s proprietary CPU design, the current iteration of which is
codenamed Kryo, present in their 820 SoC. The company has managed to drastically improve the
performance over its predecessor, the 810, going as far as marketing a nea r double performance and
efficiency. This is achieved due to the new 14nm architectural lithography and general improvements
across the board. The new chip also contains several proprietary components, such as the X12 LTE
modem, the Hexagon DSP (Digital Si gnal Processor) and Spectra ISP (Image Signal Processo r). The
64-bit Kryo CPU is clocked at 2.2Ghz and contains 4 cores, as opposed to its predecessor’s 8 cores
– Qualcomm’s claims are that the majority of Android apps still aren’ t optimized for true multi -core
processing, and so the core reduction won’t affect performance. [22]

Fig. 8 – Qualcomm Snapdragon 820 Marketed Improvements [22]

They elaborate that “The most important thing to have is peak single -threaded performance,
as most of the time only one or two cores are active.” Moreover, “When most phones are playing
games, web browsing, or just word processing, usually only 1.5 cores are active at any one time”.
[22]
Regarding connectivity, Snapdragon’s 820’s X12 LTE modem further boosts network
performance by adding Cat. 12 LTE support. This means that a device equipped with this SoC could
theoretically reach speeds of up to 600 Mbps download and 150 Mbps upload. Thi s represents a
significant improvement over its predecessor’s X10 modem, which is only capable of achieving 450
Mbps downlink and 50 Mbps uplink. Further future -proofing their design, Qualcomm also developed
the X12 as the first modem in the world to suppo rt LTE on unlicensed spectrum bands.
When talking about real world performance, the new chipset, while not quite reaching
Qualcomm’s claims of double performance over the 810, is still a massive improvement. The
following real -world benchmark tests provide relevant comparisons between the nascent chipset and
its predecessors.

Fig. 9 – Antutu (left) and 3DMark (right) scores comparing Snapdragon 820, 810 (Nexus 6P) and 808 (Nexus 5X) [22]

Antutu’s benchmark reveals Snapdragon 820 impressive performance, scoring it 54% higher
than the 810. In 3DMark’s Slightshot GPU -centric test, the 820 managed to score 34% more than the
810. A far cry from the touted double performance, but a significant improveme nt nonetheless.
Battery life is not so easily comparable, as there are no current smartphone’s to have similar
specifications in terms of screen and Android version, while sporting the 810 SoC on one hand, and
the 820 on the other. Having identical screens is mandatory as it is the most powerful battery drainer
in this mobile ecosystem, with as much as 40 -50% of power consumed. Identical Android version is
also ideal, as certain power management tweaks are being slowly implemented in each revision. Real –
life tests, with no empirical standard, haven’t left reviewers impressed. They have stated that while
performance is certainly adequate, and the phone will last through a day – the length of time which
has become the norm for a decent smartphone – it will not last significantly longer than that. [22]
Qualcomm is also priding themselves in their proprietary ISP (Image Sensor Processor), the
Spectra. It uses the latest 14 -bit image sensors and provides such features as hybrid autofocu s and
multi -sensor fusion algorithms. This allows the camera ISP to capture a vast range of colors, and,
most importantly, to make use of computational photography. The Spectra itself is accompanied by
an additional two ISP’s.
In terms of raw specifications, interesting details are the added support for high frequency –
1866Mhz – LPDDR4 RAM memory speed, the compatibility with both USB 3.0 and 2.0 and the Tri –
Band Wi -Fi support coupled with a 2×2 (2 -stream) MIMO configuration. [23]
A veritable contender of the market at the moment is Samsung’s Exynos line of SoC’s. While
the company is as of yet unable to mass produce enough of them to fill the order of Galaxy phones
(not to mention the various legal issues surrou nding the marketing of foreign design and
manufactured mobile SoC’s within the US border), and so still equips a significant portion of its
devices with Qualcomm SoC’s, its proprietary Exynos line has nevertheless continued to impress in
recent years. Deve loped to contest Qualcomm’s position as market leader, Samsung’s SoC is built
with increased efficiency as its goal. Indeed, as evidenced below, the latest Exynos 8890 cannot
outperform Qualcomm’s Snapdragon 820 in raw power [15]. It does, however, come dangerously
close to it.

Fig. 10 – Antutu Benchmark Comparison of Various Mobile Devices [15]

Exynos’s edge comes from its 8 -core CPU design and ARM’s big.LITTLE paradigm. The
central idea is pairing high -power cores with low -energy ones in order to distribute the load as
efficiently as possible. This allows SoC to deliver increased parallel processing performance, while
maintaining low average power consumption. ARM also designed the needed software to manage all
the tasks and load them to the appropriate core based on their performance needs (the big.LITTLE
MP). [24] This is what allows the Exynos SoC to achieve its impressive power eff iciency.
Additionally, the 8 -cores allow Samsung’s SoC to outperform Qualcomm in a true multiprocess
environment.

Fig. 11 – GeekBench 3 (Multicore) Performance Comparison [15]

It is however important to note, that according to market competitor Qualcomm, true 8 –
threaded optimization is near to non -existent in Android, and x8 multicore performance benchmarks
are uncharacteristic of real -life experience.
While Samsung’s Exynos 88 90 – codenamed Exynos 8 Octa – uses, as mentioned before,
ARM’s big.LITTLE design, it redesigned half of the standard processors. The 4 high -power cores
are in fact custom -designed by Samsung based on the 64 -bit ARMv8 architecture. The company
claims they provide 30% improvement in performance, while also increasing power efficiency by
10%, compared to its predecessor – the Exynos 7 Octa. In order to fully utilize the benefits of the
big.LITTLE system, Samsung also developed their own SCI technology (Samsun g Coherent
Interconnect), which allows full cache -coherency between the Cortex -A53 cores – the standard cores
–, and their proprietary custom cores. [25]

Fig. 12 – Samsung’s big.LITTLE design, employing their SCI technology. [25]

The Exynos 8 is manufactured under the same 14nm lithography as Qualcomm’s 820.
Samsung’s device however uses the 2nd generation FinFET LPP (Low -Power Plus) technology.
Specific t o the FinFET transistor is the placement of the gate on multiple sides of each source and
drain, allowing increased effectiveness on current leakage control. Furthermore, carriers are now able
to move across the various surfaces of the fins -shaped 3D struc ture in the transistor. This all
purportedly leads to much faster computational speeds and significant improvements in performance
and efficiency.

Fig. 13 – Visual construction comparison between conventional FET transistor, having a 2D planar Struc ture (Left) and
the FinFET transistor, having a 3D fins -structure (Right) [25]

In terms of connectivity, the Exynos 8 sports the same performance as its Qualcomm rival,
Category 12/13 LTE modem, capable of 600Mbps download speed and 150Mbps uplink speed. Other
similarities include the high -speed RAM support and the supported 4K display resolutions.
All things considere d, the two most powerful mainstream SoC vendors at the moment are
surprisingly similar in performance and power efficiency, with differences of at most 10% in key
areas. Should Samsung deem it worthwhile to invest in mass producing their Exynos chipset, th ey
may very well completely abandon Qualcomm’s solution, and in doing so spark a much -needed
dichotomy in the Android mobile SoC market. While Nvidia’s solution is also present, at the moment
its focus remains on high -power, high -performance cases, staying clear of the mobile phone market.

2.1.2 Android Wear Smartwatches

The smartwatch is defined as a computerized wrist device, with much more functionalities
than merely keeping time. Certain early digital watches did indeed have the ability to perform various
basic tasks, such as rudimentary gaming, or had a built -in calculator, but the smartwatch tag denotes
a device more akin to a wearable computer, able to be programmed with new capabilities, as well as
having true connectivity with other smart devices. As such, the term has come to be synonymous
with touch screen enabled watches, having such peripherals as accelerometers, compasses,
thermometers, heart -rate readers, speakers, even cameras or GPS antennas. Their programmable
software should also support appl ications like media players, schedulers and personal calendars or
digital maps , as well as ways to interact with the watch’s various sensors . Currently, a method to
connect to a personal smartphone is also seen as mandatory for a smartwatch. Most, if not a ll, use a
Bluetooth connection to establish synchronization between the two devices, but some are also
capable of Wi -Fi, GPS, or even radio communication.
A subsection of smartwatches has been specialized on sports features and have been
universally denominated as “Sport Watches” or “Fitness Trackers”. These serve as either health or
running recorders. The latter use built -in GPS to enable position tracking before a workout. The user
starts the activity on the watch, proceeds to complete their workout , then uploads the activity to a
smart device, a smartphone or a computer. Their routes are thusly synchronized with the fitness
service of their choice and allows them to ascertain a broad idea on their performance. Advanced
features on these watches incl ude training programs (having a set of achievable milestones directly
on the watch to help maintain workout consistency), lap times (ability to recognize retreading on a
predetermined route and resetting the t imer), real -time speed display, integration and display of
health -specific sensors such as heart -rate or blood pressure, as well as multi -sport capabilities, such
as serving as a pressure/depth gouge for diving, or synchronizing itself with a cadence sensor, which
measures bicycle wheel revolutions per unit of time.
There are also certain hybrid watches that are composed of a traditional wristwatch body and
functionality, but do have the communication protocol and hardware to synchronize with a
smartphone. This is usually achieved through dedicated apps within the smartphone which perform
the user application exchange of data between the two devices. These watches can then receive alerts
from a smartphone and notify the user of such information as calls, missed calls or received SMS’s.
They are, however, usually more rudimentary than true smartwatches, and as such the integration
with the mobile device is usually restricted to non -OS specific tasks, i.e. the watch is only able to
display phone calls, SMS’s and alarms.

Fig. 14 – Comparison between the Sony Ericsson MBW -150 (Left), a hybrid watch that had a single line of amoled screen, capable
of display caller number/name or SMS received when paired with a phone, and the Galaxy Gear S2 (Right)

Historically speaking, the first year to present a fully -functioning smartwatch, colloquially
known as the “year of the smartwatch”, was 2013. This is because, according to device analyst Avi
Greengart, of research firm Current Analysis, electronic compone nts had finally gotten small and
cheap enough to construct what technically amounted to a smaller, cheaper, smartphone. In that year,
a significant number of companies revealed that they were in development with smartwatch devices,
specifically: Toshiba, S ony, Samsung, Qualcomm, Microsoft, LG, Foxconn, Google, Blackberry,
Acer and Apple. [26] Early fears regarding such wearable devices, that still keep many manufacturers
from investing a sizable amount of development effort, were mainly the physical size of the
smartwatch itself – which would be significant with current technology – and the un iversal issue with
all portable electronics, the insufficient battery life. Other issues were the display technology, as LCD
would not allow the watch to function with its screen on constantly, or it would drain the battery
dramatically faster. The only te chnology to allow a reduced power mode was OLED. This is because
the LCD, by design, is powered by a backlight spanning the entire screen, so at any given time, if the
screen is turned on, the entirety of it would consume energy. Conversely, an OLED displa y has all
its pixels composed as individual organic LED’s, able to turn them on or off one at a time. This would
allow a rudimentary display of a fraction of all the pixels to show the time, or any other significant
information, while most of them would be turned off to save power.
2014 saw the actual large release of several smartwatches from various producers, as well as
the mainstream software adoption of what would become one of the largest competitors on the
smartwatch OS market: the Android Wear. The OS itself is an extension of Android’s environment,
and as such is restricted by the same hardware limitations and necessities. Notably, it requires either
a 32-bit ARM, x86, or MIPS platform – only the former of which having been actually used in this
situation. While peripheral requirements are rather lax, all Wear watches support Bluetooth
connectivity with a smartphone, and in fact require this synchronization for advanced functionalities.
Wi-Fi is supported on many devices, but is secondary to the Blu etooth connection.
The first watch to operate on the Android Wear platform was Motorola’s Moto 360 in 2014.
As this was not only the company’s first foray into wearable technology, but also Google’s first real
case – and more or less its proof of concept – of Wear OS, hardware specifications on the SoC side
were less than stellar. The operating system was run on a Texas Instruments OMAP SoC, using a
1Ghz single -core Cortex A8 processor. [27] The watch was also powered by a 320mA h battery,
which would last roughly around 12 -16 hours of use.

Fig. 15 – Block Diagram of the Qualcomm Snapdragon 400 SoC, described below. [28]

Currently, almost all Android Wear smartwatches are built on the Qualcomm Snapdragon
400 MSM8926 platform. Specifics of this SoC include a 32 -bit ARM Cortex -A7 processor, having

4 cores running at 1.2Ghz frequency, and the low -end, low -power Adreno 305 graphics processing
unit. The usage of this specific SoC is due to its relati vely cheap production costs, as well as its
considerably efficient processing. The SoC itself has a Digital Signal Processor capable of utilizing
mobile broadband signals, but few watches support mobile connectivity.
In terms of displays, as stated previou sly, most current Watches have been designed with an
OLED -type display, either P -OLED (Polymer -OLED) or AMOLED (active -matrix OLED) .
Although some still use the classic LCD panel, due to it being significantly cheaper, most agree that
a staple feature of a watch should be to have a permanent rudimentary display so as to easily glance
information. Since LCD’s consume just as much power, regardless of what is shown on screen,
having an always -on mode drains the battery massively. As such, although the option within the
Android Wear exists, the so -called ‘ambient mode’ is not encouraged by manufacturers of
smartwatches with LCD displays. Those that chose not to compromise in this aspect, and have
implemented an OLED display, bear no such issues, with the observ ation that they encourage
watchface developers to incorporate low -detail, mono -chromatic faces in always -on mode.

2.1.3 Web Server – Hosting and Physical Considerations

Whenever an individual or a company develops a web app or a website, the next step is
making it accessible to users around the world, through the World Wide Web. This is done via a web
hosting service, which is a type of internet hosting service that manages a server – either owned by a
hosting company, to be leased to the client, or owned by the web developer’s company itself – capable
of holding and running the required software and web application.
The server’s primary function is therefore to store, process, and deliver web pages in response
to client queries. This delivery is done using HTTP (Hypertext Transfer Protocol), but the data itself,
although generally HTML documents, can be in any number of formats, from images, to scripts, to
hard data. This entire operation is initiated by a client, a user agent, usually a web browser, by maki ng
a request on the World Wide Web via HTTP, to the website’s known Domain Name. This domain
name is the site’s recognized and official address on the internet, and is held and authorized by a
Registrar, a company, organization or commercial entity special ized in the management and
reservation of such Internet domain names. When the client calls the site’s domain name, the request
is picked up by a DNS service (Domain Name System), which is either provided directly by the
domain name registrar, or an indepe ndent entity authorized to host DNS records by an official
registrar. This service has the task to pick up the requested domain name, and resolve its digital
address in the form of an IP address, an Internet Protocol address. This is the logical designatio n
describing the actual location within the internet of the requested website. The client then has the
information required to find and communicate directly to the desired server, and it in turn receives
the client’s logical IP address so the communication can work both ways.

Fig. 16 – Diagram displaying the basic elements tasked with completing client -to-website communication. [29]

The web server itself is practically a computer that processes these HTTP requests and
respons es. Generally, the term is used to refer to both the hardware appliance and the underlying
software or operating system that supports the website/web application. [30] Loosely speaking, a
web server can be designed out of an ordinary home PC, but with numerous caveats, significant of
which are that firstly it needs to be up and running constantly and consistently, and second that it
needs to be monitored regularly for i ssues. Furthermore, the hardware requirements for full -fledged
web servers are generally higher than what an average home computer can supply.
As such, there are certain considerations that should be taken into account when designing
and deploying a physic al web server. First of all, it is important to note that there are no hard
requirements for hosting a website, as there each website consumes as much resources as it needs to
do its job and service all the connecting clients. As such, a rough idea of the managed traffic can save

a lot of time, money and effort into designing the ideal server. Specifically, the two major metrics
are client requests per unit of time, and connection bandwidth. A server needs to ensure that HTTP
requests are managed within a m inimum timeframe, while maintaining a decent bandwidth for the
desired data to be transferred. [31]
These physical requirements revolve mostly around the same areas that define a personal
computer: RAM, CPU and Storage Media. A lthough progress is being made to adapt a GPU to
general purpose processing owing to its massive parallelism, web hosting is not considered an
adequate recipient of such investment yet, as it does not have inherent multi -threaded tasking in the
order of hu ndreds of threads. An interesting and specific technique used in highly intensive servers
to increase performance is implementing a Multiprocessor System. Certain manufacturers produce
specialized motherboards that contain two or more CPU sockets, as oppos ed to conventional
motherboards which support only one. This permits the use of dedicated cache memories for all
processors, allowing for maximum performance, in contrast to purely multi -core/multi -threaded
systems. The drawback is that the software must a lso be designed to take advantage of multiple
CPU’s.

Fig. 17 – Graphical Layout of Dual -CPU Motherboard (Left) and Basic Block Diagram of Symmetric Multiprocessor System
(Right) [32] [33]

CPU and memory go hand in hand in server systems, as there are specialized forms of both
to be used in high -endurance environments where faults need to be minimized. A specific type of
memory is used, called EEC memory (Error -correcting code memory), that has the capability to
detect and correct the usual kinds of internal data corruption. This type of memory can therefore
prevent or at least significantly reduce the number of crashes due to memory errors, a very important
factor when considering mandatory permanent uptime. The main downsides are slightly lower
performance, due to the memory controllers time needed to perform error checking, and the
memory’s higher costs, due in part to the additional required hardware, and in part to the lower
manufacturing volume for such a component (since they are only used in specialized environments).
Furthermore, this type of memory requires specialized components on the CPU controller, present
only in Intel Xeon processor line.
The Xeon itself is Intel’s brand of microprocessors designed and marketed specifically at non –
consumer environments, such as workstations, servers and embedded systems. Besides their support
for EEC memory, these processors differ from their mainstream counterparts in their support for
multi -socket systems as well as much higher core counts. This makes them ideal for multi -task,
highly parallel workspaces.
Recent Xeon models have also placed heavy emphasis on security features. These include the
so-called “Intelligent Orchestration”, which supp orts cache and bandwidth monitoring to aid IT

specialists in providing more reliable service levels, as well as improved, high -performance
encryption, with a purported up -to 70% increase in per -core performance on encryption algorithms
[34] – this potentially allows practically transparent protection of data on workload transmission.
Furthermore, various software and hardware technologies have been implemented to prevent stealthy
malware and zero day attacks. These techniques on part employ privileged access in order to restrict
platform resources to legitimate processes, and on the other hand provide the support for new security
implementations that use deep memory monitoring.
In terms of performance, Xeon processor distinguish them selves through massive parallelism
when compared to Intel’s desktop counterparts, sporting as many as 24 cores – all the while
employing Hyper -Threading, so boosting the number to 48 threads – and as much as 60MB of
memory per cache per socket (compared to 8MB of c ache on Intel’s top of the line i7 -6700K
consumer processor). They also permit up to 24TB of memory per 8 -socket system, compared to a
maximum of 64GB of RAM on the aforementioned 6700K Skylake processor. In terms of sockets,
current Xeon processors are th e only existing processors to support up to 32 sockets on an individual
workstation, adding to a potentially massive thread count of 1536 .

2.2 Software

This chapter refers to the software aspects of all platforms involved, specifically to the entire
Androi d ecosystem, as well as the software on the server side.

2.2.1 Android OS Concepts and Paradigms

Even though the Android operating system is currently widely used in a multitude of devices,
from TV setup boxes, to cars’ infosystem, to even amateur robot development kits, it did start with
nothing but smartphones in mind, focusing solely on the touchscreen as device interaction. This type
of user interaction is designed to be intuitive, imitating real world direct manipulation gestures, such
as swiping obj ects, tapping on interactive buttons or pinching the screen to magnify or reduce in size.
Discrete character input is also implemented through a touch virtual keyboard.
Historically speaking, the Android system was in production for a very long time, with the
original team starting their work as back as 2003. Two years later Google acquired the company and,
although leaving the original team on board, it spearheaded the project in order to compete with
Nokia’s Symbian OS and Microsoft Windows Mobile. [35] The first Android smartphone was
released in 2007 without much fanfare, as the world had already been impressed by Apple’s recently
released iPhone, but nearly 10 years later Google’s OS has managed to obtain nearly 80% of the
global smartphone mobile market. [36]
A staple of the Android operating system is its open source nature. Even though most Android
devices are indeed, shipped in the end with a mixture of open and proprietary software and
applica tions – most specifically, Google’s proprietary services [37] –, the OS source code itself is
free and released on the internet. Owing to this, the system is very popular with tech companies that
wish to utilize an already deve loped, low -cost and fully customizable operating system, either to keep
costs down globally on high -tech projects, or in order to inject a cheap device into a low -income
market. The downside to its completely open and customizable nature, is the lack of a centralized
updating system. Since each manufacturer can and does modify their version of Android, Google
cannot publish specific updates to each variation of their operating system. As such, many Android
devices are left behind in terms of security update s, with even high -end recent models having late
security patches. In 2015, research concluded that nearly 90% of all Android smartphones retained
publicly known but unpatched security vulnerabilities because of their respective manufacturers’ lack
of secur ity updates and support. [38] [39]
Regarding the User Interface , as stated above, Android’s is based principally on direct
manipulation, that is the implementation of touch inputs that simulate real -world actual gestures.
These include actions like swiping, tapping or pinching the screen, each with an effect produced to
most closely match realit y, that is swiping actions generally move parts/objects within the UI, tapping
interacts with button -like elements, and pinching in or out enlarges or reduces in size the object being
manipulated. [40] Since the OS can often be viewed as a full -fledged PC operating system,
integration with external, physical input peripherals like game controllers, actual keyboards or mice,
is abundant and supported via Bluetooth or USB. The device’s internal hardware is also designed to
offer re sponsive user feedback, either haptic, through its vibration motor, or through interface
modification in response to its various sensors.
The device homescreen is the UI hub, akin to a Windows machine’s desktop. It is the central
and ‘home’ location in the entire interfaces, and is commonly populated by widgets and app icons,
all of which are entirely customizable by the user. The icons themselves point to the specific app and
launch it, analogous to program shortcuts on a Windows PC, while widgets present real-time, auto –
updating content, such as news, weather or messages. [41] This general layout however is so heavily

customizable, that most companies dealing in android devices choose to significantly modify how it
looks and navi gates in order to distinguish themselves from their competitors.
Another universal element of the Android user interface is the status and notification bar, at
the top of the screen. This is the primary node for delivering information updates to the user w ithout
inconveniencing them. The bar itself remains compact, with occasional flags detailing live
notifications, until pulled down by the user. Executing this gesture reveals the full notification screen,
detailing the collected app updates and notificatio ns received that the user has not yet responded to.
The major functionalities of the device however come from the execution of programmed
Applications , or “apps”. These are the Android analog of Windows’s programs; they are
programmable entities written by developers using Android’s SDK (Software Development Kit) to
achieve specific tasks. The SDK itself is a bundle of all needed development tools , including
debuggers, libraries, device emulators, as well as tutorials, documentation and sample codes. The
main and official IDE (integrated development environment) for Android’s SDK is currently Android
Studio. This is a PC program – supported by all major operating systems – that integrates the SDK
while supplying a graphical user interface to the programmer, in order to provide the optimum
environment for application development.
The apps themselves are most often written using a combination of XML elements (for
graphical representation of objects) and Java programming language (for the apps internal logical
computing). Certain other languages can be implemented, such as C/C++ and Go, but these usually
come with restricted access to the system’s API’s (Application Programming Interface).
The primary and only official nexus for acquiring Android apps is the Google Play Store.
This is an app itself, and is part of Google’s proprietary set of services, all licensed under the ‘Google
Mobile Services’ software. Because of this, the use of the P lay Store is only officially allowed on
devices licensed by Google, and is therefore unsupported on custom android variants. The store
allows the browsing and download of applications, as well as background updating, providing
increased quality of life ove r sideloading apps. The store also implements regulations regarding the
distributed apps, in the hopes of protecting against malicious apps. Regardless, due to Android’s open
source nature, third -party marketplaces exist, providing unregulated, unofficial applications. Some
of these have the sole purpose to replace the Play Store on unlicensed Android devices, whilst others
distribute applicat ions that specifically violate various policies and so cannot be submitted to the Play
Store.
Regarding the Play Store’s security functions, it is worth noting that Google employs a
proprietary automate antivirus and antimalware system called the Google Bo uncer, to verify each
app at submission. [42] Recently, they have implemented the use of deep neural networks to create
a virtual intelligence capable of recognizing malicious software within the apps, malware that would
escape a conventional antivirus. While the VI system is still new, Google is investing significantly
in helping it learn, feeding it known problems and malware so it can have a database with which to
compare each new submission. [43]
Android’s system core itself, the kernel, is based on the Linux kernel, starting from version
2.6.25 implemented within the first iteration of the mobile OS. [44] It has, however, brought many
significant changes to it along th e years, leading to some disputes between Google and linux
developers, as the former did not show what was thought as a decent effort to implement these
android changes and features back into linux. Some of them were ported, such as the autosleep and
wakel ock capabilities, but it took several attempts. A notable difference between the two kernel
series, is that unlike Linux, the Android system restricts access to certain sensitive disk partitions,
such as the “/system” one, in essence not giving users root access. Still, vulnerabilities can be
exploited to obtain root access on virtually any Android smartphone, and is indeed the process by
which open -source communities alter and experiment with various Android features within the

system and kernel, in the ho pes of improving some of them. [45] Linux itself was chosen as a base
kernel owing to its superior memory and process management, the ease with which multi -user, multi –
level security restrictions and instances could be implemented, as well as its already open source
nature and massive library sharing communities. [46]
While built on top a linux kernel, the Android system itself represents the various superior
layers in the stack, libraries and API’s, standalone application features as well as the middleware
itself, the entire level between the kernel and applications. All of this is in essence Android’s
development, as the linux kernel itself is worked on independently.

Fig. 2.2 .1-1 – Android Architecture Diagram, displaying its software stack. [46]

The execution of Java is done in a virtual machine, which used to be Dalvik prior to Android
version 5.0. Specific to this process virtual machine was its trace -based JIT (just -in-time) type
compilation , which actively reads and analyzes the code, then translating it while the application
itself is still executing. [47] This was changed to a AOT (ahead -of-time) compilation between
Android 4.4 and Android 5.0 when Google started introducing the Android Runtime (ART) as the
default virtual runtime machine. This new type of compilation gives up the transl ating of code mid –
app, and instead it pre -compiles the entire bytecode at app install, essentially transforming android
runtime application into native executables. [48]
The libraries layer represents the specific Java librarie s used by the Android system. These
have a format of “android.x”, where x represents the subject of work that the library deals with. For
example, the core library is android.app and supplies the access to the entire Android development
model. Other notabl e libraries are android.content, android.opengl, android.os, etc. each used for
various accesses or construction blocks. [49]
The next layer, the Application Framework, represents the various service and tools that
manage the entire running of any application. These run natively in the background, but developers
are also permitted to call and access them for additional functional ities within the app. Certain core
services are the following [49]:
• Activity Manager – roughly the most important element in the entire layer, it
provides management for the whole application lifecyle, in essence controlling
the application and enabling it to run.
• Resource Manager – second -most important, this manager allows developers
to access the system resources, which represent virtually everything apart from

the java code. Since java is only the background coding, and an An droid app
actually uses XML files to visually populate the screen, these also fall into the
resource category.
• View System – the manager that provides the UI elements to be used inside
the XML files in order to display graphical elements.
The final layer, at the highest level, represents the entirety of applications running on the
Android device, offering the entire functionality and user interface (t he homepage itself is an app).
What is interesting regarding Android application is their runtime environmen t. It was mentioned
before that among the the most important aspects of Linux to be taken into consideration when
choosing the kernel, was its support for multi -user environments. This is because the Android system
uses the kernel in such a way that each a pplication is, as far as the kernel is concerned, a different
user. Each of these users is given a unique ID, which is used to identify the application itself, and
then the kernel employs this ID to give access to the mandatory files only to their respecti ve
application. Furthermore, since they are, in essence, linux users, each application is permitted to, and
does run within its own virtual machine, isolated from all the other apps. All of these allows Android
to create a secure enough environment in whic h each process only has access to its own resources.
Several methods of file sharing exist, such as enabling two apps to use the same user ID, thus having
access to the same resources, or through the use of Intents, calls to other apps or services, which s hall
be discussed shortly. [50]
The applications themselves are each constructed around a combination of four components,
each with a different functionality, usage, lifecycle and most importantly, each existing
independently of each other, as a separate entity. These components are:
• Activities
• Services
• Content Providers
• Broadcast Receivers
Activities are represented by a single graphical user interface and its attached coding. Each section
in an app represents a solitary activity , with each activity paving the way to the next one if it requires
additional functionality. Activities can be started by other activities in other apps even, by use of Intents, for
example by taking a picture with the camera, and asking for it to be share d using the Facebook app. Any such
entity is a subclass of the Activity class. [50]
An activity’s status is mostly described by its current position in its lifecycle. This lifecycle
is a set of states that the system puts activit ies in using specific callback methods. It is most -often
visualized as a hierarchical step pyramid, with each step representing a different stage, each stage
being connected to the others through the various callback methods and having the top of the pyram id
the stage at which the activity is running on screen, having full priority and being open to be interacted
with by the user.

Fig. 2.1.1 -2 – Simplified diagram of the Activity lifecycle. [51]

The callback methods are used by the system to ensure that the activity can be dismantled
once the user has finished with it, as well as generally managing its state so it would not function
improperly such as:
• Causing a crash should another application be switched to the foreground, or should
the device receive a phone call.
• Losing the cached data or progress within the app if the user opens another app.
• Consuming system resources while delegated to the background.
• Losing data, progress or crashing, should the device’s screen rotate betw een portrait
or landscape.
Although there are 6 steps on the pyramid, an activity itself can only exist for an extended
period of time in 3 of them, the rest being transitionary states. These 3 static steps are the following:
• Resumed : sometimes called the “running” state, this is the stage in which the activity
is run in the foreground and is allowed to be interacted with by the user.
• Paused : a rather hybrid state, in this one the activity is only partially obscured by
another application or activity. This other must be in foreground and is only part ly
transparent, or contains pieces that do not completely cover the screen (a perfect
example would be Facebook’s Messenger app, which supports the usage of “chat
heads”, that is bubbles specific to each conversa tion that appear universally on top of
all other apps, and once interacted with, and so put in the foreground, act as an overlay
on top of the preceding app, but do not entirely cover it). This state stops the activity
in it from receiving user input, or e xecuting code.
• Stopped : this is the state of an activity once another has completely taken over the
foreground or the screen. The original activity is utterly hidden, invisible to the user
and is delegated to the background. While in this state, this activ ity does keep all of
its cached data, information and progress, however it is not allowed to execute any
code.
The other two steps within the activity lifecycle pyramid are transitionary ones . They are used
to get the activity ready to be put within the ma in three steps without causing crashes or losing
progress, but the activity is not designed to remain within these two steps. The first one, the
“onCreate()” is executed the moment the activity is launched, and it then immediately calls the
“onStart()” met hod, which itself then leads directly to the “onResume()”. These are all mostly
invisible to the user, and even though a developer has access to them and can modify instances of

them specifically for a certain activity, forcing an activity to remain within these states causes the
Android System to shut down the activity. [51]
As mentioned above, when an app is selected within the Android UI, the system executes the
“onCreate()” method specific to the activity that the app has designated the main activity, or the
launcher activity. This represents the gateway into that application’s user interface. Interestingly
enough, an application lacking these launcher or main activities will not populate Android’s App
Drawer and will be co mpletely invisible to the user. These activities are defined within the Android
manifest file, which shall be discussed shortly. [51]
Services are elements that are permitted to run in the background, in order to execute coding
operations designed to not stopped once an activity has been displaced from the foreground. Owing
to this, there is no user interface attached to a service. An example of such a component is any number
of applications designed to be able to save and run pro gress in the background, or any music player
that continues to play while the screen is turned off. [50]A service’s functionality is increased when
another component is bound to it, allowing the service to execute I/O operations, network exchanges
or interaction with any number of other entities, while still remaining in the background. [52] Just
like activities, a service is also able to exist in several states, these being:
• Started : designates the serv ice that is called by an active component of the application
through the “startService()” method. In this state, the service is meant to execute its
code in the background until its end, even should the activity or the entire application
that called it be destroyed. Once the service has finished its programmed task, it should
stop itself. If not, the Android system is designed to periodically clean its background
services in order to free up memory and prevent resource leakage.
• Bound : the state of the service once an active component calls it using the
“bindService()” method. This state opens the service to being interacted with by other
components, usually ac tive, such as requests and replies. IPC (Interprocess
Communication) allows t hem to do so even across multiple processes. Since the
bound service is a platform for the other component to run in the background, it will
only run until the activity bound to it will finish its program and end. When more than
one component is bound to a service, all of them must either unbind or be destroyed,
for the service to be discarded.
Several core metho ds are used to manage a service and handle its lifecycle. The
“onStartCommand()” method is the actual starter method, the way by which other active components
request the service to be started. The “onCreate()” method is then called by the system in order to
execute the start -up setup actions – in effect this happens after the “onStartCommand()” is called,
but the method is actually executed after th e “onCreate()” has finished its setup. The “bindService()”
method is used from within a different component, and is the way by which that component requests
to be attached to the service. When this method is called, the system calls and executes the “onBin d()”
method, similar to the “onCreate()”, to manage several setup processes before it allows the
“bindService()” method to actually run. The “onDestroy” method is called and executed by the
system when the service ends and it should be destroyed. Within ea ch service’s particular
implementation of this method, code can be executed in order to save the service’s progress.
A notable observation is that Android employs a memory management routine that scans and
destroys service if memory is low and the foregrou nd activity requires more of it. This works using
a hierarchy of priorities, with the system lowering a service’s priority step by step if no active
component interacted with it recently.
In terms of parent classes, a service can extend either the Service class or the IntentService
class – which is, itself, a subclass of Service. The Service class is the parent to all services, and most
of the time the class to be instantiated when a service is being programmed. IntentService is used to

respond to service s tart requests sequentially, easing implementation if the desired service is not
required to perform more than one request at the same time.

Fig. 2.1.1 -3 – Service State Diagram, showing the methods called to transition between states. [52]

Content Providers are Android’s way of managing application data and information. These can be
saved as files in system file tree itself, as an SQL database or various other medias that allow persistent data
storage. An application’s activities or other components can use a content provider in order to request access
to certain data. The content provider is then programmed to decide whether to answer the request with the
data, or deny access. Perhaps the most well -known content provider is the one tasked with handling users’
contact information. Any application wishing to query, modify or delete data related to contact information
must first call this specific content provider, which in turn will verify the app’s permissions and decide
whether to respond or not. [53]
The data itself is presented upon request and admission relational tables of structured information,
relaying different pieces of information for each instanced object requested. For example, as shown below,
the content provider containi ng data about the user dictionary saves the different spellings of uncommon
words that the user wishes to hold.

Fig. 2.1.1 -4 – Table held by content provider showing user dictionary data [53]

Broadcast Receivers are components specialized in listening and replying to broadcast call.
While many of these come from the system itself – common broadcasts include notification that the
screen turned off, power is low, or that the camera has taken a picture –, applicatio ns and active
components can also create broadcasts. This is usually in relation to other apps or components, to
announce that certain task s have been finished and that certain resources are now free to be used.

While broadcast receivers are akin to servic es in that they do not employ user interfaces, their nature
allows them to populate the notification center, if the broadcast is set to be announced to the user as
well. [50]
All broadcast s pertain to one of two broadcast classes . A “normal broadcast” is fully
asynchronous. This is a typical, general type of broadcast, as all receivers are executed in a random
order, many times even at the same time. While resulting in increased efficiency, this also means that
certain methods and API’s cannot pinpoint specific receivers. The second type is called “ordered
broadcast” and is represented by the delivery of broadcasts to one individual receiver at a time. This
allows the analysis of the result and the forwarding of it to various other receivers pertaining to other
components. [54]
Besides these four major application components, an Android app is composed of various
other classes and objects, such as views, layouts or fragments, each having a specific task to fulfill
in order to give the application all the functionality it requires. One of the most important objects
used is the Intent . This object is the first and foremost method with which activities or components
can request access or action from another component of the app. Generally speaking, an intent serves
one the following three key uses [55]:
• The Call and Execution of an Activity
• The Call and Execution of a Service
• The Delivery of a Broadcast
Since each activity is in effect a single screen in an application, as discussed above, it requires
a way to switch to another screen in order to present additional functionally. This is achieve d via
such an intent, which as an object is passed by the init ial activity, to call the “startActivity()” method,
in turn opening and executing the second activity. The intent itself is also able to pass any relevant
information towards the following activity. An intent is also used when starting and binding services ,
allowing the application to carry the data necessary for the service’s code execution. After the service
is finished, its result is also carried back to the main activity via another similar intent. [55]
Each Android applicatio n must also contain an Android Manifest file (name d
AndroidManifest.xml). This is an actual file in the app’s root directory which supplies the Android
system with all the necessary information to run the app. The file most importantly contains the
followi ng [56]:
• The application’s Java package name, which serves as a unique ID for the respective
app.
• Details regarding all of the app’s components described beforehand, where many
necessary settings for these components are set and saved.
• Information regarding the Android version used when developing the application as
well as the minimum such version required to run the app.
• Lists of all libraries used within the application.

2.2.2 Android Wear OS

Android Wear is Google’s official operating system for smartwatches. First announced as
recently as 2014, it is designed as an extension of the smartphone, delivering information and
allowing data and commands to flow both ways. [57] The OS integrates fitness as a core part of its
features, allowing for step count, GPS tracking and heartrate measurements. Since it’s designed from
the grounds -up as extending a smartphone’s control and interaction, while some manufacturers
implement cel lular support for their Wear smartwatches, the device still needs to be connected to a
smartphone for a complete feature set. [58]
The OS’s two main native implementations of communicating with a mobile smartphone are
the integ ration with Google Now, and the use of smart notifications. With Google Now, the user can
issue commands to the watch, either through a specific app interface, or globally, and the watch will
relay that information to its paired smartphone. [59] The other integral part is the watch’s use of the
original notification center on the smartphone itself. While the watch does use local notification, its
primary interaction with the phone is mirroring all notification alerts from it, an d presenting the user
with a few limited options with which to reply to those notifications. Increase d functionality can also
be implemented, giving exclusive actions to the watch regarding those notifications, that do not
appear on the smartphone. [60]

Fig. 2.2.2 -1 – Example of difference between the notification on a smartphone, and its mirrored implementation on the Android
Wear OS

Regarding the OS itself it is very important to note that it is built fully as an alternativ ely
styled Android OS. In essence this means that on the watch, runs a reduced, but fully functional,
Android OS, capable of theoretically running any app on the phone, since Wear OS is compatible
with all of Android’s libraries. The limitation is the hard ware, which is incapable of running many
high-performance tasks. [61]
Consequently, the primary differences between Wear apps (called “Wearable Apps” by
Google) and Android apps are the following [61]:
• Wearable apps must be reduced in size and functionality compared to their handheld
counterparts. App data should contain solely what is necessary for the app to function
on the device, and not to include superfluous details and actions. Extended proces sing
and code execution should be done on the handheld through the use of services, with
the Wear device’s sole contribution being the delivery and reception of data and
results.
• As of Wear version 1.5 , wearable apps are not downloadable directly into the watch,
instead designed as an extension to a full -fledged handheld app. The wear component
is installed automatically on the install of its “big sister”.

• While wearable apps technically have access to the entire android system libraries and
API’s, there so me that are off limits due to its limitations, chief amongst which being
android.webkit, as the watch completely lacks the hardware strength to browse
websites.
There are also software features specific to Wear devices, such as its use of Ambient mode.
Because the watch itself must be small enough to not be cumbersome and uncomfortable wrapped
around the hand and so it can only support a small battery capacity, it needs a mechanism to reduce
power drain. For this purpose, Google designed and implemented a s tate for the device to transition
to when it becomes idle, when the hand returns to a rested position through the typical gesture or
when covering the screen with the palm. For apps capable of such functionality (mainly watch faces,
i.e. the watch’s equiva lent of the Home application from a handheld), the two states are interactive
and ambient. Interactive permits the full usage of the device’s hardware platform, with complete
color range and graphically accelerated animations. Ambient mode shuts down the s creen brightness
to the bear minimum capacity, stops any input during this mode, as well as reducing the color range
to grayscale and disabling hardware acceleration. [61]
Communication between the Wear device and an Android ph one is generally performed
through the Data Layer, through a Bluetooth connection. The layer itself is an API supplied by
Google, through their Google Play Services, that enables access to the data exchange link between
the devices. Data can be sent back a nd forth through this connection using either the Wearable
Message API or the Wearable Data API. The Message API is built and optimized to share messages
containing single text strings up and down the protocol stack. When an app requires the transmission
of more complex data, this is usually encapsulated within a DataMap object. This object – which
contains a set of various data types, organized as key/value pairs – is used by the Data API to send
such information through the communication protocol. The obj ect itself moves across the stack in
the same manner as the message object. [62] [63]

Fig. 2.2.2 -2 – Diagram displaying the Wearable Message API [62] protocol stack (Left) and the Wearable Data API [63] protocol
stack (right)

2.2.3 Web Server Protocols and Communication

In terms of communication, the most widely used form of transporting information across the
network is the HTTP – Hypertext Transfer Protocol. The protocol itself is on the highest level, the
7th layer, on the OSI model, representing the Application level and employs mainly the TCP internet
transport protocol, although it can and has been adapted to be able to function on unreliable
transportation such as UDP packets – called HTTPU . It was designed first and foremost, and is still
widely used since its inc eption, for the distribution of hypermedia information. [64]
Historically, the first case of HTTP implementation was in the first test case for the World
Wide Web – notably, this first protocol version supported only one method, specifically GET, in
order to request a webpage. The protocol would go on to be published as a guideline in 1991 as
version 0.9, with the most widely spread version, 1.1, being complete and documented in 1999.
Recently, in 2015, a successor to this protoco l has been designed and released, namely the HTTP/2,
but it is still nascent. [64]
What makes HTTP ideal in a client -server environment is that it was designed from the
grounds up as a request -and-reply type of communication pro tocol. That is, the protocol functions by
having a client – a mobile phone application for example – submit an HTTP request to server across
the internet or network – a web hosting server for example. The latter then processes this request,
and depending w hat is asked, responds either with data and resource, such as web content in the form
of HTML files, or information in the form of another HTTP message, this time called a response
message.
Since the protocol is meant to be used on reliable network transmi ssion protocols, i.e. the
TCP, it requires a session called the HTTP session, represented as a closed set of request -and-
response transactions between the same client and server. The session is always started by the client,
who issues the first HTTP reques t, using a TCP connection to a certain port – most often the standard
internet HTTP ports of 80, 8080 or HTTPS port 443. The server then replies with an
acknowledgement message, followed by the requested information. [64] A part icular type of session
is started with an HTTP authentication scheme. These are already built mechanism by which the
server can challenge the user before delivering the requested information. Some authentication
schemes are Basic Access Authentication or D igest Access Authentication. [65]
As mentioned above, the main way by which the request -and-reply system works is using
methods. These are specially designed to represent an action that the client wishes to perform. The
first method, as stated before, was GET, followed by POST and HEAD in version 1.0, and finally by
OPTIONS, PUT, DELETE , TRACE, CONNECT in version 1.1 . What is important to note is that
although these are the official methods of HTTP communication, the protocol d oes not restrict the
definition and usage of custom methods, nor does it put a hard limit on the number of them. As such,
a client -server system can be developed to use any number of custom methods to suit the developer’s
needs. The official methods are as follows: [66] [67]
• GET : the primary method of HTTP, designed to request and retrieve hard
information. Data is delivered by way of objects called entities. The method can be
used conditionally, by way of a special header field called “If -Modified -Since”, which
requests that the information be supplied only if it has incurred changes since a
specified timeframe.
• HEAD : designed to provide a reply with the same headers as GET, but without its
body, providing efficient pieces of information.
• POST : used by the client itself to send a piece of data to the server. It is designed to
carry entities such as extensions to already present resources on the server side, or

even new resources or blocks of data. It is the primary method for the client to deliver
information to the server.
• OPTIONS : used by the client to request information related to what options for
communication the server has. In essence, this method demands a reply with the
available methods t hat the server is programmed to listen and respond to, but it can
also provide information about the server’s capabilities or its requirements.
• PUT : method by which the client declares a resources, and requests that server append
the data attached to the m essage to that resource. If the resource is not present on the
server side, it should be created and supplied with the data in the message.
• DELETE : this method is used by the client to provide the identifier for a resource
and then request that the specifi c resource be deleted from the server’s database.
• TRACE : used by a client to request an exact reply to his message, in order for it to
analyze the data as it is received by the server and how it was modified along the way.
• CONNECT : request by the client to switch the HTTP session from a web transaction,
to a SSL tunnel.
Regarding the actual programming of the server, among the most used forms of scripting, is
PHP. Originally an acronym for “Personal Home Page”, it currently stands f or “PHP: Hypertext
Preprocessor”, making it a recursive acronym. Its most distinctive feature is that unlike other scripting
protocols, PHP can easily be integrated and embedded right into HTML. As described earlier,
Android works by binding XML files, whi ch represent the graphical display, with java files,
representing the actual algorithmic programming. Unlike Android however, PHP defines itself as
having one single file, with lines of both HTML and PHP right between each other. [68]

Fig. 2.2.3 -1 – PHP scripting, showcasing its distinctive capability of being integrated within HTML lines of code. [68]

This allows PHP to offer a much more compact programming than other languages like C or
Perl, which rely on printing large amounts of HTML text in order to integrate programming logic
within web pages. Another useful trait of PHP is that the coding itself exists on the server, and
although it is written there between HTML text, the processing itself produces purely HTML content
(since the PHP coding is in effect the though -process of a server), thus delivering to the client no
information whatsoever regardi ng the server’s programming structure. [68]
Generally speaking, PHP is a wide -range programming language, capable of virtually any
task. Since it doesn’t necessarily need a server, but can function with simply a PHP parser, it can
work simply as a command line scripting platform, on either Linux or Windows, supporting easy to
build processing scripts. Moreover, due to its open nature, PHP also supports extensions which
heavily increase its functionality. There are even extens ions adding graphical libraries, allowing the

language to code actual desktop programs, complete with a graphical user interface. While not ideal,
nor the most efficient way, it is entirely possible. [69]
First and foremost, however, PHP is a server -side scripting language. A system like this
requires the aforementioned PHP parser to interpret the code as well as a dedicated web server to run
it. A client can then take the form of a web browser in order to access the server’s HTML output.
[69] PHP being as open as it is, bears no relevance to the operating system. It is run on a server
machine, like Apache, that can be installed on either Linux, Windows, Mac OS, or even a RISC OS.
While already mentioned that PHP can output purely HTML content, it is by no means limited by it,
capable of producing any number of file types, from PDF’s to images, to even video and audio data
generated live. In terms of database usage, PHP is capable of supporting most formats on the market,
including SQL, having s pecific extensions to deal with them.
In terms of the scripting itself, as evidenced by the previously attached figure, PHP delimits
its processing instructions by use of the “<?php” and “?>” key structures. The installed parser will
only interpret and exe cute code within these characters. This allows PHP to be inserted within web
coding, and still be recognized by the processing machine. [68] Specific to PHP is its use of variables.
Identified by the dollar sign, the languag e does not need a type to be specified for them, instead
instantiated as whatever their assigned value represents. This is through the use of “type hinting”,
which permits methods and functions to automatically assign their parameters as whatever their
coding requires. [70]
Regarding actual syntax, PHP is mostly similar to any other C -like programming language,
with specifics such as the “echo” command that outputs text, or the block comment delimiters “/*”
and “*/” respectivel y, as well as the line comment delimiter “//”. Logic and statements are ended by
semicolons, as the language interprets line breaks and new lines as whitespace and disregards them.
[71] [72]
Originally, PHP programming was composed of mainly two elements, variables and
functions. Variables have a dynamic data type, as mentioned above, being able to be easily converted
between different types, such as integers, float, even Boolean values. The latt er interpret zero values
as false, and anything else as true. Additionally, PHP supports the use of resource -type variables.
These represent all the special data types created by extensions , and so handled only by the specific
functions in those extensions . Examples include audio/video files or database values. [73] Functions
represent the methods themselves that perform logic operations, the same as any other programming
language. [74] Recently, support for object -oriented programming has also been added to PHP,
allowing it to create and manipulate objects, adding an additional level of programming to ease the
developer’s job.
Very important for PHP’s functionality is its support for we b frameworks, most importantly
the CakePHP open -source extension. Frameworks themselves are in essence a collection of libraries
and templates to ease the construction of various web applications and websites by providing all the
necessary tools already op timized for their specific tasks. Most of these frameworks utilize the MVC
(Model -view -controller) architecture, including CakePHP itself. [75]
This architecture itself represents a type of pattern used to implement user inte rface and
interaction on client -server systems, originally used as a guideline for most desktop programs, but
currently extended to websites and web applications. To simplify the entire transaction, it separates
the server system into several components, e ach designed with a different task to perform. [75]
Traditionally, the MVC architecture splits the server into three components, listed as follows:
• Model : the core of the application, contains its inner programming language. As such,
it is the one responsible for the direct manipulation and management of data.

• View : somewhat similar to Android views, this represents the actual building blocks
of the graphical user interface, ranging from text, to images, to more complex charts
and graphical data.
• Controller : the transparent interaction between the user and the server, it receives
input from the client, translates it and forwards it to the model.

Fig. 2.2.3 -2 – Basic diagram of the MVC architecture. [76]

As stated beforehand, CakePHP is one such framework built around the MVC architecture
and written, naturally, in PHP. Originally developed by programmer Michal Tatarynowicz in 2005
as a simple application extension within PHP, due to its open -source nature it was quickly picked up
by various other developers and designed into one of the most well -known PHP web frameworks.
[77]
Cake itself prov ides the user with an all -encompassing toolbox to facilitate the usage of all
its features. The framework also employs the “Conventions Over Configuration” design, in that it
already presents a set of various conventions for objects, classes, file and data base names, and many
other elements. This allows the user to focus less on configuring the building blocks, and merely
know which ones to use, as they are already pre -configured. [78]
As part the MVC architecture, the Model layer of Cake is the core of the application, the
layer that implements the actual algorithmic logic. It receives structured data and processes it as
designed by the developer. For example, it could mean user authentication and validation,
audio/video pro cessing, or simply searching and querying a database. The View layer represents the
graphical representation of the data processed by the model. It presents this data using any number
of elements, usually in HTML, but it is open to various extensions. This allows it to deliver
information in extended formats such as XML, JSON and any other format. The Controller is the
actual listener service for the user. It handles the requests from the clients and is responsible for their
processing into usable information and forwarding this to the model. Particular to Cake, the controller
serves also a general -purpose manage r of all process requests within the framework, not only
deciding which model receives which piece of information, but also handling the supplying of the
model’s data to the correct views. [78]

Fig. 2.2.3 -3 – Diagram of C akePHP’s MVC model, showing its particularities. [78]

Chapter Three. Project Implementation

3.1 Hardware

While the ideal physical support for a website or web application has been discussed as being
a powerful, datacenter -grade server, containing Xeon -level processors and EEC memory, for the
purposes of this project, a powerful enough laptop was deemed as sui table. Specifically, an Asus
ROG G751 -JY high-performance gaming laptop was used. [79]
The most significant detail, and having the most impact on a website and/or web application’s
performance, is the main processor. In the current case, the laptop is equipped with an i7 -4710HQ
Haswell -generation processor. [79] Launched in 2014, the CPU sports 4 core, multiplied to 8 logical
threads through the use of Intel’s proprietary Hyperthreading technology. As evidenced by the
benchmark below, while still a laptop processor, the 4710HQ is powerful enough to compare itself
to its desktop counterparts. [80]

Fig. 3.1 -1 – Various synthetic benchmarks comparing the i7 -4710HQ, a mobile CPU, with the i7 -4770, the equivalent top -range
desktop CPU. [81]

Other noteworthy specifications include the 8GB of RAM capacity – not ideal, but sufficient
for the task at hand – and the SSD storage support – allowing the web app to not be bottlenecked by
slow transaction speeds. The operating system running on the platform is a Window s 10 Professional
edition, compatible with all the needed software necessary to run the web server.
On the mobile end of the system, a Sony Xperia Z5 was used as the Android smartphone
platform. The Android application itself shouldn’t and isn’t at all har dware intensive, so the mobile
phone’s chipset is more than sufficient to run it. Specifically, the Z5 is equipped with the previously
discussed high -performance Qualcomm Snapdragon 810 chipset, delivering all the power needed.
[82]
Other notable features are 5.2 inch, 1080×1920 IPS LCD display, capable of utilizing
Android’s high -DPI application profile, as well as its mounted 32GB of internal storage and 3GB of
RAM storage, enabling the entire chipset to perform optimally. In terms of software, the smartphone
is running Google’s latest Android Marshmallow 6.0.1 version (Android 7, nicknamed Nougat, has
been announced, but has thus far not been implemented on any device). [82] This allows the devic e
to be fully compatible with any version of an Android application, supporting all the recent libraries,
toolsets and app components and functionalities. [82]
On the actual wearable side of the system, the Huawei Watch was us ed. This was the
company’s first foray into the smartwatch market, being relatively late compared to its competitors
who have already released several iterations of wearable smart devices, either sporting Google’s
WearOS or having proprietary operating sys tems.

The watch sports a relatively high -dpi screen of 1.4 inches, 400×400 pixel resolution,
managing a 286 PPI (pixels per inch) display density. Although low compared to high -end
smartphones, the device is severely limited by the available power the SoC can deliver. Huawei also
chose to give up the LCD screen generally chosen by smartwatch manufacturers, and instead used a
P-OLED (Polymer -Organic Light Emitting Diode) display. As discussed beforehand, this technology
allows the watch to selectively turn o n only a handful of pixels in order to deliver a minimal display
at significantly reduced battery drain. In practicality this allows the utilization of Android Wear’s
Ambient Mode functionality without majorly impacting battery life.
In terms of performanc e, the watch is identical to almost all Android Wear current -generation
smartwatches, being equipped with the Qualcomm Snapdragon 400 SoC. This chipset’s CPU
contains four Cortex -A7 cores, clocked at 1.2Ghz, alongside a similarly low -power GPU, the Adreno
305. In terms of memory, the watch contains the standard 4 GB of storage and 512 MB of RAM,
common to all android smarwatches. Regarding software, the watch runs the latest Android Wear
version, 1.5, likewise supporting any app feature introduced to date.
Finally, perhaps the most important feature of the phone, is its usable heartrate monitor, in
essence the core of the entire project.

Fig. 3.1 -2 – Illustrations of the laptop and smartwatch platforms. [83] [84]

3.2 Software

The software implementation represents the actual programmed implementation of the entire
project, specifically the Android application (since the Wear app is seen as an extension of the main
smartphone application) and the web application that acts as the server.

3.2.1 Android Wear Application

The entire Android application was coded using the official IDE (Integrated Development
Environment), the Android Studio. While ADT (Eclipse Android Development Tools) used to be the
main Android IDE, it was discontinued during late -2014 to early -2015.
Besides the IDE’s native support for Android, certain factors were prioritized the use of this
IDE against other commonly known on es. The program uses Gradle to build its applications, which
is an automation compiler tool characterized by its optimized patching and refactoring. The tool uses
a tree -based compiling structure, allowing it to quickly pinpoint out -of-date elements and up date only
those, a much faster process than updating the entire application.
Other features specific to Android Studio are its vast range of application templates, giving a
head start for virtually any app, and most importantly, its native, out -of-the-box support for Android
Wear application extension. This is represented by IDE’s building of all necessary files for a Wear
app, allowing the programmer to concentrate only on the code itself.
Starting from the Wear side of things, the application itself is an extension of the smartphone’s
app, being programmed within the same project. Inside the Wear app’s directory within this project,
are the resources used by the app extension, the compiled build components, as well as the original
source code. These are st ructure as the “build” folder and “src” folders respectively.
The src folder contains the actual programming of the app, that is the “main” folder that
contains all the programmed logic, as well as a few files used by the Android system as well as the
Android Studio program. Inside the “main” folder are two subfolders containing the two, separate,
underlying infrastructure of an Android app: the java files and the XML files. Besides these, the
AndroidManifest.xml file is also located here, discussed previo usly as the file containing all
information about the application’s modules.

Fig. 3.2.1 -1 – Android Studio snapshots revealing the “wear” folder’s structure.

The “drawable” folders represent the image resources used by the app. In this case, there is a
single image, the application icon, optimized for different dpi profiles.
The “values” folder contains the “strings.xml” file, which is a repository for all string pointers
found in the app. Generally speaking, Google discourages the use of hard -coded, s tatic strings within
the app, and instead urges the use of string pointers, whose values are stored here. This is because in
this way, multi -language support can be implemented, where the pointers within the app can be

resolved in a multitude of ways, depe nding on what system language is set on the Android
smartphone. This functionality however was not implementing within this project.

Fig. 3.2.1 -1 – Snippet of the string.xml file.

The last folder within the “res” directory, the “layout” folder, contain s the actual graphical
user interfaces displayed. These are all xml files and the first of them, “activity_my.xml” is the first
layout loaded when the application starts. The activity is characterized by pertaining to the
“WatchViewStub” child class. This specific type of view permits the usage of different types of child
views depending on the shape of the device. In this case, the ViewStub contains parameters to
distinguish from rectangle or round watch shape.

Fig. 3.2.1 -2 – Activity_my.xml file, showing the two different layout options.

Either one of the two layouts, the “rect_activity_my” or the “round_activity_my”, is the main
layout activity on the watch, in the current case being chosen the round activity. These layouts each
contain 3 distinc t views containing text (called TextViews) tasked with specific things. Each of the
views are uniquely identified by an ID under the form of “@+id/view_name”. The first view is the
“rate” view, tasked with displaying the read heartrate. The second view rep resents the accuracy
adjustment, and the third view relates information about the sensor. All of these TextViews also
contain parameters used to size them and place them on the screen. After all of these 3 textboxes
there is also a button, called a ButtonV iew. Identified as “ss_service”, it controls the start and stop of
the service tasked with recording the heartrate.
Within the “java” folder of the “main” directory lies another subfolder which itself contains
the java elements that perform the logical pro gramming of the application. In this case, there is a java
activity and a java service.
The java activity, called “WearActivity.java” is the main activity of the application, and is
called at the launch of the app. The file itself first contains a package declaration, which is the way
by which the application is uniquely identified within an Android system. Next are the libraries
imported and used by the application, after which the actual activity is declared and initiated, starting
with the global variabl es.
After that, the connection to the service is created, through the “ServiceConnection” class,
and the “onServiceConnected” and “onServiceDisconnected” methods are overridden. These
methods are called automatically as the service is started and stopped r espectively. Here, the service
starting method instantiates the binder object and attributes its service to a variable, “mService”. The

“mBound” value is also declared as true, signifying that the service is bound. When the service is
stopped, the “mServic e” variable is set to null, and the “mBound” variable is set to false.
A broadcast receiver is then instantiated that listens for the broadcast sent by the service, and
extracts the “WEAR_MESSAGE” extra value from that intent, and sets that value to the “r ate”
TextView.
The actual implementation of the activity is then coded, through the “onCreate()” method
which is called as soon as the activity is started. This starts with the instantiation of a ViewStub and
the binding of it to the main layout stub. A li stener service is then used to receive notification about
when one of the two sublayouts have been inflated. When they have, the “rate” object is being bound
to the “rate” TextView, and its text is being set as a default “Reading…”.
The button is then prog rammed. When it is clicked, it first checks if the service is running,
through the “isServiceRunning()” method implanted at the end of this class. If the service is running,
its text is set to “Start service” and the service connection is checked. If this is also running, then the
bound service connection is terminated, the “mBound” variable is set to false, and the service itself
is stopped. Otherwise, the button’s text is set to “Stop service”, the service itself is started, the activity
is bound to the s ervice and “mBound” is set to true.
After this, the broadcast receiver instantiated above is registered to this activity, and its filter
is set in order to receive messages from the “WearService” service, inside the “onStart()” method.
The same receiver is set to be unregistered when the application is stopped.
Finally, the “isServiceRunning” method is implemented, which checks if the service is
running.
The second java file, the “WearService”, starts off similarly to the main activity, listing the
imported library files. It then declares itself as an extended “Service” class implementing the
“SensorEventListener” class, followed by the various variables used within this class.
The first method is an overridden “onDestroy( )” implementation, which unregisters the
listener service and disconnects the connection to the Google API service. This service is what
actually permits the app to access the smartwatch’s data layer, and so transmit data across activities
and across devic es.
Then the “onCreate()” method is modified to implement the actual programming. First of all,
the connection to the Google API service is opened. The next method is irrelevant to the application,
it is an override of the listener tasked with managing fai led connections, implemented solely for
logging purposes. Finally, the actual Wearable API is added to the Google API service connection
so that the application may use it.
A new thread is then created, instantiated as “tt”, that first and foremost checks if the API
service is created and if the app is connected or connecting to the service. The thread then uses a
“NodeApi” object to scan for connected nodes, which is to say connected devices, i.e. a smartphone.
The results are then put into a list object n amed “nodes”, which is then set to list the node ID of the
first device found. The connection to the API service is then stopped, as the app is done with the
thread for the moment.
The sensor manager and the sensor themselves are instantiated, and the mana ger is set to
listen to this specific sensor.
Lastly, the app implements a method which updates the value of the heartrate if it has
changed. This is an override of the already designed “onSensorChanged()” method. Firstly it checks
if indeed the value has changed, and then restarts the “tt” thread, which again restarts the Google API
service connection if it is down. It then collects the value from the sensor and turns it into a
bytestream, which is send to the designated node, via the Google API service. T he same value is then
sent as an Intent to the “WearActivity” activity, in order to be displayed on screen.

3.2.2 Android Mobile Application

Since the full mobile application is an actual Android application, everything mentioned
previously about the Wear side of the project is also applicable here, from the IDE and building of
the app to the folder structure itself. Since it was discussed that the “src” folder contains the actual
programming of the app, we’ll start from there.
Inside this folder, there are the two folders discussed previously, the java folder and the
resources one. Inside the “res” folder is most of the information needed to display the app, to send
information and render it on the device’s display. Most important here are the layouts, of which there
are two: “activity_auth.xml” and “activity_main.xml”. The two activities are fairly simple, serving
only to match entities on the display to objects in the java files. The authentication activity is the first
one that pops up when launching the app, it uses an authentication form to collect the information
needed to connect to the server, which is the Server IP, Username and Password. It then has a simple
button attached to the login function. The user is then directed to the main activity, which hol ds a
textview with the heartbeat and reference to the linechart that will display the heartbeat historically.
The java folder itself contains the many classes used in the project . First and foremost there
is the MainActivity class, which is the primary act ivity in application and the one attached to the
“activity_main.xml” file. It starts off instantiating all the data it needs, from a simple TextView, to a
broadcast receiver for the service, as well as a database object (which will be discussed shortly) an d
chart data. On being created, this activity instantly looks up the database to get heartbeat values
without waiting for a specific input. It then uses these values, stored in an array to populate the chart
that will show the historical heartbeat informat ion. After, it edits the TextView at the top of the
display, to show the current heartbeat and also starts the receiver that will get the heartbeat
information through the listener service. Two methods are then coded, to start and respectively stop
the receiver for the listener service. After this, the method to update the chart is created, in essence it
uses the same logic as the segment from the onCreate() method in order to collect the informa tion
from the database, store it, use it in a dataset, and then use the dataset to populate the chart. Methods
to inflate and interact with the options menu are then programmed. To be more specific, there is a
toggle for the live listener service (that use s the two methods to start and stop the receiver mentioned
above), settings to switch between day, month and year heartbeat classification and a button to logout
from the current instance of the application (which will forward the application to the AuthAc tivity
class). Lastly, a customized version of the public AxisValueFormatter class is used, which the chart
employs in order to display its data.
The first activity that the user is actually presented with is the AuthActivity. This one handles,
as the name implies, the authentication itself with the web server. In the beginning, the activity clears
any possible leftover objects from previous executions and also instantiates the UI elements that it
will use. When created, it will employ this UI elements to p opulate the associated XML with the
from fields required for validation, which are: Server IP, Username and Password. It also links the
sign-in button and the progress animation to their respective xml objects. Of note next is that the
onResume() method is overridden, so that when the activity is resumed, the app will try to
authenticate with the web server using the saved token. Next up, the method used to attempt the
authentication is coded. This one first loads the information the user inserted in the fo rm fields, inside
corresponding variables in order to use them. It then checks to see if the username and password
fields are empty, as they are not allowed to be and finally instantiates a new UserSignInTask objects
(class that will be discussed shortly) and executes it. A standard, public method of animating a
loading icon is then coded, as per the official instructions on the Android Developer website. Finally,
the two classes of authentication are coded, one that uses the username and password written b y the
user in the form, and another that uses the token received from the website. UserSignInTask is the

method that uses the form information, and it extends the AsyncTask class. It first creates the
variables for the form data and defines how these varia bles will be passed as input to the class. In the
background, it then c alls a ServerConnector method (a class that will be discussed shortly ) and passes
the form data as parameters, expecting in return the authentication token from the web server. This
token is then saved on a file using the Settings class’s methods. If the authentication is successful, an
intent for the main activity is generated. The final method, the authentication with token, progresses
in a much similar fashion, save that instead of su bmitting a username and password through the
ServerConnector method, it instead sends the token and expects a response based on that.
Two slightly different classes inside the java folder are the Heartbeat and Settings files. The
former simply because it’s programmed for ease of access to heartbeat objects and only contains the
fields necessary to correctly define a heartbeat. The latter, because it’s a class used for the purposes
of saving and retrieving information stored locally. It contains methods to w rite files on the local
disk, and also to access them. It is this class that is used to hold the authentication information used
in the other classes, specifically the token, server address, id and also has methods to access or delete
these files.
There ar e also two classes that both deal with configuring and manipulating the database that
the application uses to store all the heartbeats. These are the DatabaseContract and DatabaseHandler
respectively. The former simply holds variables to easily manage SQL operations, using data for
table name, column values, date created and sync status. The DatabaseHandler however is a class
that extends SQLiteOpenHelper, a public class used to manage as easily as possible sql databased
within an android app. Its onCreate( ) method is overridden to generate an sql table with the fields
configured in the DatabaseContract class. Afterwards, the methods used to manipulate data inside
the table are defined. First, it’s the addHeartbeat method which takes the value and sync statu s as
parameters, puts them in a ContentValues files instantiated as values, and then uses the inherited
‘insert’ method to put this data inside the database and return the id of the newly created row. The
next method takes as input parameter a heartbeat id and then sets the sync status column of that
heartbeat id inside the table as true. The following method goes hand in hand with the last, as it is
used to produce a list of unsynced heartbeats. An sql query is configured, asking for the id’s of all
heartb eats whose sync status column is set to false. All these heartbeats are then written on a list
which is returned by the method. The last method in this class is a general request for heartbeats,
having input parameters as a limit and the period in which th e heartbeats are requested. Depending
on the period selected (which can be either day, month or year), a “WHERE” sql query condition is
generated, defining either the current specific day, or a period of time beginning either at the
beginning of the curren t month, or beginning of the current year. This condition is then used in an
sql query that asks for all heartbeats that comply to it. All of these are then inserted into the list, and
the list is returned by the method.
For the communication with the serv er, the app uses two activities, ServerConnector and
HTTPConnector. The latter is a class designed to ease the transmission of HTTP messages and has a
generalized method that can execute almost any kind of HTTP request, specifying the endpoint,
request typ e, paramet ers and headers and is even able to direct both clear HTTP and HTTPS. The
ServerConnector class uses the HTTPConnector method to send specific requests from the app to the
server. This class starts off with a way to call it mentioning the server endpoint and then defines the
login input method. It then inserts the secured information inside hashmaps and loads these hashes
into the parameters variable. It then uses a HTTPConnector object to forward this data to the server.
The next method is design ed to receive user information from the server, by supplying it with the
authentication token and an “X -Authorization” HTTP field. This field is the keyword that the server
looks for when listening for requests that come from the app, with the token. Anoth er method to rely
on this header is the “sendHeartbeat” method. Since it would be unrealistic to have to provide a

username and password every time the heartbeat is sent to the server, the app instead uses the token
supplied by the server, attached to this “X-Authorization” field, for every heartbeat transmission.
Finally, there is the WearListenerService java file, that deals with the connection between the
mobile phone and the smartwatch and collects the heartbeat information. At the beginning, it declare s
all the data it needs, including a ServerConnector object and a DatabaseHandler one. In the
overridden initialization method, the class first tries to use the saved server address in order to log in
using a token. Inside the “onStartCommand” method, whic h is executed every time the service is
started, the app requests a list of all heartbeats that exist in the phone’s database, but have not been
synced with the server. These heartbeats are then sent to the server. Next, the method that listens for
messages is configured. Whenever a message is received (which is checked using Android’s native
MessageAPI), a ByteBuffer object is created to extract the data from the message. The integer value
from the message is then saved inside a variable and that variable is sent to the table using the
DatabaseHandler object created previously. The same variable is also sent to the main activity to be
displayed on -screen. If a token exists, the service then tries to send the heartbe at to the web server.
If it receives a response that the action was successful, it also set the sync status of that particular
heartbeat inside the phone’s database as synced. Lastly, the method used for the attempt to sign in
with token is configured in t he same fashion as for the AuthActivity class. If the attempt fails
however, an intent is generated to direct the app to the Authentication activity in order to sign in with
username and password.

3.2.3 Web Server

As discussed during the theoretical presentati on, the web server in the project is coded in
PHP, using the Cakephp3, which is an MVC PHP framework. The IDE used for the coding is PHP
Storm. Worth noting is that unlike most other MVC’s, cake separates its usually unitary ‘model’
objects, into two objec ts: Entity and Table.
An Entity means referring to the object itself (in this case User, Heartbeat, etc.) and
informationally, it represents a single row. Such objects usually contain global properties that you
wish to share among all instances of themselves, as well as methods to edit, view or delete the
information they hold. These manipulations of data within an instanced entity can happen in a few
ways, first of which, and the simplest, is just using the object as it is defined. Another way is u sing
the get() and set() methods which have direct access to the data.

Fig 3.2.3 -1 – Examples of accessing and manipulating data within enties. Top: the set and get commands. Bottom: using
object notation.

A Table refers to the actual database table and all actions directed at that table. Such an object,
therefore, is necessary to interact with any given table. An advantage of cakephp is that it creates a
Table instance whenever you need to use a table, givi ng the programmer access to the most widely
use methods of interaction with such a table. When creating tables, certain conventions are used, such
as the name of the table that the class will use, or the primary key that is expected, or the name by

which t he Table objects search for an Entity Class. All of these can be customized inside the
“initialize” function, a method called at the end of the constructor. Its purpose is exactly this, to fine
tune tables, without risking overriding the constructor itself , which could prove problematic if
mishandled.
Within the project itself, the file structure is mostly automatically populated by the cakephp
framework (a distinct advantage of using frameworks, and especially this specific one, as the
programmer need onl y bother with programming the bits that need to be customized to the specific
task). It contains the “bin” folder, first and foremost, which is specific to this framework and contains
initialization data.
Next is the “config” folder, which contains the ro uting mechanism of the framework. The
purpose of routes is to create paths to the various sections of the website, within the HTTP addresses
themselves. The routes.php file holds all of these associations, in effect binding HTTP links to
controllers and th eir actions. What is interesting here is that some routes aren’t simple one -to-one
static associations. Rather, they can take certain data from the HTTP link, verify that it is in
accordance to a desired structure (such as verifying that an id field only c ontains digits), and passing
that data forward to the action specified in the route. In a specific case here, when accessing the
“/heartbeats/:user_id” link, the server checks first that the user_id contains only digits, and then
passes that value to the “ index” action from the “heartbeats” controller. Inside the “config” folder are
also the “app.default.php” and “app.php” files, which contain information the server will start to,
practically the initial default settings. Of note is the mail transport funct ionality which is defined
here. Since the server has the capability to send an email t o the doctor in case a pat ient reaches critical
heartbeat, the settings required to reach and authenticate on a mail server is set here (in this case, the
settings are a simple smtp over tls connection to a mail provider). The “bootstrap” and “schema” files
are defined automatically by the framework and contain framework specific data. Schema for
example, contains data for internationalization, like languages. The Seeds fo lder contains initialized
objects that the database should start with, which is a good way to start the web server and have some
information already present in order to test its functionality (in his case, it contains three patients,
each with the “patient ” password). The last element in the “config” folder are the migrations. These
function as links/translations between a model (such as user, in this case) and the SQL database. It is
cakephp’s way of simplifying and streamlining database interaction, by al lowing the use of php code
for all interactivity with the database. In effect, for every modification on the table’s structure, there
is a migration.
The other important folder is the “SRC” folder, where all the actual implementation of the
code is stored. All the server elements described beforehand are here, meaning the actual MVC
components and all custom classes. The ”View” folder here contains “AjaxView.php” and
“AppView.php” files which are automatically generated by phpcake as default, but have not b een
customized. The same thing is true regarding the “Shell” and “Console” folders.
The first folder that the user interacts with, so to speak, is the Template folder, which contains
the actual pages that present the information to the user. In a way, this is analogous to Android’s
XML files. On one hand, in the background, you have the a lgorithmical logic of the program, and in
the forefront you have the layout that is presented to the user. These layouts are all contained here,
and reference elements from the computational files. These templates are mostly written in html, but
contain ph p code as well. Furthermore, the templates are not singular, absolute objects. One template
can contain another, and a web page can contain multiple templates at the same time. In the “users”
folder, for example, are most of the webpages that the user has access to, such as the doctor listings,
the index containing patients, pages to add doctors or patients, and the main view as well. This main
view (configured as the “view.ctp” file) represents the webpage that the user is presented with after

login, and a lso contains the graphing function and the JSON functions used to get access to the
heartbeat information.
Next is the “Model” folder. As explained before, the model is characterized by an entity object
– which represents the object itself, the user, a si ngle row in the table – and the table object – which
is characterized by information pertaining to that specific row. The entity can hold data regarding
which fields are to be given public access and which to be protected, functions regarding database
fields like passwords, and so on. In the table objects however, the relations between objects are
defined, for example a user entity can have many heartbeat entities and many histories. In a table you
can also code field validators, to make sure the informatio n is correct. In our case, we have three
entities: Heartbeat, History and User. The latter is fairly self -explanatory and is a pretty basic model,
all it contains are settings regarding accessible fields – in this case, the ‘id’ is not accessible, and the
password is not only inaccessible but also hidden – and a protected function that allows password
setting and also hashes the password, so if someone were to hack into the database, they would only
have access to the hash. Next is the History object, desig ned to hold the diagnostics history of the
patient. This one is even simpler than the User object, it is simply a declaration of an entity model,
with the default settings. Same thing is true regarding the Heartbeat entity. In a separate folder, we
have th e table objects: HeartbeatsTable, HistoriesTable and UsersTable. In the latter, the object itself
is defined as extending the Table superclass and described with the table itself that it should be bound
to, the primary key and the relation to the other objects (as mentioned before, a user has many
heartbeats and many histories). Next are field validators, specifying which fields are allowed to be
empty, which are mandatory and when these rules should be applied. The HistoriesTable object is
created similarl y, just with different relation rules. In this case, the histories are set to belong to the
Users objects, and their foreignKey is defined. Validators are still mentioned regarding the fields in
this table, specifically the treatment and diagnostic fields. The heartbeat table is coded almost
identically to the histories one, belonging to the Users object and having some validators at the end.
Next, there is the Auth folder. This contains a single file: TokenAuthenticate.php. This class
doesn’t conform to an y MVC object format, it is simply a custom designed class in order to ease the
authentication mechanism use in the controllers. It extends the FormAuthenticate class which is the
authentication platform in cakephp, and then has two custom functions. One is the authentication
function, and the other is a method to query the user based on the given token from the “X –
Authorization” HTTP header. Should no token exist, the true value is returned, and should either no
user, or multiple users exist with the same t oken, the false value is returned. Otherwise, the required
user is returned.
Finally, the last folder inside “src” is the Controller folder, which holds controllers for all
models declared previously and also a few extra controllers for other functions. Ba sically, this is the
actual programming of the website, the logic itself. First of all, there’s the UsersController.php, which
contains information regarding all actions on the user object within the web interface. At the
beginning, there are filters used in order to restrict access to the actual page, until the user has
authenticated. As such, the user will at first only see the authentication form and allowed the login
and logout methods. Next, the index is rendered which is the element on the website con taining the
list of patients. Simple, raw functions are then declared, the ability to view a user and his associated
heartbeats and history, the option to add another patient or another doctor (to be noted, only a doctor
can add another doctor) and to see the list of all doctors. Options to edit or delete users are also
present. The login function is lastly defined, using the Auth class which inherits methods such as
“identify()” that checks the username and password and returns the user. Then, the user is checked
to see if it is a patient or a doctor. In the case of the latter, he is redirected to the main page, otherwise
the patient is shown his own personal view page, as he is not allowed more than this. Next is the
HistoriesController, which similarly to the users starts with an index listing the history of a user and

then moves to the general functions: a simple view function, an add function in order to update a
patient’s history and an edit function to modify an existing history. A delete option is als o available.
The HeartbeatsController.php is somewhat different, in that it is only designed to be used by
the interaction between the webserver and the mobile app. As such, the filters only allow connections
that present the X -Authorization header token, only allow the add function, and also memorize that
user in order to categorize the heartbeat by the correct patient. An index function is also present,
capable of categorizing the heartbeats by day, month or year, as requested. A default view function
is listed and then the add function which instantiates a new entity of the Heartbeats object and attaches
it to the corresponding user. Finally, the default edit and delete functions are described.
The AppController.php is somewhat of a master controller for the entire website. It is the only
one that extends the Controller superclass, and all other controller in this project extend the
AppController (with one exception, which will be discussed shortly). As such, it is the place to build
global and streamlined settings, that all controller should have by default. At first, the “initialize()”
function is defined, loading the required components, listing the redirects for the login and logout
functionalities, and describing the format used to authenticate the use rs. This is also where the user
is being categorized as doctor or patient, admin or not, and so to what resources they have access to.
Finally, the only other controller to not extend the one discussed above, is ApiController.php.
This one is intended to be the controller that directly communicates with the mobile app. It has its
own initialization, with its own components. Then, the login function is programmed, which checks
the details used for authentication and if they are correct, dynamically generates a unique string, the
uuid, and attaches it to a user as the authkey, afterwhich the entire user (including the authkey) is
passed on to the mobile app. A getUser() function is then coded, which behaves similarly to the last
part of th e login function. Finally the adHeartbeat() function is defined, which instantiates a new
Heartbeat entity with the data received from the mobile app, checks the user and then attaches the
heartbeat to that user. Furthermore, it also checks to see if the v alue received exceeds the alert value
and if it does, uses the Email() function to send a warning mail to the doctor.

Conclusion

This project, therefore, aims to bridge the inefficient gap between user and information, taking
away the practice of sharing data through strictly physical means. All of this lead to several
advantages and important points of progress.
First and foremost, queues at the doctor’s office will ideally be eliminated, as the bulk of
people waiting in such lines, in fact wait for brief consultations regarding their diagnostics. The issue
being that the doctor will only see and examine test results and findings at that specific moment,
when the patient presents the file to them. Migrating this to a digital platform allows the doctor to
examine most of what is needed, tests and such, directly from a web portal, without the person having
to visit them at the clinic. This saves time for both parties and allows a much more efficient and
streamlined process of providing a diagnostic and prescribing a treatment.
Moreover, it presents all of this information as easily accessible to the two parties as possible.
Physical rec ords must be picked up, collected, which in itself adds a useless delay, but also prevents
them from being accessed so easily since they are, after all, physical objects. With the help of EHR’s,
such data is supplied to the patient and doctor as soon as it is made available, eliminating any and all
delay from the termination of the text results, to the access by the user. This also allows the person
to look at the information at any time, from any place, without fear of losing it, damaging it, or having
to keep it safe in any way. The information is inherently safe, since it is stored digitally and backed
up.
Furthermore, linking a cloud platform to the collection of real time biomedical data allows
the doctor to have a live overview of the patient’s health, minimizing the time of intervention in the
case of an emergency. Since many times, a patient suffering from a crisis will not be able to use a
phone and call an ambulance directly, the fact that the doctor can be immediately alerted to such a
situation co uld potentially save lives. Moreover, it can act to prevent, not only react. The doctor can
supervise a patient’s health, and notice unhealthy behavior and can then notify the patient of what
needs to be changed. This of course does lead into an entire iss ue of privacy and surveillance, an
issue quite present in the world today as it is, but at the very least this gives people an option. The
option to be looked after and taken care of if their situation deteriorates to the point where they could
not act oth erwise.
The project itself does have limitation s as it is, however. The precision of the heartbeat
information relies entirely on the smartwatch device, not to mention that not all smartwatches do
have a heartbeat sensor. The mobile phone as well must have constant internet access in order to send
the information. If the phone does not have connectivity, or the smartwatch fails to pick up the
heartrate, the information on the web server can reach it significantly late or altered. Furthermore, if
the case is that the server platform is loaded with hundreds or thousands of patients, the very real
issue of hardware performance appears. There is only so much processing power that can be cheaply
put inside a server, and the more transactions it requires, the more database operations it needs the
do, then the more powerful the machine must be. This can lead to significant investment needs to the
hardware support of the web platform, which grows exponentially. Not to mention that ideally all
this investment is doubl ed by the backup site, since that is an entire point of having digital records,
for them to be safe in case of disaster. Finally, the most dangerous threat to a platform such as this
remains a cyberattack. As they have grown more and more common, more and more targeted, the
need for security has grown significantly in the last years. Anything that has access to the internet is
vulnerable, and anything with databases containing civilian information represents an especially
attractive hit for attackers. The e ntire infrastructure must then be secured, which adds an even bigger
investment, both in time and finances.

As the basic premise of the idea has been described throughout the project, the potential for
future development is even greater. The platform itsel f could be extended to support different kinds
of doctors, different kinds of departments, in effect transcribing on the digital web site, the actual
layout and topology of a hospital, offering patients intuitive access to exactly the doctors they need.
The platform can also be linked to various institutes and clinics, allowing medical referrals and
appointments directly from the website. All of this can also potentially evolve into an entire digital
hospital, allowing communication and sharing of informati on between doctors and professionals
themselves, all accessible from anywhere at any time, giving the patient the best possible care without
delay. More than the server side of things, the infrastructure can also grow to encompass not only
heartbeat collec tion, but an entire array of sensors, allowing, if needed, a full biomedical monitoring
of patients, from blood pressure, to glucose levels and more. The web site access provided to the
patient can then also be made into a personal health dashboard, with i nformation about when to take
medication, what to do in case of emergencies, offering a full, detailed overview of everything the
patient needs. Going even further, contracting the services of a delivery company, the platform can
also serve as an online ph armacy for patients to order the medication they need, and for it to be
delivered directly to their home.
To conclude, in my opinion, such a project would be highly important in the future to ensure
the efficient distribution of medical information in the hopes of offering better, faster medical
services.

References

[1] "Internet of Things Global Standards Initiative," [Online]. Available: http://www.itu.int/en/ITU –
T/gsi/iot/Pages/default.aspx.
[2] "Health Affairs," August 2014. [Online]. Available:
http://content.healthaffairs.org/content/early/2014/08/05/hlthaff.2014.0445. [Accessed June 2017].
[3] G. L. Baumblatt, "Becker's Hospital Review," 16 September 2014. [Online]. Available:
http://www.beckershospitalreview.com/hospital -management -administration/collaboration -will-
define -healthcare -s-future -a-recap -of-stanford -medicine -x-2014.html?__scoop_post=6004ca10 –
3e06 -11e4 -d5b0 -842b2b775358&__scoop_topic=3078282#__scoop_post=6004ca10 -3e. [Accessed
June 2017].
[4] "GSMArena T -Mobile G1 Review," [Online]. Available: http://www.gsmarena.com/t_mobile_g1 –
review -337.php.
[5] PDAdb, "PDA Database – Qualcomm MSM7200," PDA Database, [Online]. Available:
http://pdadb.net/index.php?m=cpu&id=a720 0a&c=qualcomm_msm7200a.
[6] ARM, "ARM Infocenter – AMBA AXI," ARM, [Online]. Available:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0022d/index.html.
[7] Google , "Google User Content – Android CDD," [Online]. Available:
http://stati c.googleusercontent.com/media/source.android.com/en//compatibility/android -cdd.pdf.
[8] Google, "Android – Graphics," [Online]. Available:
http://source.android.com/devices/graphics/index.html.
[9] "What is system -on-a-chip," Tech Target, [Online]. Available:
http://internetofthingsagenda.techtarget.com/definition/system -on-a-chip -SoC.
[10] "How it Works – System on a Chip," Android Authority, [Online]. Available:
http://www.androidauthority.com/how -it-works -systems -on-a-chip -soc-93587/.
[11] "Loughborough University Instituional Repository," [Online]. Available:
https://dspace.lboro.ac.uk/dspace -jspui/handle/2134/6162.
[12] "Mobile Data – How It Works," i -programmer, [Online]. Available: http://www.i –
programmer.info/programming/hardware/3676 -mobile-data -how -it-works.html.
[13] R. Cerejo, "All You Need to Know About Mobile Phone Chipsets," Firstpost, 28 April 2012. [Online].
Available: http://tech.firstpost.com/news -analysis/all -you-need -to-know -about -mobile -phone –
chipsets -27704.html.
[14] "Tegra X1 Super Chip," Nvidia, [Online]. Available: http://www.nvidia.com/object/tegra -x1-
processor.html.
[15] "Galaxy S7 Edge Review," GSMarena, [Online]. Available:
http://www.gsmarena.com/samsung_galaxy_s7_edge -review -1409p6.php.

[16] R. Shrout, "Qualcomm History and its GPU Revolution," PCper, 22 June 2015. [Online]. Available:
http://www.pcper.com/reviews/Processors/Qualcomm -History -and-its-GPU -Revolution/Present -and-
Future -Qualcomm -GPUs.
[17] "Z-buffering," Wikipedia, [Online]. Available: htt ps://en.wikipedia.org/wiki/Z -buffering.
[18] "Qualcomm Adreno 530," Notebook Check, [Online]. Available:
http://www.notebookcheck.net/Qualcomm -Adreno -530.156189.0.html.
[19] "Tegra FAQ," Nvidia, [Online]. Available:
http://www.nvidia.com/docs/IO/55043/ NVIDIA_Tegra_FAQ_External.pdf.
[20] "Tegra X1 Whitepaper," Nvidia, [Online]. Available:
http://international.download.nvidia.com/pdf/tegra/Tegra -X1-whitepaper -v1.0.pdf.
[21] "CUDA Toolkit," Nvidia, [Online]. Available: https://developer.nvidia.com/cuda -toolkit.
[22] A. Stevenson, "Snapdragon 820 vs Snapdragon 810," Trusted Reviews, 25 April 2016. [Online].
Available: http://www.trustedreviews.com/opinions/snapdragon -820-vs-snapdragon -810.
[23] "Snapdragon 820 Datasheet," Qualcomm, [Online]. Available:
https://www.qualcomm.com/products/snapdragon/processors/820.
[24] "big.LITTLE processing," ARM, [Online]. Available:
https://www.arm.com/products/processors/technologies/biglittleprocessing.php.
[25] "Exynos 8 Octa Datasheet," Samsung, [Onli ne]. Available:
http://www.samsung.com/semiconductor/minisite/Exynos/w/solution/mod_ap/8890/.
[26] "Smart Watch Explosion," QUARTZ, [Online]. Available: http://qz.com/101058/smart -watch –
explosion/.
[27] "Moto 360," GSMArena, [Online]. Available:
http:/ /www.gsmarena.com/motorola_moto_360_(1st_gen) -7682.php.
[28] "Snapdragon 400," Qualcomm, [Online]. Available:
https://www.qualcomm.com/documents/snapdragon -400-processor -product -brief.
[29] "Web Path Diagram," Wikipedia, [Online]. Available:
https://up load.wikimedia.org/wikipedia/commons/0/0e/Working_of_hosting_servers.jpg.
[30] "What is Web Server," Web Developer's Notes, [Online]. Available:
http://www.webdevelopersnotes.com/what -is-web -server.
[31] V. Nani, "Web Server Hardware and Software," 16 April 2013. [Online]. Available:
http://www.slideshare.net/VikramNani/web -server -hardware -and-software -18966627.
[32] "Supermicro Layout," Server The Home, [Online]. Available: http://www.servethehome.com/wp –
content/uploads/2013/03/Supermicro -X9DRH -7TF-Layout.png.
[33] "Symmetric Multiprocessor System," Wikipedia, [Online]. Available:
https://upload.wikimedia.org/wikipedia/commons/thumb/1/1c/SMP_ –
_Symmetric_Multiprocessor_System.svg/2000px -SMP_ -_Symmetric_Multiprocessor_System.svg.png.

[34] "Xeon E7 B rief," Intel, [Online]. Available:
http://www.intel.com/content/www/us/en/processors/xeon/xeon -e7-8800 -4800 -v4-product –
families -brief.html.
[35] "Google Buys Android," WebCitation, [Online]. Available: http://www.webcitation.org/5wk7sIvVb.
[36] J. Call aham, "Google Report," Android Central, 29 September 2015. [Online]. Available:
http://www.androidcentral.com/google -says -there -are-now -14-billion -active -android -devices –
worldwide.
[37] R. Amadeo, "Google's Iron Grip," Ars Technica, 21 October 2013. [Online]. Available:
http://arstechnica.com/gadgets/2013/10/googles -iron-grip-on-android -controlling -open -source -by-
any-means -necessary/.
[38] "Android Vulnerabilities," Android Vulnerabilities, [Online]. Available:
http://androidvulnerabilities.org/.
[39] "Waiting for Android's Security Armageddon," Ars Technica, 8 July 2015. [Online]. Available:
http://arstechnica.co.uk/gadgets/2015/08/waiting -for-androids -inevitable -security -armageddon/.
[40] "Android Inputs," Google, [Online]. Available: http://so urce.android.com/devices/input/.
[41] "Widgets," Google, [Online]. Available:
https://developer.android.com/design/patterns/widgets.html.
[42] H. Lockheimer, "Android and Security," Google, 2 February 2012. [Online]. Available:
http://googlemobile.blogspot.ro/2012/02/android -and-security.html.
[43] C. Metz, "Google's Training its AI," Wired, 6 February 2016. [Online]. Available:
http://www.wired.com/2016/06/googles -android -security -team -turns -machine -learning/.
[44] "Android Kernel Versions," Linux, [Online]. Available: http://elinux.org/Android_Kernel_Versions.
[45] R. Whitwam, "Android 4.4 Kernel," Android Police, 25 November 2013. [Online]. Available:
http://www.androidpolice.com/2013/11/25/htc -posts -android -4-4-kernel -source -and-framework –
files-for-one-google -play-edition -ota-update -cant -be-far-off/.
[46] "Anatomy and Physiology of an Android," Google, [Online]. Available:
http://androidteam.googlecode.com/files/Anatomy -Physiology -of-an-Android.pdf.
[47] P. Nickinson, "Google Android developer explains more about Dalvik and the JIT in Froyo," Android
Central, 26 May 2010. [Online]. Available: http://www.androidcentral.com/google -android –
developer -explains -more -about -dalvik -and-jit-froyo.
[48] C. Toombs, "Meet ART," A ndroid Police, 6 November 2013. [Online]. Available:
http://www.androidpolice.com/2013/11/06/meet -art-part-1-the-new -super -fast-android -runtime –
google -has-been -working -on-in-secret -for-over -2-years -debuts -in-kitkat/.
[49] "Android Architecture," tutorial spoint, [Online]. Available:
http://www.tutorialspoint.com/android/android_architecture.htm.
[50] "App Fundamentals," Google, [Online]. Available:
https://developer.android.com/guide/components/fundamentals.html.

[51] "Activity Lifecycle," Google, [Online]. Available:
https://developer.android.com/training/basics/activity -lifecycle/starting.html#lifecycle -states.
[52] "Services," Google, [Online]. Available:
https://developer.android.com/guide/components/services.html.
[53] "Content Provider," G ooge, [Online]. Available:
https://developer.android.com/guide/topics/providers/content -provider -basics.html.
[54] "Broadcast Receiver," Google, [Online]. Available:
https://developer.android.com/reference/android/content/BroadcastReceiver.html.
[55] "Intent and Intent Filters," Google, [Online]. Available:
https://developer.android.com/guide/components/intents -filters.html.
[56] "Manifest Intro," Google, [Online]. Available:
https://developer.android.com/guide/topics/manifest/manifest -intro.html.
[57] "Google Reveals Android Wear, an operating system for smartwatches," The Verge, 18 March 2014.
[Online]. Available: http://www.theverge.com/2014/3/18/5522226/google -reveals -android -wear -an-
operating -system -designed -for.
[58] R. Amadeo, "Android Wear gets cellular support, still needs to be paired with a phone," ArsTechnica,
11 December 2015. [Online]. Available: http://arstechnica.com/gadgets/2015/11/android -wear -gets –
cellular -support -still-needs -to-be-paired -with -a-phone/.
[59] R. Amadeo, "Android Wear software review: Smartwatch software that doesn't suck," ArsTechnica, 7
January 2014. [Online]. Available: http://arstechnica.com/gadgets/2014/06/android -wear -review/.
[60] "Adding Wearable Features to Notifications," Google, [Online]. Available:
https://developer.android.com/training/wearables/notifications/index.html.
[61] "Wearable Apps," Google, [Online]. Available:
https://developer.android.com/training/wearables/apps/index.html.
[62] "Wearable Message API," Google, [Online]. Available: ht tp://android -wear –
docs.readthedocs.io/en/latest/sync.html.
[63] "Wearable Data API," Google, [Online]. Available: http://android -wear –
docs.readthedocs.io/en/latest/data.html.
[64] "HyperText Transfer Protocol," IETF, [Online]. Available: https://tools. ietf.org/html/rfc2616.
[65] "RFC7235," IETF, [Online]. Available: https://tools.ietf.org/html/rfc7235.
[66] "RFC1945," IETF, [Online]. Available: https://tools.ietf.org/html/rfc1945#section -8.
[67] "RFC2616," IETF, [Online]. Available: https://tools.ietf.org/html/rfc2616#section -9.
[68] "What is PHP?," PHP, [Online]. Available: http://ro1.php.net/manual/en/intro -whatis.php.
[69] "What can PHP do?," PHP, [Online]. Available: http://ro1.php.net/manual/en/intro -whatcando.php.

[70] "Scalar Type Declarations," PHP, [Online]. Available: https://wiki.php.net/rfc/scalar_type_hints_v5.
[71] "Instruction Separation," PHP, [Online]. Available: http://www.php.net/basic -syntax.instruction –
separation.
[72] "Comments," PHP, [Online]. Available: http://www.php.net/manual/en/language.basic –
syntax.comments.php.
[73] "Variable Types," PHP, [Online]. Available: http://www.php.net/manual/en/language.types.php.
[74] "User -defined functions," PHP, [Online]. Available: http://www.php.net/ma nual/en/functions.user –
defined.php.
[75] T. Reenskaug and J. O. Coplien, "The DCI Architecture: A New Vision of Object -Oriented
Programming," Artima, 20 March 2009. [Online]. Available:
http://www.artima.com/articles/dci_vision.html.
[76] "MVC Diagram, " Wikipedia, [Online]. Available:
https://upload.wikimedia.org/wikipedia/commons/a/a0/MVC -Process.svg.
[77] "Team," cakephp, [Online]. Available: https://cakephp.lighthouseapp.com/contributors.
[78] "CakePHP at a Glance," CakePHP, [Online]. Available: http://book.cakephp.org/3.0/en/intro.html.
[79] "ROG -G751JY," Asus, [Online]. Available: https://www.asus.com/ROG -Republic -Of-Gamers/ROG –
G751JY/.
[80] "i7-4710HQ," Intel, [Online]. Available: http://ark.intel.com/products/78930/Intel -Core -i7-4710HQ –
Processor -6M-Cache -up-to-3_50 -GHz.
[81] "i7-4770 vs i7 -4710HQ," CPUBoss, [Online]. Available: http://cpuboss.com/cpus/Intel -Core -i7-4770 –
vs-Intel -Core -i7-4710HQ.
[82] "Sony Xperia Z5," GSMArena, [Online]. Available: http://www.gsmarena.com/sony_xperia_z5 –
7534.php.