Android DRM Architecture

The DRM framework is designed to be implementation agnostic and abstracts the details of the specific DRM scheme implementation in a scheme-specific DRM plug-in. The DRM framework includes simple APIs to handle complex DRM operations, register users and devices to online DRM services, extract constraint information from the license, associate DRM content and its license, and finally decrypt DRM content.
The Android DRM framework is implemented in two architectural layers:

• A DRM framework API, which is exposed to applications through the Android application framework and runs through the Dalvik VM for standard applications.
• A native code DRM manager, which implements the DRM framework and exposes an interface for DRM plug-ins (agents) to handle rights management and decryption for various DRM schemes.

See the Android DRM package reference for additional details. Read more...

Read More

Android Camera Architecture

Android's camera HAL connects the higher level camera framework APIs in android.hardware to your underlying camera driver and hardware. The figure and list describe the components involved and where to find the source for each: 

Application framework

At the application framework level is the app's code, which utilizes the android.hardware.Camera API to interact with the camera hardware. Internally, this code calls a corresponding JNI glue class to access the native code that interacts with the camera.

JNI

The JNI code associated with android.hardware.Camera is located in frameworks/base/core/jni/android_hardware_Camera.cpp. This code calls the lower level native code to obtain access to the physical camera and returns data that is used to create the android.hardware.Camera object at the framework level.

Native framework

The native framework defined in frameworks/av/camera/Camera.cpp provides a native equivalent to the android.hardware.Camera class. This class calls the IPC binder proxies to obtain access to the camera service.

Binder IPC proxies

The IPC binder proxies facilitate communication over process boundaries. There are three camera binder classes that are located in the frameworks/av/camera directory that calls into camera service. ICameraService is the interface to the camera service, ICamera is the interface to a specific opened camera device, and ICameraClient is the device's interface back to the application framework.

Camera service

The camera service, located in frameworks/av/services/camera/libcameraservice/CameraService.cpp, is the actual code that interacts with the HAL.

HAL

The hardware abstraction layer defines the standard interface that the camera service calls into and that you must implement to have your camera hardware function correctly.

Kernel driver

The camera's driver interacts with the actual camera hardware and your implementation of the HAL. The camera and driver must support YV12 and NV21 image formats to provide support for previewing the camera image on the display and video recording.

Implementing the HAL

---

The HAL sits between the camera driver and the higher level Android framework and defines an interface that you must implement so that apps can correctly operate the camera hardware. The HAL interface is defined in the hardware/libhardware/include/hardware/camera.h and hardware/libhardware/include/hardware/camera_common.h header files.
camera_common.h defines an important struct, camera_module, which defines a standard structure to obtain general information about the camera, such as its ID and properties that are common to all cameras such as whether or not it is a front or back-facing camera.
camera.h contains the code that corresponds mainly with android.hardware.Camera. This header file declares a camera_device struct that contains a camera_device_ops struct with function pointers that point to functions that implement the HAL interface. For documentation on the different types of camera parameters that a developer can set, see the frameworks/av/include/camera/CameraParameters.h file. These parameters are set with the function pointed to by int (*set_parameters)(struct camera_device *, const char *parms) in the HAL.
For an example of a HAL implementation, see the implementation for the Galaxy Nexus HAL in hardware/ti/omap4xxx/camera.

Configuring the Shared Library

---

You need to set up the Android build system to correctly package the HAL implementation into a shared library and copy it to the appropriate location by creating an Android.mk file:

1. Create a device/<company_name>/<device_name>/camera directory to contain your library's source files.
2. Create an Android.mk file to build the shared library. Ensure that the Makefile contains the following lines: 

   LOCAL_MODULE := camera.<device_name>
   LOCAL_MODULE_RELATIVE_PATH := hw
   

   Notice that your library must be named camera.<device_name> (.so is appended automatically), so that Android can correctly load the library. For an example, see the Makefile for the Galaxy Nexus camera located in hardware/ti/omap4xxx/Android.mk.
   
3. Specify that your device has camera features by copying the necessary feature XML files in the frameworks/native/data/etc directory with your device's Makefile. For example, to specify that your device has a camera flash and can autofocus, add the following lines in your device's <device>/<company_name>/<device_name>/device.mk Makefile:

   PRODUCT_COPY_FILES := \ ...
   
   PRODUCT_COPY_FILES += \
   frameworks/native/data/etc/android.hardware.camera.flash-autofocus.xml:system/etc/permissions/android.hardware.camera.flash-autofocus.xml \    
   

   For an example of a device Makefile, see device/samsung/tuna/device.mk.
   
