Android System Programming

Roger Ye

• Editorial: Packt Publishing
• Año: 2017
• ISBN:
  9781787120389
• Edición: 1
• Categoría: Computer Science
• Categoría: Programming Mobile Devices

Build, customize, and debug your own Android systemAbout This Book• Master Android system-level programming by integrating, customizing, and extending popular open source projects• Use Android emulators to explore the true potential of your hardware• Master key debugging techniques to create a hassle-free development environmentWho This Book Is ForThis book is for Android system programmers and developers who want to use Android and create indigenous projects with it. You should know the important points about the operating system and the C/C++ programming language.What You Will Learn• Set up the Android development environment and organize source code repositories• Get acquainted with the Android system architecture• Build the Android emulator from the AOSP source tree• Find out how to enable WiFi in the Android emulator• Debug the boot up process using a customized Ramdisk• Port your Android system to a new platform using VirtualBox• Find out what recovery is and see how to enable it in the AOSP build• Prepare and test OTA packagesIn DetailAndroid system programming involves both hardware and software knowledge to work on system level programming. The developers need to use various techniques to debug the different components in the target devices. With all the challenges, you usually have a deep learning curve to master relevant knowledge in this area. This book will not only give you the key knowledge you need to understand Android system programming, but will also prepare you as you get hands-on with projects and gain debugging skills that you can use in your future projects.You will start by exploring the basic setup of AOSP, and building and testing an emulator image. In the first project, you will learn how to customize and extend the Android emulator. Then you'll move on to the real challenge—building your own Android system on VirtualBox. You'll see how to debug the init process, resolve the bootloader issue, and enable various hardware interfaces. When you have a complete system, you will learn how to patch and upgrade it through recovery. Throughout the book, you will get to know useful tips on how to integrate and reuse existing open source projects such as LineageOS (CyanogenMod), Android-x86, Xposed, and GApps in your own system.Style and approachThis is an easy-to-follow guide full of hands-on examples and system-level programming tips.

Enabling Graphics

In the last chapter, we learnt how to boot the x86vbox device using PXE and NFS. We can boot the device to an embedded Linux environment, which is the first stage of the Android-x86 boot. In this stage, we can use a debug console to verify the status of the system so that we can make sure everything is right before we start the real Android system. In this chapter, we will talk about the first issue we meet during Android system boot up. This is about how to enable the Android graphics system for the x86vbox device. We will cover the following topics in this chapter:

• Overview of Android graphics architecture
• Delving into graphics HAL
• Analyzing the Android emulator graphics HAL for comparison

The graphics system probably is the most complicated software stack in the Android system architecture.
As you will see, the content in this chapter is much longer than the rest. Reading and understanding the content in this chapter may be harder. What I suggest is that you can open a source code editor and load the relevant source code while you read this chapter. This will help you a lot to understand the source code and the points that I want to address in this chapter.

Introduction to the Android graphics architecture

The graphics system in Android is similar to the architecture that we discussed in Chapter 3, Discovering Kernel, HAL, and Virtual Hardware. There we used goldfish lights HAL as an example to do a detailed analysis from the application level to the HAL and device driver layer. This analysis helps us to understand the Android architecture vertically.

However, the graphics system could be the most complicated system in the Android architecture. It would require another book to give a detailed introduction to the Android graphics system. The focus of this book is on how we can port Android systems to a new hardware platform. To focus on this goal, we will address the graphics HAL in this chapter instead of discussing the entire graphics system. The graphics system will work if we can choose the right graphics HAL and configure it right.

According to Google documents about the implementation of graphics, Android graphics support requires the following components:

• EGL driver
• OpenGL ES 1.x driver
• OpenGL ES 2.0 driver
• OpenGL ES 3.x driver (optional)
• Vulkan (optional)
• Gralloc HAL implementation
• Hardware Composer HAL implementation

In the preceding list, OpenGL ES implementation is the most complicated component in the graphics system. We will discuss how it is chosen and integrated in an Android emulator and Android-x86. We won't go into the details of how to analyze the OpenGL ES implementation, but we will have an overview about the underlying OpenGL ES libraries. OpenGL ES 1.x and 2.0 must be supported in an Android system. OpenGL ES 3.x is an optional component at the moment. EGL driver is usually implemented as part of the OpenGL ES implementation and we will see this when we discuss the Android emulator and Android-x86 (x86vbox) graphics system.

