Introducing the Android OS

- [Instructor] Android was first released by Google in 2008. And is based on the Linux 2.6 kernel. Includes a Java programming interface, and typically runs on an ARM processor. The Android operating systems have whimsical names. With the Android 4.0 release being called Jellybean. And the later 4.1 release, Kitkat. Android 5 is known as Lollipop and Android 6, Marshmallow. Many older mobile devices are still in regular use and manufacturers will often deploy older versions of Android on their newer models.

Kitkat is still commonly seen on current model phones. Google provides an open source platform. But individual phone manufacturers incorporate proprietary code within their deployments. Consequently, there are some differences between different manufacturers. However, the tools and techniques for hardening we'll cover, are common across manufacturers. Android doesn't introduce a completely new security model but builds on the Linux security model. With enhancements appropriate to the mobile environment.

One of the main changes is making security application centric rather than user centric. Allowing for proper sandboxing of applications. New security features are often included in new release of Android. And we'll look at the latest development techniques that can be used on newer devices. An Android mobile device consists of a hardware platform. On top of which is the Android implementation of the Linux kernel. And above that, the Android runtime environment and libraries.

Pre-installed and user installed applications Typically in Java. Then run in the runtime environment and use the application framework for accessing user level system resources. The Linux kernel is the core part of the operating system that mediates access to system resources. It's responsible for enabling multiple applications to effectively share the hardware by controlling access to CPU, memory, disc IO, and networking. In addition to the kernel, the operating system contains the range of high level features such as editor's command line and graphical shells, compilers, and so on.

An Android system, while it's based on the Linux kernel, is sufficiently different in most other respects that a Linux application won't run on Android. And an Android application won't run on Linux. Early Android releases use the Dalvik virtual machine to run applications written in Java and provide system calls through the Android Application Programming Interfaces or APIs. It doesn't run Java compiled by code directly but runs an optimized .dex formats. More recently, from Android 5.0 onwards.

The Android runtime has replaced the Dalvik virtual machine. This uses native instructions to provide better performance and lower power consumption. For compatibility however, it uses .dex format applications and converts them to native instructions when the app is installed. Android provides a Linux-like shell but it doesn't have the standard tools that come with Linux releases. The toolbox was originally provided for application use. But this was limited and third-party tools like Busybox are often installed by testers to add these capabilities to Android.

From Android 6.0 onwards, Toolbox has been replaced by Toybox. Toolbox includes familiar Linux command such as cat, chmod, cp, grep, ls, mkdir, and many more. The Landley webpage shown here provides the status and roadmap for Toybox. In order to test mobile applications, we need to understand how an Android application is generated and deployed and the role of its component parts. An Android application is delivered as a package with a .apk extension.

I've downloaded an app called pego to my testing folder. While this isn't recognized in Windows, it is in fact a zip archive. I've changed the appication extension and renamed the file Peggo.zip. Let's have a look at it. In the zip file, or apk file as it was, we can see a number folders and files. The main executable is called classes.dex. .dex is the extension used for a Dalvik executable file format which includes the executable code and the source code.

we also have a classes2.dex file. Multiple dex files are used when the size of a single file exceeds that's allowed in the Dalvik executable specification. The package also contains a file called AndroidManifest.xml which is a source of useful information regarding the applications characteristics and planned interactions. It also contains a number of subdirectories with additional resources and libraries needed by the application. An application in Android is different in a number of ways from a traditional computer application.

It's a loosely coupled sets of components rather than a tightly coupled executable. Unlike other operation systems, the user ID in Android doesn't represent the user but rather an application. The most common component is an activity which has a user interface and typically interacts with the user. Android also provides for a service which have no graphical user interface and is typically used for long running background tasks. In addition, there are two forms of helper routines.

The first is a broadcast receiver which allows the application to register for specific events. And which will then be passed to it for action. The second is a content provider which interfaces between an application and file storage. And provides an SQlite interface to read, write, modify, and delete data. SQlite is a common database service accessed via a content provider. Another key concept in Android is intents.

These are objects used to manage requests and include an action and irrelevant data for the request being made. And intent is used to start an activity to start a service, what to send to broadcast. An application can register to listen for an intent activity request by including it in its manifest file. And intent can explicitly define its target application or can let the system identify the application or application's able to respond. If there's more than one, Android will display an application picker.

Applications can export activities and these can then be accessed by application to application intents. Applications can also access broadcast receivers and content providers exported by other applications.