Instant Android Systems Development How-to

You need Ubuntu 10.04 LTS or later (Mac OS X is also supported by the build system, but we will be using Ubuntu for this book). This is the supported build operating system, and the one for which you will get the most help from the online community. In my examples, I use Ubuntu 11.04, which is also reasonably well supported. You need approximately 6 GB of free space for the Android code files. For a complete build, you need 25 GB of free space. If you are using Linux in a virtual machine, make sure the RAM or the swap size is at least 16 GB, and you have 30 GB of disk space to complete the build.

As of Android Versions 2.3 (Gingerbread) and later, building the system is only possible on 64-bit computers. Using 32-bit machines is still possible if you work with Froyo (Android 2.2). However, you can still build later versions on a 32-bit computer using a few "hacks" on the build scripts that I will describe later.

The following steps outline the process needed to set up a build environment and compile the Android framework and kernel:

In general, your (Ubuntu Linux) build computer needs the following:

We will first set up the build environment with the help of the following steps:

Next, we describe the steps needed to build the Android framework sources:

This will obtain the kernel code:

Following are the steps required to build the framework on a 32-bit system:

The Android build system is a combination of several standard tools and custom wrappers. Repo is one such wrapper script that takes care of GIT operations and makes it easier for us to work with the Android sources.

The kernel trees are maintained separately from the framework source trees. Hence, if you need to make customizations to a particular kernel, you will have to download and build it separately. The keen reader may be wondering how we are able to run the emulator if we never built a kernel in when we just compiled the framework. Android framework sources include prebuilt binaries for certain targets. These binaries are located in the /prebuilt directory under the framework source root directory.

The kernel build process is more or less the same as building kernels for desktop systems. There are only a few Android-specific compilation switches, which we have shown to be easily configurable given an existing configuration file for the intended target.

The sources consist of C/C++ and Java code. The framework does not include the kernel sources, as these are maintained in a separate GIT tree. In the next recipe, we will explain the framework code organization. It is important to understand how and where to make changes while developing custom builds.

You need to use a suitable code editor/viewer. I usually make use of gedit with several code-related options enabled. Some people prefer to use vi, emacs, or Eclipse. Use whatever you are comfortable with to view the sources.

As you read the following table, refer to the directories of your Android source copy and feel free to explore the subdirectories. The top level folders are as follows:

All of these subdirectories are part of the Android framework (note that they also contain code which is not exactly part of the framework such as the code under /system, but the definition of what exactly is in the framework can be relaxed a bit). During a system build, most of these are pulled together with the help of Android make files that exist in these directories. Creating new folders is not advised, since all vendor-specific code can be added under the /vendor directory (not shown earlier). This directory is created when you build for a particular device and it contains proprietary binaries among other things, such as vendor-specific framework code.

Keep your code editor/viewer ready, as we will open a lot of source files and inspect their contents.

There are three major phases for the bootup of an Android Phone, which are as follows:

Android has a specific init language, which is described in detail at the following location in the Android sources:

ANDROID_SRC/system/core/init/readme.txt

Following this, there is a startup procedure for Zygote and system_server.

The following extract from init.rc is the initialization of Zygote:

service zygote /system/bin/app_process -Xzygote /system/bin --zygote –start-system-server

Here, app_process is a binary that fires up the zygote process during system initialization. The last flag (--start-system-server) indicates that the system_server process is to be started. The system_server process encompasses all the core services provided by the Android platform. Examples are the ActivityManagerService, LocationManagerService, and so on.

The app_process binary invokes the functionality of AndroidRuntime, which is the entry point to start the dalvik environment; AndroidRuntime.cpp is located at ANDROID_SRC/frameworks/base/core/jni/.

The app_process binary's code eventually comes down to the following in AndroidRuntime.cpp:

void AndroidRuntime::start(const char* className, const bool startSystemServer)

This then calls int AndroidRuntime::startVm(JavaVM** pJavaVM, JNIEnv** pEnv).

The preceding line of code then loads the DVM into the native process, and results in a call to the main method of ZygoteInit.java located at ANDROID_SRC/frameworks/base/core/java/com/android/internal/os.