4. Declare your camera’s media codec, format, and resolution capabilities in device/<company_name>/<device_name>/media_profiles.xml and device/<company_name>/<device_name>/media_codecs.xml XML files. For more information, see Exposing Codecs and Profiles to the Framework for information on how to do this.
5. Add the following lines in your device's device/<company_name>/<device_name>/device.mk Makefile to copy the media_profiles.xml and media_codecs.xml files to the appropriate location:

   # media config xml file
   PRODUCT_COPY_FILES += \
       <device>/<company_name>/<device_name>/media_profiles.xml:system/etc/media_profiles.xml
   # media codec config xml file
   PRODUCT_COPY_FILES += \
       <device>/<company_name>/<device_name>/media_codecs.xml:system/etc/media_codecs.xml
   

6. Declare that you want to include the Camera app in your device's system image by specifying it in the PRODUCT_PACKAGES variable in your device's device/<company_name>/<device_name>/device.mk Makefile:
   

   PRODUCT_PACKAGES := \
   Gallery2 \
   ...
   

   Read more...

Read More

Android Bluetooth Architecture

Android provides a default Bluetooth stack, BlueDroid, that is divided into two layers: The Bluetooth Embedded System (BTE), which implements the core Bluetooth functionality and the Bluetooth Application Layer (BTA), which communicates with Android framework applications. A Bluetooth system service communicates with the Bluetooth stack through JNI and with applications through Binder IPC. The system service provides developers access to various Bluetooth profiles. The diagram shows the general structure of the Bluetooth stack: 

Application framework

At the application framework level is the app's code, which utilizes the android.bluetooth APIs to interact with the bluetooth hardware. Internally, this code calls the Bluetooth process through the Binder IPC mechanism.

Bluetooth system service

The Bluetooth system service, located in packages/apps/Bluetooth, is packaged as an Android app and implements the Bluetooth service and profiles at the Android framework layer. This app calls into the HAL layer via JNI.

JNI

The JNI code associated with android.bluetooth is located in packages/apps/Bluetooth/jni. The JNI code calls into the HAL layer and receives callbacks from the HAL when certain Bluetooth operations occur, such as when devices are discovered.

HAL

The hardware abstraction layer defines the standard interface that the android.bluetooth APIs and Bluetooth process calls into and that you must implement to have your bluetooth hardware function correctly. The header files for the Bluetooth HAL is located in the hardware/libhardware/include/hardware/bluetooth.h and hardware/libhardware/include/hardware/bt_*.h files.

Bluetooth stack

The default Bluetooth stack is provided for you and is located in external/bluetooth/bluedroid. The stack implements the generic Bluetooth HAL as well as customizes it with extensions and configuration changes.

Vendor extensions

To add custom extensions and an HCI layer for tracing, you can create a libbt-vendor module and specify these components.

Implementing the HAL

---

The Bluetooth HAL is located in the hardware/libhardware/include/hardware/ directory and consists of the following header files:

• bluetooth.h: Contains the HAL for the Bluetooth hardware on the device
• bt_av.h: Contains the HAL for the advanced audio profile.
• bt_hf.h: Contains the HAL for the handsfree profile.
• bt_hh.h: Contains the HAL for the HID host profile
• bt_hl.h: Contains the HAL for the health profile
• bt_pan.h: Contains the HAL for the pan profile
• bt_sock.h: Contains the HAL for the socket profile.

Keep in mind that your Bluetooth implementation is not constrained to the features and profiles exposed in the HAL. You can find the default implementation located in the BlueDroid Bluetooth stack in the external/bluetooth/bluedroid directory, which implements the default HAL and also extra features and customizations.

Customizing the BlueDroid Stack

---

If you are using the default BlueDroid stack, but want to make a few customizations, you can do the following things:

• Custom Bluetooth profiles - If you want to add Bluetooth profiles that do not have HAL interfaces provided by Android, you must supply an SDK add-on download to make the profile available to app developers, make the APIs available in the Bluetooth system process app (packages/apps/Bluetooth), and add them to the BlueDroid stack (external/bluetooth/bluedroid).
• Custom vendor extensions and configuration changes - You can add things such as extra AT commands or device-specific configuration changes by creating a libbt-vendor module. See the vendor/broadcom/libbt-vendor directory for an example.
• Host Controller Interface (HCI) - You can provide your own HCI by creating a libbt-hci module, which is mainly used for debug tracing. See the external/bluetooth/hci directory for an example. Read more...

Read More

Android Audio Architecture

Application framework

At the application framework level is the app code, which utilizes the android.media APIs to interact with the audio hardware. Internally, this code calls corresponding JNI glue classes to access the native code that interacts with the audio hardware.

JNI

The JNI code associated with android.media is located in the frameworks/base/core/jni/ and frameworks/base/media/jni directories. This code calls the lower level native code to obtain access to the audio hardware.

