on a Java Virtual Machine since it is not designed to run on resource-constrained environments. Originally, Android developed the Dalvik VM [24] particularly tailored for that purpose: a register- based VM optimized for low memory requirements that relied on the underlying OS to isolate processes, manage memory and support threads while allowing multiple VM instances to run at once. Since Android 5.0 "Lollipop", the Dalvik VM is discontinued. Android incorporated Ahead-of-time (AOT) compilation which translates the Dalvik bytecode of the application to device-specific instructions at install-time. This allowed to improve applications performance on the phone without sacrificing their portability. Subsection 2.3 elaborates on how the Java code written by the programmer is transformed to run on the device.
To keep Android agnostic about low-level driver implementations, it defines a standard interface for vendors to implement, the hardware abstraction layer (HAL). Thus, vendors can implement funcionalities without affecting software of higher-levels.
The Linux Kernel layer is the bottom of the Architecture and the heart of the whole system by gathering all the core services that any Android device relies on. It provides generic operating system services such as management of memory and processes, storage and network I/O, security settings to grant/deny access to hardware devices or data. It also offers an interface that allows to plugin hardware device drivers so Android can communicate with a wide range of low-level components that are often coupled to the mobile. The layer also includes some Android-specific components that target to mobile-related issues such as the power management, memory sharing or its own interprocess communication mechanism known as binder.
Figure 2.1 illustrates the different layers of the Android Software stack described above.
2.2
Applications
As explained in the previous section, applications are how users access to the device functionalities. A user interacts with an application through the graphical interface developed by its programmer along with all the logic that supports the feature. To help on that job, the Android Framework provides four building blocks: activities, services, content providers and broadcast receivers.
Activities are designed to contain the visual interface through which users give and receive information from and to the application. By convention, an activity should support a single and individually-focused action that user can do and string together to other activities to achieve a common purpose. Tasks gather all the activities related to the same goal, not necessarily from the same application, and organizes them as a stack where the top activity is shown to the user. When the user launches an application, a new task is started along with a new activity which is pushed onto the top of the stack.
From the forefront activity, the user might need to navigate to a new activity. In this case, Android suspends the current activity, captures its current state, creates the new activity and pushes onto the top of the stack. When the activity is no longer useful, it is destroyed and popped
Figure 2.1: Android software stack. (Source: https://developer.android.com)
out of the stack; the new peek activity resumes its execution and is shown to the user. Developers only need to focus on the graphical elements shown to the user in each activity and the actions that need to be taken when interacting with them; the base Activity class encapsulates all the management of the task stack and the lifecycle of that particular activity.
When the application requires two components to interact, e.g. the current activity creates a new activity or opens a web page in the browser, developers turn to Intents. Intents are a class of the Android framework that represents an action to be done: create a new activity or a service, notify an event, etc. The component that the action targets can be explicitly indicated by the developer, for instance, creating a new activity of the same application; or developers may leave it implicit in the code indicating only the action to perform and Android determine which component
2.2. APPLICATIONS
of which application receives the action through a process known as Intent Resolution. Intent Resolution relies on a manifest (AndroidManifest.xml) attached to each application describing its components and which actions they support. At runtime, when an Intent is created and to be delivered, the system matches the action with some known component (action Id, data type and category). Multiple components can accept the same kind of intent, in that case, Android needs to choose a single one, usually asking the user.
Services are the application component designed to support long running operations with- out providing any user interface. Mainly they are used for two purposes: performing work in background outlasting the calling application and interaction among different processes. They can take two forms: started and bounded. Started services are started by another aplication component and run in background indefinetely even if the component that started is destroyed. Usually, a service is started to perform a single operation that does not return a result to the caller and it stops by itself when the operation completes. Other application components can bind to a service whether it was created by the same application or by another one. A bound service offers a client-server interface to interact with this service (known as IBinder), send requests and get results. Once the client component gets bound to the service it receives a stub implementation of the IBinder. Multiple components can bind to the service at once; the service is alive as long as other components are bound to it. To allow clients from different applications to access a service it is necessary to define the service interface using the Android Interface definition Language (AIDL).
The purpose of BroadcastReceiver is to enable application to react to system-wide events. Developers specify on the AndroidManifest which events the application receives and which individual BroadcastReceiver handles them. When an event needs to be broadcasted, the source application/hardware creates an event representing it with some additional information about it; Android notifies to any application component registered in the system through the Intent Re- solver invoking the onReceive method on the corresponding BroadcastReceiver implementations passing the intent as a parameter.
The last building block of Android applications are ContentProviders which their main pur- pose is to allow data sharing across different applications. ContentProviders represent centralized repositories of structured data with data access control (specify and enforce permissions). Ap- plications that want to access a particular ContentProvider do so through the ContentResolver class which presents a database-style interface that lets read and write data from and to a ContentProvider and supports methods such as query, insert, update and delete. To use a Con- tentResolver, applications identify the data they want and the content provider that hosts the data through a URI composed by a scheme (content://), an authority which indicates the specific ContentProvider, a path containing 0 or more segments indicating the specific dataset, and the ID indicating the specific record.
ContentProvider stores information such as bookmarks and browsing history; CALL LOG keeps track of the telephone calls; CONTACTS manages contact information; MEDIA keeps track of the pictures, songs and videos; and many more.
Sometimes applications need to squeeze extra performance from the device. In these cases, Android allows to build part of the application as a native library and write it in C or C++ and directly interact with the embedded devices of the mobile platform such as network interface, GPUs, accelerators or sensors. Developers dynamically load these libraries at any point of the code and they access to their functions through the Java Native Interface (JNI).
In addition to the code implementing the logic, applications are also include non-source code entities called resources; things like images, sound and video media, the layout of a screen or strings of characters. Managing them separately from the application code and using them properly has a significant impact on the portability of the application since they allow to alter the content shown to the user without need of changing the application or recompiling it. Choosing among different set of strings to be used allows applications to translate to any language. Providing a different layout for each device size or orientation (landscape or portrait) allows applications to adjust to the user interface to the current configuration. For applications to automatically adapt to the current configuration, Android requires the developer to classify the resources in a specific folder hierarchy according to their kind and the device configuration when they sould be used.