Android Study Guide

1.1.1 Complete, Open, Free

• Complete — Android is a complete platform with a secure Linux operating system at its base and a robust Java-based software framework which allows for the development of powerful mobile applications.
• Open — The Android platform is open source. Device manufacturers can create custom Android implementations for their devices, and app developers have unprecedented access to device features in their applications.
• Free — Neither developers nor device manufacturers pay royalties or licensing fees to develop for the platform.

1.1.2 What Android Is

• A free open-source operating system for embedded devices (i.e., an object that contains a special-purpose computing system like cellphones, point-of-sale terminals, ATMs, household appliances, etc.).
• An open source development platform for creating applications.
• Devices which run the Android operating system and applications created for it.

Android is made up of several necessary and dependent parts, including:

• A Compatibility Definition Document (CDD) and Compatibility Test Suite (CTS) — which describe the capabilities required for a device to support the software stack.
• A Linux operating system kernel— which provides a low-level interface with the hardware, memory management, and process control, all optimized for mobile and embedded devices.
• Open-source libraries for application development— including SQLite, WebKit, OpenGL, and a media manager.
• A run time used to execute and host Android applications—For devices running Android version 5.0 (API level 21) or higher, each app runs in its own process and with its own instance of the Android Runtime (ART). Previous versions of Android utilized the Dalvik VM (DVM).
• An application framework— which agnostically exposes system services to the application layer, including the window manager and location manager, databases, telephony, and sensors.
• A user interface framework— which is used to host and launch applications.
• A set of core pre-installed applications— Android devices ship with certain "core" apps including an email client, SMS management application, PIM (personal Information Management) app (e.g, claendar, contact list, etc.), a Webkit-based web browser, a music player and picture gallery, camera, etc.
• A software development kit (SDK)—used by developers to create applications, including the related tools, plug-ins, and documentation.

1.1.3 What Android Isn't