The ZygoteInit.main() method is invoked, which causes the invocation of startSystemServer in that file. This method passes command-line arguments to the system server. An extract is shown as follows:

String args[] = { 
            "--setuid=1000", 
            "--setgid=1000", 
            "--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,3001,3002,3003",
            "--capabilities=130104352,130104352", 
            "--runtime-init", 
            "--nice-name=system_server", 
            "com.android.server.SystemServer", 
        };

After starting the system server (details to follow), the zygote socket is set up and then the process runs in "select loop mode". In this mode, the process spins waiting for requests to start up new Android processes.

We will now take a look at the system_server startup process. The code for this process can be located at frameworks/base/services/java/com/android/server/SystemServer.java.

There are two methods called during startup, one of which is shown here:

native public static void init1(String[] args);

This method is called by zygote (as we have seen earlier), and its job is to initialize native services which exist in the android_servers native object file. Examples of these native services are SurfaceFlinger, AudioFlinger, and so on. The init1() method is implemented at ANDROID_SRC/frameworks/base/cmds/system_server/library/system_init.cpp.

The init1() method bootstraps init2 via the following line in system_init.cpp:

runtime->callStatic("com/android/server/SystemServer", "init2");

Now, the execution is back inside SystemServer.java, and init2 is run. It creates a thread and then proceeds to start up system servers.

An example start sequence for the servers is as follows (based on Gingerbread 2.3.4_r1):

This code can be seen inside the run() method of SystemServer.java. Once the ActivityManagerService class is started (and boot is completed), the first few Android applications are started up, as shown here:

com.android.phone – The phone app.
android.process.acore – The home screen and core apps.

The complete booting system sequence is shown in the following diagram:

We will now take a look at some pointers on good and secure code style to be followed when writing code for Android.

We will write the code at ANDROID_SRC/frameworks/base/core/java/android/os/packt. The code is written at this location because it follows the conventions of Android systems coding and, more importantly, the build system is designed to automatically pick up files from these pre-known locations. Hence, to avoid modifications to the build system, we write our code at standard locations. Another reason is that since we are writing framework-level extensions, they have to be tightly integrated with the framework, and the above location is where all such code is written.

Create a directory called packt under /os. This helps us to better organize the code and easily distinguish custom code from framework code. This is important since you are modifying an already tested open source system. Simply due to the sheer size of Android, making indiscriminate changes to the code can introduce really hard-to-find bugs. Hence, having a clear separation between newly added code and framework code is a good practice.

The following code represents the Android interface definition of the system service. It specifies the methods that are exposed by the service for use by clients.

Our example exposes a single method named getMD5(String) that calculates the MD5 hash for the input parameter.

Save the following code file as IPacktCrypto.aidl:

package android.os.packt; 

interface IPacktCrypto 
{ 
  byte [] getMD5(String data); 
}

We have to communicate this new file to the build system. This is done by adding the following line to the LOCAL_SRC_FILES entry in the Android.mk file located at ANDROID_SRC/frameworks/base.

Scroll to the LOCAL_SRC_FILES directive. The last few lines should look like the following (GingerBread 2.3.4_r1):

…
voip/java/android/net/sip/ISipSessionListener.aidl \ 
voip/java/android/net/sip/ISipService.aidl \ 
core/java/android/os/packt/IPacktCrypto.aidl

Notice that we have specified our newly added interface definition file. Inclusion of the filename here results in the invocation of the AIDL compiler on the file to generate the proxy and stub classes (the proxy/stub classes contain marshalling code).

Proxy/stub marshalling code is needed because the system server runs in its own process. Thus, to invoke its functions from other processes, you need an intermediate layer that marshals calls from one process to another. In case of Android, generated stub/proxy classes constitute this layer.

The AIDL file has to be compiled by the build system with the help of the AIDL compiler. Therefore, we list the name of our file towards the end of the existing framework files in the make file. When the system is being built, AIDL will be invoked on IPacktCrypto.aidl, and will result in the generation of proxy and stub classes. These classes are generated at android_src/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/src/core/java/android/os.

We will add our system server code to ANDROID_SRC/frameworks/base/services/java/com/android.

