In preparation to install and run the Hello Android application, let's take a tour of our build and testing environment. We need to identify four distinct environments/tools and clearly understand them when building applications for Android/Linux. The first environment to grasp is the big-picture architecture of the Android Emulator running essentially on top of Linux, as shown in figure 13.1.
As presented in the early chapters of this book, there is a Linux kernel running underneath the pretty, graphical face of Android. There exist device drivers, process lists, and memory management, among other elements of a sophisticated operating system.
As shown in the previous section, we need an environment in which to compile our C code. This is most likely to be a command-prompt window on a Windows machine, or a shell window on a Linux desktop machine, exercising the CodeSourcery tool chain. This is the second environment to be comfortable operating within.
NOTE The CodeSourcery tool chain is not designed to run on the Android/Linux environment itself, so the development work being done here is considered to be cross compiling. The figures and example code presented in this chapter were taken from a Windows development environment used by the author. There are a number of long path and directory structures in the Android SDK and the CodeSourcery tools. In order to help simplify some of the examples and keep certain command line entries from running over multiple lines some drive mappings were set up. For example a drive letter of "m:" seen in scripts and figures corresponds to the root location of source code examples on the author's development machine. Likewise the "g:" drive points to the currently installed Android SDK on the author's development machine. Note that this technique may also be used in Linux of Mac OSX environments with a "soft link" (ln) command.
The next requirement is to copy our newly constructed binary executable application to the Android Emulator. This can be done with a call to the adb utility or by using the DDMS view in Eclipse. Both of these tools were demonstrated in chapter 2. Here is the syntax for copying the executable file to the Android Emulator:
adb push hellostatic /data/ch13
Note a few items about this command:
■ The command name is adb. This command takes a number of arguments that guide its behavior. In this case, the subcommand is push, which means to copy a file to the Android Emulator. There is also a pull option for moving files from the Android Emulator file system to the local development machine's hard drive.
■ After the push option, the next argument, hellostatic in this case, represents the local file, stored on the development machine's hard drive.
■ The last argument is the destination directory (and/or filename) for the transferred file. In this sample, we are copying the hellostatic file from the current working directory to the /data/ch13 directory on the Android Emulator.
Be sure that the desired target directory exists first! You can accomplish this with a mkdir command on the adb shell, described next.
The final tool to become familiar with is the shell option of the adb shell. Using this command, we can interact directly on the Android Emulator's file system with a limited shell environment. To enter this environment (and assuming the Android Emulator is already running), execute adb shell from the command line. When invoked, the shell displays the # prompt, just as if you had made a secure shell (ssh) or telnet connection to a remote Unix-based machine. Figure 13.2 shows these steps in action.
Figure 13.2 The build, copy, run cycle
Note the sequence shown in figure 13.2. First the application is built with a call to gcc. Next we push the file over to the Android Emulator. We then connect to the Android emulator via the adb shell command, which gives us the # prompt, indicating that we are now on the shell. Next we change directory (cd) to /data/ch13. Remember that this is Linux, so the application by default may not be executable. A call to chmod sets the file's attributes, turning on the executable bits and allowing the application to be invoked. Lastly, we invoke the application with a call to ./hellostatic. The search path for executable applications does not by default include the current directory on a Linux system, so we must provide a more properly qualified path, which explains the ./ prefix. Of course, we can see that our application has run successfully because we see the "Hello, Android!" text displayed on the screen.
Congratulations! We have a successful, albeit simple, Android/Linux application running on the Android Emulator. In the next section, we take a quick look at streamlining this build process.
Was this article helpful?