Vulkan is a new generation of GPU API from Khronos Group. Vulkan is new and optional and was only introduced in Android 7. Covering Vulkan is beyond the scope of this book, so we won't discuss it. Gralloc HAL is the one that handles the graphics hardware and it is our focus for a deep analysis. In most of the porting work of the graphics system, Gralloc HAL is the key to enabling graphics.

Hardware composer is part of the graphics HAL. However, it is not a component that we must have for Android emulator or Android-x86. The Hardware Composer (HWC) HAL is used to composite surfaces to the screen. The HWC abstracts objects such as overlays and helps offload some work that would normally be done with OpenGL.

Android graphics architecture

As we can see from the preceding Android graphics architecture diagram, we can also divide related components into different layers in the Android architecture as we did in previous chapters. This architecture diagram is a simplified view of a graphics system. SurfaceFlinger is the system service to the application layer for graphics-related system support. SurfaceFlinger will connect to the OpenGL ES library and HAL layer components to perform the actual work. In the HAL, we have HWC, gralloc, and a vender-specific GPU library that will talk to the drivers in the kernel space.

Delving into graphics HAL

After we have an overview of graphics system architecture, we will analyze the Gralloc module, which is the graphics HAL. In the AOSP source code, the skeleton of Gralloc HAL implementation can be found at the following folder:

$AOSP/hardware/libhardware/modules/gralloc

This is a general implementation that provides a reference for developers to create their own Gralloc module. Gralloc will access framebuffer and GPU to provide services to the upper layer. In this section, we will analyze this general implementation first. After the analysis of this general Gralloc HAL module, we will introduce the Gralloc HAL of the Android emulator.

Loading the Gralloc module

When application developers draw images to the screen, there are two ways to do it. They can use Canvas or OpenGL. Beginning in Android 4.0, both methods use hardware acceleration by default. To use hardware acceleration, we need to use Open GL libraries and eventually the Gralloc module will be loaded as part of the graphics system initialization. As we saw in Chapter 3, Discovering Kernel, HAL, and Virtual Hardware, each HAL module has a reference ID that can be used by the hw_get_module function to load it to memory. The hw_get_module function is defined in the $AOSP/hardware/libhardware/hardware.c file:

 int hw_get_module(const char *id, const struct hw_module_t **module) 
{ 
 return hw_get_module_by_class(id, NULL, module); 
} 

In hw_get_module, it actually calls another function, hw_get_module_by_class, to do the work:

 int hw_get_module_by_class(const char *class_id, const char *inst, 
 const struct hw_module_t **module) 
{ 
 int i = 0; 
 char prop[PATH_MAX] = {0}; 
 char path[PATH_MAX] = {0}; 
 char name[PATH_MAX] = {0}; 
 char prop_name[PATH_MAX] = {0}; 


 if (inst) 
 snprintf(name, PATH_MAX, "%s.%s", class_id, inst); 
 else 
 strlcpy(name, class_id, PATH_MAX); 

 snprintf(prop_name, sizeof(prop_name), "ro.hardware.%s", name); 
 if (property_get(prop_name, prop, NULL) > 0) { 
 if (hw_module_exists(path, sizeof(path), name, prop) == 0) { 
 goto found; 
 } 
 } 

 for (i=0 ; i<HAL_VARIANT_KEYS_COUNT; i++) { 
 if (property_get(variant_keys[i], prop, NULL) == 0) { 
 continue; 
 } 
 if (hw_module_exists(path, sizeof(path), name, prop) == 0) { 
 goto found; 
 } 
 } 

 /* Nothing found, try the default */ 
 if (hw_module_exists(path, sizeof(path), name, "default") == 0) { 
 goto found; 
 } 

 return -ENOENT; 

found: 
 return load(class_id, path, module); 
} 

In the preceding function, it tries to find the Gralloc module shared library using the following names in /system/lib/hw or /vendor/lib/hw:

 gralloc.<ro.hardware>.so 
gralloc.<ro.product.board>.so 
gralloc.<ro.board.platform>.so 
gralloc.<ro.arch>.so 

If any of the preceding files exist, they will call the load function to load the shared library. If none of them exist, a default shared library, gralloc.default.so, will be used. The hardware module ID for Gralloc is defined in the gralloc.h file as follows:

 #define GRALLOC_HARDWARE_MODULE_ID "gralloc" 

The load function will call dlopen to load the library and will ca...