Create a directory called packt at the preceding location. Inside that directory, create a file named PacktCrypto.java.

Traditionally, proxy classes represent the code component that executes on the client side of a remote request. Likewise, stubs execute on the server side. Therefore, our system server extends IPacktCrypto.Stub, which was generated during the build process from the IPacktCrypto.aidl file. We also have to implement the getMD5() interface method as it will provide the required functionality to the client. We choose to utilize the singleton pattern for our service to guarantee that only one object of the service exists in the system. This makes sense, since only one copy of the system service may exist in the service directory.

We will add our custom server to SystemServer.java located at ANDROID_SRC/frameworks/base/services/java/com/android/server.

The following code represents modifications you need to make to the SystemServer.java file. Locate the run() method and add the following lines at an appropriate location. For the purpose of illustration, we choose to add this after all services have been started.

...
//begin packt 
Slog.i(TAG, "PacktCrypto service"); 
com.android.packt.PacktCrypto pcrypt = com.android.packt.PacktCrypto.getInstance(); 
ServiceManager.addService("PacktCryptoService", pcrypt); 
//end packt
…

The preceding code modification obtains a reference to an object of type PacktCrypto. It then adds that object to the ServiceManager class, which, if you recall, is a directory service for all system services. It adds the PacktCrypto object to the directory by invoking the addService() method that takes as arguments a string service identifier and the object itself.

In the code fragment, we must create an object of PacktCrypto and add it to the Service Manager directory with a string name. We choose PacktCryptoService for our example. At this stage, our custom server will be created and registered with the Service Manager.

Write the following test code inside SystemServer.java itself after the location where you created the service, that is, the location where changes were made in the Adding a custom service to the SystemServer process recipe.

The preceding code uses an instance of IPacktCrypto to store a reference of PacktCrypto that is obtained from the Service Manager. We then invoke the getMD5() method, passing in a test string. We then print the output. Since this is a cross-process call, a RemoteException can occur.

On our test device—Samsung Galaxy Nexus (or emulator)—we can view these partitions with the following command executed inside an adb shell. To obtain a shell on the device, you should connect the device via USB and you should make sure that the USB Debugging option is enabled (located at Settings | Developer Options).

Finally, to actually obtain a shell, while the device is connected, fire up a terminal and type in adb shell and press Enter.

The main thing to notice here is the existence of a few common partitions which are important to flashing new software. The following are major partitions on most Android devices:

The three partitions just mentioned are the ones involved in flashing a new build of Android on to a device. In addition to these, there are a few other partitions that exist:

Navigate to your Android source directory and include the build environment as usual. (source build/envsetup.sh).

The lunch command is part of the build environment. It provides a list of available targets you can build with your current source distribution. In all the distributions, the simulator and generic-eng targets are available. Simulator was used before the QEMU emulator became available. This target is now deprecated and should not be used.

We can build the code for a generic target (the emulator), or a simulator target (currently outdated, this existed when the QEMU emulator was not ready). The more interesting options are full_passion-userdebug and full_crespo-userbedug. The first one represents the Google Nexus One device. Passion is the code name for that device. Similarly, the latter represents the Google Nexus S.

Therefore, based on your target device, you can select the desired build target and execute a make.

Although Android is an open source project, certain hardware drivers are closed source. These include the graphics drivers, the WiFi chipset drivers on certain models, orientation sensors, the radio baseband software, and camera drivers. Therefore, if you create a build just with the source downloaded from the Android GIT tree, certain phone functions will not work. For example, if the correct radio image was not included, you will not be able to make and receive phone calls. However, these drivers are made available in binary format for download from https://developers.google.com/android/nexus/drivers.

In the event that something went wrong with your custom code and the device becomes unusable, you will need to restore it to a working state. Google provides Factory images for its developer devices. They contain the usual system.img, boot.img, and recovery.img images that will restore the device to its factory state. These are available at https://developers.google.com/android/nexus/images.

You may need to execute the following command after including proprietary binaries to make sure they are included in the generated software images:

make clobber

Before you can flash any software, you need to boot the device into fastboot mode. There are two ways of doing this:

Fastboot is a protocol to communicate with device bootloaders. This was designed such that flashing can be independent of the underlying bootloader. The process of unlocking the bootloader is available on developer devices. This is a recent feature starting with Nexus S. Relocking bootloaders allows you to lock the bootloader preventing the installation of new firmware.

Google developer phones can be loaded with custom software that we have been building in the previous recipes (Google developer phones are special devices designed for platform developers and not for the typical consumer). Firmware can be written to these devices' flash memory as the bootloader is unlocked. Consumer devices normally lock their bootloaders and flashing is not possible. The workflow for all three of the developer phones (Nexus One, Nexus S, and Galaxy Nexus) is, for the most part, identical. Fastboot is a protocol and a flashing tool used to write new software images to the device.

For more details on the fastboot protocol, refer ANDROID_SRC/bootable/bootloader/legacy/fastboot_protocol.txt.

Navigate to the ANDROID_SRC directory.

The code images are cross compiled for an ARM architecture and the proprietary binaries are included in them. The appropriate prebuilt kernel image is picked up and included in boot.img during the build process.

In the preceding recipes, we created a custom service that can be invoked by obtaining a reference directly to the service via the Service Manager. In this recipe, we will create a class library that abstracts much of that code away into a clean interface. The advantage of creating a class library is that it acts like an SDK-API for our custom service. The example we go through here will also guide us in adding code to the Android class library. The code is generally independent of system services and can be used for other purposes as well. An example of an Android class library is android.app.Activity, which is a commonly used class to represent Android activities. This class is part of the Android class library.

Create a directory at ANDROID_SRC/frameworks/base/core/java/android. We will name it packt. Inside it, we have the following code file.

We need to write a wrapper around PacktCryptoService, which provides us the MD5 creation functionality. The wrapper we write will be the class library. I chose to wrap a service call, as this pattern is followed by many of Android's class libraries, that is, they wrap the service functionality. However, you are not restricted to using this type of wrapper:

Our class library simply obtains a reference to the custom server from the Service Manager. It then invokes the getMD5() method. The advantage of this is that we have a simpler and more uniform API to access our custom server. The other advantage is that it can be packaged into an SDK without the need to package the actual system service itself. This makes sense, since no system services are ever packaged in the SDK, only the APIs that access them are packaged.

We need to make our custom SDK visible to the existing Android SDK. So, unzip the generated custom SDK. Inside, there will be the platforms/android-2.3.4 directory. We are interested in the android-2.3.4 directory. Rename it to android-packt and copy it into ANDROID_SDK/platforms/, where ANDROID_SDK is the path to your Android SDK installation.

Next, we need to update the API level number, so as not to clash with an existing installation of the same API level. Inside android-packt, a file with the name build.prop exists. Change the following line:

ro.build.version.sdk=10

to

ro.build.version.sdk=-20

Here, -20 is an arbitrary number. This is needed to prevent clashes.

Start Eclipse and navigate to the SDK Manager. You should see something similar to the following:

Notice that the plugin has detected a new installation of an SDK with an API level of -20, which is our custom SDK.

Now follow the usual steps to create a skeleton Android application. Be sure to select the correct target when prompted to do so. As shown in the following screenshot, API level -20 has to be selected. This is our custom SDK:

Now, we can access our PacktCrypto class library just like any other Android API.

The PacktCrypto class library methods are available in the new SDK framework.jar file. This helps in compiling the application. When deployed to the emulator, the class library obtains a reference to the PacktCrypto service that is running on the system and provides its functionality to the Android application.

If you haven't already started an emulator with our custom system image (explained earlier), do so now.

Build the APK. Install it via the command line (adb install). The SDK will not detect the running emulator since the SDK we use is standard/unmodified, and hence will not understand the dummy API level -20. Therefore, a launch from Eclipse will not work. However, the installation procedure is no different from a normal app installation via the command line. As specified in the Android Developer documentation, an APK may be installed by specifying the adb install command with an APK filename. The output looks like the following:

The emulator is running an image of the firmware that contains the PacktCrypto service. This was started at the system boot time. The class library simply obtains a copy of the service object through the Service Manager and invokes the getMD5() method. This is abstracted away in the class library which allows development of applications independently of code that runs on an actual system.