• A Java ME implementation — Android applications are written in Java, but they are not run with the Java Mobile Edition Virtual Machine (VM). Android has its own custom VM.
• Simply an application layer (e.g., Nokia's UIQ or S60) — Android includes an application layer, but it also encompasses the underlying operating system, API libraries, and the applications themselves.
• A mobile phone handset— Android includes a reference design for device manufacturers, with some devices running close to "pure" implementations of the Android operating system (e.g., Nexus and Pixel). But Android is designed to support many different hardware devices.
• Google's Answer to the iPhone— iPhone is a fully proprietary hardware and software platform. iPhone apps run only on Apple's iPhone and custom implementations of iPhone software are not supported. Android, on the other hand, is an open-source software stack produced and supported by the open handset alliance (OHA) and designed to operate on many devices.

1.1.4 Android Open Source Project

The Android Open Source Project (AOSP) is an initiative led by Google that makes the source code of the Android Operating System available to read, review, and modify.

1.1.5 Android Open Handset Alliance

The Open Handset Alliance (OHA) is a business alliance which includes many of the largest device manufacturers, chip makers, software developers and service providers. Membership in the OHA allows companies license (and include on Android devices) Google Mobile Services (GMS) which includes proprietary Google mobile apps like Google Play, YouTube, Google Maps, and Gmail.

1.2.1 The Linux Kernel

The foundation of the Android platform is the Linux Kernel. For example, the Android Runtime (ART) relies on the Linux kernel for underlying functionalities such as threading and low-level memory management.

Using a Linux kernel allows Android to take advantage of key security features and allows device manufacturers to develop hardware drivers for a well-known kernel.

1.2.2 Hardware Abstraction Layer

The Hardware Abstraction Layer (HAL) provides standard interfaces that expose device hardware capabilities to the higher-level Java API framework. The HAL consists of multiple library modules, each of which implements an interface for a specific type of hardware component, such as the camera or bluetooth module. When a framework API makes a call to access device hardware, the Android system loads the library module for that hardware component.

1.2.3 Android Runtime

For devices running Android version 5.0 (API level 21) or higher, each app runs in its own process and with its own instance of the Android Runtime (ART). ART is written to run multiple virtual machines on low-memory devices by executing DEX files, a bytecode format designed specially for Android that's optimized for minimal memory footprint. Build toolchains, such as Jack, compile Java sources into DEX Bytecode, which can run on the Android platform.

Some of the major features of ART include the following:

• Ahead-of-time (AOT) and just-in-time (JIT) compilation
• Optimized garbage collection (GC)
• Better debugging support, including a dedicated sampling profiler, detailed diagnostic exceptions and crash reporting, and the ability to set watchpoints to monitor specific fields
• Prior to Android version 5.0 (API level 21), Dalvik was the Android runtime. If your app runs well on ART, then it should work on Dalvik as well, but the reverse may not be true.

Android also includes a set of core runtime libraries that provide most of the functionality of the Java programming language, including some Java 8 language features, that the Java API framework uses.

ART is an improvement over DVM due to the use of AOT or Ahead-of-time Compilation vs DVMs just-in-time or JIT approach. AOT allows apps to be compiled on installation rather than every time the app is launched which improves app performance and saves battery life. (note: both AOT and JIT are used as of in Android 7.0 to achieve the "best of both worlds" with regard to app speed, system performance and use of storage space).

More Info: ART and Dalvik

1.2.4 Native C/C++ Libraries

Many core Android system components and services, such as ART and HAL, are built from native code that require native libraries written in C and C++. The Android platform provides Java framework APIs to expose the functionality of some of these native libraries to apps. For example, you can access OpenGL ES through the Android framework’s Java OpenGL API to add support for drawing and manipulating 2D and 3D graphics in your app. Additional Native Libraries include: SQLite for databases, the Media Framework, Webkit, and the libc C library

If you are developing an app that requires C or C++ code, you can use the Android NDK to access some of these native platform libraries directly from your native code.

1.2.5 Java API Framework

The entire feature-set of the Android OS is available to you through APIs written in the Java language. These APIs form the building blocks you need to create Android apps by simplifying the reuse of core, modular system components and services, which include the following:

• A rich and extensible View System you can use to build an app’s UI, including lists, grids, text boxes, buttons, and even an embeddable web browser
• A Resource Manager, providing access to non-code resources such as localized strings, graphics, and layout files
• A Notification Manager that enables all apps to display custom alerts in the status bar
• An Activity Manager that manages the lifecycle of apps and provides a common navigation back stack
• Content Providers that enable apps to access data from other apps, such as the Contacts app, or to share their own data

1.2.6 System Apps or Application Layer

Android comes with a set of core apps for email, SMS messaging, calendars, internet browsing, contacts, and more. Apps included with the platform have no special status among the apps the user chooses to install. So a third-party app can become the user's default web browser, SMS messenger, or even the default keyboard (some exceptions apply, such as the system's Settings app).

The system apps function both as apps for users and to provide key capabilities that developers can access from their own app. For example, if your app would like to deliver an SMS message, you don't need to build that functionality yourself—you can instead invoke whichever SMS app is already installed to deliver a message to the recipient you specify.

1.3.1 Android Platform Versions and Android APIs

The Android Platform Version (e.g., Android 7.1 Nougat, Android 6 Marshmallow, etc.) refers to a particular version of the Android operatng system (think: the OS as it exists on Android devices—devices are said to run particular versions of Android). Each Andoid Version is given a dessert-themed nickname.

The Android Platform provides a Framework API that applications can use to interact with the underlying Android system. The Framework API includes:

• A core set of packages and classes
• A set of XML elements and attributes for declaring a manifest file
• A set of XML elements and attributes for declaring and accessing resources
• A set of Intents
• A set of permissions that applications can request, as well as permission enforcements included in the system

The API Level is always a single integer and you cannot derive the API Level from its associated Android version number (for example, it is not the same as the major version or the sum of the major and minor versions)

Updates to the framework API are designed so that the new API remains compatible with earlier versions of the API.

Each Android Platform Version supports exactly one API Level.

For information about the relative numbers of devices that are running each version, see the Platform Versions Dashboards Page.

1.3.2 Android SDK

The Android SDK includes several tools and utilities to help you create, test, and debug your projects. The SDK download comes with the base tools and additional packages are downloaded via the SDK Manager. In order to start developing applications, you must install the Platform-tools and at least one version of the Android platform.

1.3.3 Development Tools