Native framework

The native framework is defined in frameworks/av/media/libmedia and provides a native equivalent to the android.media package. The native framework calls the Binder IPC proxies to obtain access to audio-specific services of the media server.

Binder IPC

The Binder IPC proxies facilitate communication over process boundaries. They are located in the frameworks/av/media/libmedia directory and begin with the letter "I".

Media Server

The audio services in the media server, located in frameworks/av/services/audioflinger, is the actual code that interacts with your HAL implementations.

HAL

The HAL defines the standard interface that audio services call into and that you must implement to have your audio hardware function correctly. The audio HAL interfaces are located in hardware/libhardware/include/hardware. See <hardware/audio.h> for additional details.

Kernel Driver

The audio driver interacts with the hardware and your implementation of the HAL. You can choose to use ALSA, OSS, or a custom driver of your own at this level. The HAL is driver-agnostic. Note: If you do choose ALSA, we recommend using external/tinyalsa for the user portion of the driver because of its compatible licensing (The standard user-mode library is GPL licensed).

Not shown: Android native audio based on OpenSL ES. This API is exposed as part of Android NDK, and is at the same architecture level as android.media. Read more...

Read More

Android Architecture

To start an Android user you may know how the fundamental function is such as making a call, sending a text message, changing the system settings, install and uninstall apps or setup and delete etc. Android users know these things but not enough for an android application developer. So, what else details are a developer required to know about Android. To be an android apps developer you should know all the key concepts of Android such as all the nuts and bolts of Android Operating System.

The illustration shows us the Android Architecture System. The Android OS can be referred to as a software stack of different layers, where each layer is a group of several  program components. Together it includes operating system, middle ware and important applications. Every layer in the architecture provides different types of services. The services are :

Linux Kernel

For the most part, developing your device drivers is the same as developing a typical Linux device driver. Android uses a specialized version of the Linux kernel with a few special additions such as wakelocks, a memory management system that is more agressive in preserving memory, the Binder IPC driver, and other features that are important for a mobile embedded platform like Android. These additions have less to do with driver development than with the system's functionality. You can use any version of the kernel that you want as long as it supports the required features, such as the binder driver. However, we recommend using the latest version of the Android kernel. For the latest Android kernel, see Building Kernels.

Libraries

The next layer is the Android’s native libraries. It is this layer that enables the device to handle different types of data. These libraries are written in c or c++ language and are specific for a particular hardware.

Some of the important native libraries include the following:

Surface Manager: It is used for compositing window manager with off-screen buffering. Off-screen buffering means you cant directly draw into the screen, but your drawings go to the off-screen buffer. There it is combined with other drawings and form the final screen the user will see. This off screen buffer is the reason behind the transparency of windows.

Media framework: Media framework provides different media codecs allowing the recording and playback of different media formats

SQLite: SQLite is the database engine used in android for data storage purposes

WebKit: It is the browser engine used to display HTML content

OpenGL: Used to render 2D or 3D graphics content to the screen

Android Runtime

Android Runtime consists of Dalvik Virtual machine and Core Java libraries.

Dalvik Virtual Machine
It is a type of JVM used in android devices to run apps and is optimized for low processing power and low memory environments. Unlike the JVM, the Dalvik Virtual Machine doesn’t run .class files, instead it runs .dex files. .dex files are built from .class file at the time of compilation and provides hifger efficiency in low resource environments. The Dalvik VM allows multiple instance of Virtual machine to be created simultaneously providing security, isolation, memory management and threading support. It is developed by Dan Bornstein of Google.

Core Java Libraries
These are different from Java SE and Java ME libraries. However these libraries provides most of the functionalities defined in the Java SE libraries.

Application Framework

These are the blocks that our applications directly interacts with. These programs manage the basic functions of phone like resource management, voice call management etc. As an android apps developer, you just consider these are some basic tools with which we are building our applications.

Important blocks of Application framework are:

Activity Manager: Manages the activity life cycle of applications

Content Providers: Manage the data sharing between applications

Telephony Manager: Manages all voice calls. We use telephony manager if we want to access voice calls in our application.

Location Manager: Location management, using GPS or cell tower

Resource Manager: Manage the various types of resources we use in our Application

Applications

Applications are the top layer in the Android architecture and this is where our applications are go to fit. Several standard applications comes pre-installed with every device, such as:

• SMS client app
• Dialer
• Web browser
• Contact manager

As an android application developer we are able to write an app which replace any existing system app. That is, you are not limited in accessing any particular feature. You are practically limitless, and you can do whatever you want to do with the android. Android is an opening endless opportunities to the android application developer.

Read More