In the preceding recipes, our modifications have been tightly integrated with the platform code. In certain cases, such levels of integration may not be needed, but new features need to be added to the system. In such cases, a developer can add code to the framework in the form of a platform library. In this recipe, we will learn how to create a platform library and learn how to write an application which uses it.

Since this code is external to the framework and does not need to be tightly integrated with the system, we will place it in a separate directory called /vendor under ANDROID_SRC. Usually, inside this directory, vendor-specific files are added. Create ANDROID_SRC/vendor/PacktVendor. Inside that, include the following one-liner Android.mk file, so that subsequent make files are called during build.

The platform library has two main components. One is the library itself, which is written in Java or C, and is packaged into a JAR (with an optional shared object if native code is used). The second component is an XML file that declares the JAR to the system as a platform library. This component is important as it helps the system to identify the location of the platform library when it is needed for loading into an application.

The module class ETC specified in the make file for the XML file is used to place files into the /system/etc directory of the firmware image.

Create a directory named PacktLibraryClient at that location. Inside, we write a small Android application that accesses the platform library and invokes a method.

Create the following file at ANDROID_SRC/packages/apps/PacktLibraryClient/src/com/packtclient.

The platform client is simply another Android application. The only difference here is that it is bundled with the system image and is installed at /system/app—the read-only partition.

The most important line in the make file for the application is the LOCAL_JAVA_LIBRARIES tag. This specifies that we will use the functionality of the platform client.

To help clarify the concepts presented in this recipe, it is often helpful to visualize the project structure. In the following text, we pictorially depict what platform libraries look like in the Android sources.

Platform library project organization

Most platform libraries are structured as shown in the next figure. As stated earlier, the top-level directory can change from ANDROID_SRC/vendor to ANDROID_SRC/device/ if you move from Gingerbread development to Ice Cream Sandwich development.

System application project organization

System applications have the following structure within the Android Sources. This figure depicts the organization in terms of the PacktLibraryClient system application we just built, but the organization is similar to other system applications. The point to note here is that system applications live under ANDROID_SRC/packages/apps and for the most part, the directory structure is the same as a normal Android application.

Our previous system service contained only Java code; however, such services may also contain calls to native code. Developers may choose to use native code for a variety of reasons. The most common being speed over interpreted code and re-use of existing libraries. In the next recipe, we will show you how to use native functions inside our PacktCrypto system service.

Also, before jumping to the next recipe, I assume that you are comfortable with JNI technology. If not, I recommend reading the excellent book: The Java Native Interface: Programmer's Guide and Specification by Sheng Liang. (http://www.amazon.com/Java-Native-Interface-Programmers-Specification/dp/0201325772).

We start by implementing the native method in C code. In this example, I choose to implement the popular quick sort algorithm. Note that the file has to be named as per the naming conventions. This is simply the package name in reverse order, but with underscores instead of dots as delimiters.

The native methods we write have to be loaded and identified. The Android framework provides a function called jniRegisterNativeMethods that takes as input a method table and a fully qualified class name of the Java class that will call the native method. In this case, it is our PacktCrypto system service. The method table uses the JNI method descriptor notation to indicate the type of input/output parameters. It also includes a function pointer to the native method implementation. The JNI_OnLoad event is called whenever a native library is loaded into the virtual machine. At this point, we register our native methods, like other system servers. NELEM is a framework-provided macro to calculate the length of an array. It is defined as follows and is located inside the frameworks/base/include/utils/misc.h file:

# define NELEM(x) ((int) (sizeof(x) / sizeof((x)[0])))

Open up the PacktCrypto.java file that is located in the services/java/com/android/packt directory and change it by adding the following lines towards the end of the file.

The Java code contains a native method definition. The framework loads the native code and during the onload event, our native implementation is loaded and registered. When getMD5() is called, our native code is executed and the output is visible on the logger.

In the next recipe, we will learn how some of the most important core Android services are organized and how to make changes to these services. We will also learn how to secure our changes with custom permissions added to the framework.

The Internet infrastructure on Android requires discussion as its design is non-conventional as compared to other services such as the Location Manager service.