• The Android Virtual Device and SDK Managers – Used to create and manage AVDs and to download SDK packages, respectively. The AVD hosts an Emulator running a particular build of Android, letting you specify the supported SDK version, screen resolution, amount of SD card storage available, and available hardware capabilities (such as touchscreens and GPS). See : Android Studio Docs: Create And Manage Virtual Devices.
• The Android Emulator – An implementation of the Android VM designed to run within an AVD on your development computer. Use the Emulator to test and debug your Android applications.
• Dalvik Debug Monitoring Service (DDMS) – Use the DDMS to monitor and control the Emulators on which you’re debugging your applications.
• Android Debug Bridge (ADB) – A client-server application that provides a link to virtual and physical devices. It lets you copy files, install compiled application packages (.apk), and run shell commands. You can find the adb tool in android_sdk/platform-tools/. See : Android Studio Docs: Android Debug Bridge.
• Logcat – A utility used to view and filter the output of the Android logging system.
• Android Asset Packaging Tool (AAPT) – Constructs the distributable Android package files (.apk).
• SQLite3 – A database tool that you can use to access the SQLite database files created and used by Android.
• Traceview and dmtracedump – Graphical analysis tools for viewing the trace logs from your Android application.
• Hprof-conv – A tool that converts HPROF profiling output files into a standard format to view in your preferred profiling tool.
• MkSDCard – Creates an SD card disk image that can be used by the Emulator to simulate an external storage card.
• Dx – Converts Java .class bytecode into Android .dex bytecode.
• Hierarchy Viewer – Provides both a visual representation of a layout’s View hierarchy to debug and optimize your UI, and a magnified display to get your layouts pixel-perfect.
• Draw9patch – A handy utility to simplify the creation of NinePatch graphics using a WYSIWYG editor.
• Monkey and Monkey Runner – Monkey runs within the VM, generating pseudo-random user and system events. Monkey Runner provides an API for writing programs to control the VM from outside your application.
• ProGuard – A tool to shrink and obfuscate your code by replacing class, variable, and method names with semantically meaningless alternatives. This is useful to make your code more difficult to reverse engineer.

1.3.4 Documentation

Android development is assisted by an ever-growing library of documentation. SDK docs are available online and can also be downloaded from the SDK Manager. They will be located in, for example, [Username]/AppData/Local/Android/sdk/docs/index.html

• Android API Guides A List of guides which teach developers how to build apps using Android APIs.
• Android Studio User Guide

1.4.1 Activity

An activity is the entry point for interacting with the user.

• Think of an Activity as a single screen with a user interface.
• Activities can start each other–even across applications (e.g., a camera app can start the activity in the email app that composes new mail to allow the user to share a picture).

An activity facilitates the following key interactions between system and app:

• Keeping track of what the user currently cares about (what is on screen) to ensure that the system keeps running the process that is hosting the activity.
• Knowing that previously used processes contain things the user may return to (stopped activities), and thus more highly prioritize keeping those processes around.
• Helping the app handle having its process is killed so the user can return to activities with their previous state restored.
• Providing a way for apps to implement user flows between each other, and for the system to coordinate these flows. (The most classic example here being share.)

You implement an activity as a subclass of the Activity class. For more information about Activity in the Activities developer guide.

1.4.2 Service

A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.

• Used for long-running operations (e.g., database work, accessing the internet, or reading a file).
• A Service does not provide a user interface.
• Another application component can start a service, and it continues to run in the background even if the user switches to another application.

A service is implemented as a subclass of Activity. For more information about the Service class, see the Services developer guide.

1.4.3 BroadcastReceiver

A Broadcast Receiver listens for Broadcast Intents and allows the app to respond to system-wide broadcast announcements.

• The system can deliver broadcasts even to apps that aren't currently running.
• Broadcasts can originate from the system (e.g., screen turned off, battery low, picture captured), or from individual apps.

A broadcast receiver is implemented as a subclass of BroadcastReceiver and each broadcast is delivered as an Intent object. For more information, see the BroadcastReceiver class.

1.4.4 ContentProvider

A content provider manages a shared set of app data that you can store in the file system, in a SQLite database, on the web, or on any other persistent storage location that your app can access.

• Other apps can query or modify the data if the content provider allows it.
• The data the Content Provider provides is identified by a URI scheme.
• Content providers can read and write data that is private to your app and not shared. For example, the Note Pad sample app uses a content provider to save notes.

A content provider is implemented as a subclass of ContentProvider and must implement a standard set of APIs that enable other apps to perform transactions. For more information, see the Content Providers developer guide.