Chapter 2. Interfacing with Android
In the last chapter, you installed Android on your BBB. You also gathered all of the hardware and components that you will need to try out the exercises in this book. Now that you have a working Android system and the hardware needed to explore it, it is time to dive into Android and find out how to prepare it to interface with custom hardware.
Most people would not consider Android and Linux to be very similar, but the two have more in common than you might realize. Underneath the polished UIs and a wide variety of apps, Android is secretly Linux. Android's filesystem layout and services are quite different from those of a typical Linux system, so there are certainly many differences between the two in terms of user space (where apps and other processes execute). In terms of kernel space (where device drivers execute and resources are allocated to each running process), they are almost identical in functionality. Understanding how the BBB interacts with...
Understanding the Android HAL
An Android kernel contains a few additional features that aren't found in a typical Linux kernel, such as Binder IPC
and the low-memory killer, but otherwise it is still Linux. This provides you with one very big advantage when interfacing hardware with Android, that is, if a Linux driver already exists in the kernel used for an Android system, then you already have an Android driver for that device.
Android apps must interact with the hardware of an Android device by generating video and audio data, receiving button and touchscreen input events, and receiving sensor events from cameras, accelerometers, and other devices that gather information from the outside world. Leveraging existing Linux drivers for these devices makes Android support much easier. Unlike a traditional Linux distribution, which grants applications permission to directly access many different device files (by directly opening files in the /dev filesystem), Android dramatically limits the...
All of the various pieces of PacktHAL are located in the PacktHAL.tgz file, which is available for download from Packt's website (http://www.packtpub.com/support). This is a compressed tar file that contains all of the source code and configuration files required to modify BBBAndroid to use PacktHAL and include PacktHAL support in your apps.
Preparing PacktHAL under Linux
Once you have downloaded the PacktHAL.tgz file, you must decompress and untar it. We will assume that you have copied PacktHAL.tgz to your home directory after downloading it and will decompress it from there. We will refer to your home directory as $HOME.
Use the Linux tar command to decompress and untar the file:
A directory named PacktHAL now exists in your $HOME directory. All of the PacktHAL files are located in this directory.
Preparing PacktHAL under Windows
Once you have downloaded the PacktHAL.tgz file, decompress and untar it. We will assume that you have copied...
Setting up the Android NDK for PacktHAL
Unfortunately, the Android Native Development Kit (NDK) is missing a kernel header file that is needed to build PacktHAL. The missing header describes the interface between user space apps and the generic SPI driver (spidev, which you will use in Chapter 5, Interfacing with High-speed Sensors Using SPI). It is not the fault of the NDK that this header file is missing, as usually apps will never need direct access to the spidev driver.
As you are using an app to talk directly talk to the hardware, you will need to copy this missing header into your NDK installation.
Tip
For your convenience, we have included a copy of this header file in the PacktHAL source tarball. You only need to copy the file into your NDK installation prior to building PacktHAL.
BBBAndroid is 4.4.4 KitKat, and API level 19 is the highest level supported by this version. You will be building all of the examples in this book for API level 19. Each API level has a different set of headers...
Multiplexing the BBB pins
As accessing hardware resources follows the same process under Android as it does under Linux, it is important to understand how the Linux kernel configures device drivers and allocates them to particular pieces of hardware. It is also necessary to understand how these kernel drivers provide user space interfaces that PacktHAL can interact with.
The BBB's AM3359 processor offers a wide variety of signals on its hundreds of pins. These signals include many different, specialized interface buses and sensor inputs. There are far too many potential signals for the number of pins available to supply these signals to the outside world. To select which signals are available on the pins, the pins are multiplexed, or muxed, to specific signals.
Several of the processor's pins are wired to the connections of the BBB's P8 and P9 headers. The muxing of these particular pins is of great interest to BBB users, as the muxing determines which processor signals and features are easily...
In this chapter, we explained how Android uses a HAL to allow Android managers to provide hardware access to apps. We introduced you to PacktHAL that can be used to interface with all of the examples throughout this book. You configured your BBBAndroid image to use PacktHAL, and you modified your NDK installation to build PacktHAL into your apps.
We also showed which pins of the BBB's P8/P9 headers can be multiplexed, what the Device Tree is and how it is used to multiplex pins, and how the capemgr loads Device Tree overlays to dynamically mux the BBB's pins.
In the next chapter, you'll put PacktHAL to work and build your first hardware-interfacing app using GPIOs.