ActivityManagerService.java is the source file and is located at ANDROID_SRC/frameworks/base/services/java/com/android/server/am.

The Activity Manager service is started early during the bootup process. At the end, when all the initialization tasks are complete, the systemReady method is executed and the system boot complete broadcast is fired. This method is called by the SystemServer service. It is used to notify the ActivityManagerService that the system is at a point where it is possible to start running third-party code. While the ActivityManagerService does not immediately do this, it gets itself ready when it receives the systemReady call.

Whenever you make changes to the ActivityManagerService class, make sure that you don't introduce code paths that make the service vulnerable or leak sensitive data to malicious applications. Always follow the principles of secure coding and protect your methods by permission checks. If you don't want third-party developers to access your functionality, assign a signature permission to that method. The keen reader will have noticed that the ActivityManagerService class is like any other system service and executes in the context of the SystemServer service. Hence, now you realize that your custom system service executes alongside such important services. Any bugs in your system service have the potential to bring down the whole framework. So be careful when writing such code!

We will edit the following files:

In Android, the ActivityManagerService class executes within the context of the system server process. Hence, calls into it will be remote calls. Therefore, we have to make use of the Binder IPC mechanism. The IActivityManager.java file contains the set of remote calls exposed by the Activity Manager service. Hence, we add a new interface method packtSensitiveMethod() and a transaction constant PACKT_TRANSACTION that will correspond to this method.

ActivityManager.java represents a class library that user applications use to access the functionality of the Activity Manager service. This is similar to the custom class library we added in the earlier recipe on creating custom class libraries. As I've stated before, our implementations follow the design guidelines used in the Android code. Therefore, you will see several existing parallels in the Android source code. This is just one of the many examples that exist. Hence, we add a shim method to that file that invokes the real method through a remote procedure call.

As stated earlier, the Activity Manager service was written before the AIDL compiler existed, therefore the proxies and stubs for all remote calls are implemented manually. Hence, we add marshalling code to ActivityManagerNative.java.

You may wonder why we still add the marshalling code manually. The answer is that even though the AIDL compiler is now available, the build process was never updated for the ActivityManagerService class to make use of the AIDL compiler.

Open the AndroidManifest.xml file from the location specified in the preceding table.

Even the Android framework has a manifest file. This file contains permission definitions for all permissions that exist in the system. The permission tag requires you to specify a permission description among other parameters. The system uses these strings for user display. For example, the permission description parameter is shown to a user while installing the application which asks for the permission in question.

Open up Client.java from the PacktLibraryClient application, which is located at ANDROID_SRC/packages/apps/PacktLibraryClient/src/com/packtclient/.

The application obtains a reference to the Activity Manager service. This reference is in the form of an ActivityManager object. The packtSensitiveMethod shim is executed in the client, which cause an RPC to be sent out to the Activity Manager service, which performs a permission check before executing the main body of the method. When our APK wasn't signed with the platform key and didn't include the correct <uses-permission> tag, this check failed and the application crashed. In the second instance, we made the appropriate changes and the permission check succeeded.

The source code of the Package Manager service is located at ANDROID_SRC/frameworks/base/services/java/com/android/server/. Open up the file named PackageManagerService.java in your favorite code editor.

The Package Manager service stores and manages all configuration data in XML files with proper Linux permissions on these files. Internally, the service makes use of XML pull parsers to read and process these files. This service is interrogated by other services, most notably the Activity Manager service, as to whether a package possesses a certain permission or not.

Whenever you make changes to this service, please rethink your design carefully and only if there is no other way to accomplish the task, run the unit tests.

To run these tests, run the following command in a terminal (as always, I assume you have set up a build environment by including build/envsetup.sh):

mmm frameworks/base/tests/AndroidTests

Then start the emulator and execute this in a terminal over ADB:

adb install -r -f out/target/product/passion/data/app/AndroidTests.apk

Finally drop into an adb shell and execute:

adb shell am instrument -w -e class com.android.unit_tests.PackageManagerTests com.android.unit_tests/android.test.InstrumentationTestRunner

The unit tests are part of the Compatibility Test Suite (CTS). The CTS is part of the Android compatibility program. The aim is to achieve standardization among Android vendor implementations. The interested reader is referred to an overview of the compatibility program at http://source.android.com/compatibility/overview.html. Details on the CTS itself may be found at http://source.android.com/compatibility/cts-intro.html.

We will look at a kernel source file in this recipe, so locate the kernel sources you had downloaded and built in the first recipe of this book.

The code for network access in Java is implemented in the Apache Harmony library in OSNetworkSystem.java located at ANDROID_SRC/libcore/luni/src/main/java/org/apache/harmony/luni/platform.

This is the final point before native socket calls are invoked.

The OSNetworkSystem.java file contains native methods that ultimately make use of libc socket calls to perform I/O on the network. System library calls eventually invoke system calls implemented in the kernel. On Android, the network calls were changed to only allow execution if the process currently executing the system call belongs to a particular group. That group is named inet.

When an application requests android.permission.INTERNET, and when it is about to be run, the Package Manager service notifies Zygote that the application is to be run as part of the inet group.

Later on, the modified system calls verify that the process is running as a member of inet and the call succeeds.

The current_has_network() function makes use of the function in_egroup_p(gid_t) to check the group identifier of the process executing it. An Android process runs as a member of this group only if it has been granted android.permission.INTERNET.

The system applications are installed on the system/read-only partition of an Android device. The applications are signed with the one of system certificates (There are four certificates: testkey, platform, shared, and media) and perform certain privileged tasks. Examples include the Contacts application and the Settings application. Sometimes, your design may require a change of these system applications. In the next recipe, we will learn the purpose of the most important system applications and learn how to compile changes made to them.

Navigate to the /packages directory under ANDROID_SRC/.

The following table summarizes the four top-level directories and the code they contain:

Now, we will learn the purpose of the most important directories under Apps and Providers.

Directories under /Apps:

Directories under /Providers:

All of the above applications have a make file that is picked up by the Android built system during a full system build. The built APKs are packaged into system.img and during system bootup they are installed into the /system/app directory.

The search widget's code is in the directory named QuickSearchBox under ANDROID_SRC/packages/apps/. Navigate to this directory and open up ANDROID_SRC/packages/apps/QuickSearchBox/res/drawable/text_field_search_empty_google.xml.

The mmm command selectively builds code. The argument to it is the path to the source directory containing an Android.mk file. The path should end with the name of a target that can be built. For example, if you open the Android.mk file, the target is identified by the LOCAL_PACKAGE_NAME tag.

As we have seen in earlier recipes, the system partition is mounted as read-only for security reasons. To install a system application, we need to remount this. The remount can only be done by a root user. On the emulator, ADB runs as root by default.

The side effect of simply pushing an APK to /system/app results in its installation.

The different drawable directories are used based on different screen densities. This has the same meaning as the directories used when writing SDK-based apps.

Navigate to your Android sources root and issue the make clean command. We want to build up the cache from scratch.

The Android build system is written in such a way that if CCACHE is activated by the environment variable, it will be used automatically.

The above shell script is really simple and simplifies the developer's task of initializing an environment for further work. The commands within the shell script have to be executed whenever a new terminal is opened for Android systems development. Hence it is easier to execute one shell script instead of several individual commands.

As an example, we will use selective compilation to rebuild the Phone application under ANDROID_SRC/packages/apps/Phone.

Make a small change, like adding a comment to one of the source files:

mmm invokes the build system only on the specified argument and places the output at the specified location (this is inferred from the make file of the module being compiled).

You can follow this technique for any module as long as you replace all rebuilt components on the device/emulator.

All you need is a terminal window with the build environment set up.

The following table lists the command options for the standard make:

These commands can be regularly used for several tasks during development. As an example, suppose I want to rebuild the Android framework and push it to the emulator, I can use the following sequence of commands written as a shell script:

You can save this build file as mk_frmwrk.sh:

#!/bin/sh
mmm -j4 frameworks/base frameworks/base/core/res snod
adb shell stop
adb sync
adb shell start

This will recompile the framework code, recompile the resources, rebuild system.img and sync it to the currently connected device.