Build Android on Ubuntu Linux

This note is an indirect continuation of my first publication Assembling Android for Mac OS X and has a similar goal - solving build problems with respect to older versions of Android 4.0.x.

Short introduction. In one of the projects, I am working on finalizing the original Android code to create firmware for a specific piece of hardware. The build version was already relatively old - AOSP 4.0.4, but it is based on a stable code branch from the hardware manufacturer. I originally worked on MacOS, but for this project I decided to switch to Linux for ease of development. So by the will of fate, I switched from MacOS to the more or less recent Ubuntu Linux 12.04.3, the currently recommended version of Linux for building Android.

The main problem in the new environment was the old problem - old versions of AOSP are not tracked and new edits are not made to the assembly system. Therefore, if assembling a master is not particularly difficult, then assembling previous versions of Android for more recent versions of Ubuntu requires fixing a number of problems.

In my case, the working environment looks like this:

• AOSP 4.0.4 r1.1
• Ubuntu Linux 12.04.3 x64
• GNU Make 3.81 and other recommended utilities

All the main points and difficulties of assembling AOSP are well described in the official documentation . As for MacOS, in the case of Ubuntu, it is proposed to use older versions of the base OS to build AOSP 4.0.x versions. In particular, in the “Known Issues” section, to solve the “ Build error with 4.0.x and earlier on Ubuntu 11.10 ” problem, it is proposed to use the old Ubuntu 10.04 release, which I don’t really want to do if you intend to deal with the OS and other tasks besides building AOSP.

Decision

The installation was performed on almost pure Ubuntu, with the exception of several application programs. The initial setting of the environment was carried out in accordance with the official description.

Below I give the error texts from the console and the correction methods. Depending on the version of AOSP and your environment, they may appear in whole or in part. Most of the solutions can be found on the Internet, I give only a brief description of the necessary actions.

Error 0

Or it’s not a mistake at all, but the need to install proprietary Oracle Java packages for the assembly, which for some time have not been included in the Ubuntu package.

Correction

To build Android, we need the JDK 6th version, respectively, for this we prescribe the Oracle repository with the necessary packages and install the required one:

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java6-installer

Similarly, you can install the latest JDK 7th version if it is required for other purposes:

sudo apt-get install oracle-java7-installer

Error 1

When installing the necessary packages , the libgl1-mesa-glx package is not installed: i386, which contains the library we need libGL x86. It is not installed with the following reason:

The following packages have unmet dependencies:
 libgl1-mesa-glx:i386 : Depends: libglapi-mesa:i386 (= 8.0.4-0ubuntu0.6)
                        Recommends: libgl1-mesa-dri:i386 (>= 7.2)
E: Unable to correct problems, you have held broken packages.

Along with it, the package libgl1-mesa-dev is specified for installation, which contains libGL, but the x64 version is not suitable for us to build AOSP.

If we try to build with libgl1-mesa-dev for x64 architecture, then we get an error when linking:

/usr/bin/ld: cannot find -lGL
collect2: ld returned 1 exit status
make: *** [out/host/linux-x86/obj/lib/libGLES_CM_translator.so] Error 1
make: *** Waiting for unfinished jobs....
/usr/bin/ld: cannot find -lGL
collect2: ld returned 1 exit status
make: *** [out/host/linux-x86/obj/lib/libEGL_translator.so] Error 1

Correction

Instead of the libgl1-mesa-glx: i386 and libgl1-mesa-dev packages, install the libgl1-mesa-dev: i386 package:

sudo apt-get install libgl1-mesa-dev:i386

A more detailed description of the contents of the package can be found in the description of Ubuntu, it can be seen that it also contains the necessary libgl1-mesa-glx.

Also, when installing the package, a symlink will be created in the / usr / lib / i386-linux-gnu / directory, so you do not need to create it additionally, as indicated in the manual by the command:

sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so

Error 2

The gcc compiler version (4.6.x) used in the system has a problem with overriding the _FORTIFY_SOURCE symbol, which is also described in the official " Known Issues ". As a solution, it is proposed to roll back to Ubuntu 10.04, which is obviously not the best option. The text of the warning and error will be as follows:

:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default]

or

:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
:0:0: note: this is the location of the previous definition
cc1plus: all warnings being treated as errors

Correction

This problem can be solved by installing gcc-4.4 and the necessary libraries:

sudo apt-get install gcc-4.4 g++-4.4 g++-4.4-multilib gcc-4.4-multilib

You can read more about configuring 2x versions of gcc and using gcc-4.4 as a priority version in this blog. For our purposes, it is enough to install the necessary packages and start the assembly with a command indicating the version of the compiler:

make CC="gcc-4.4" CXX="g++-4.4"

After the above operations, Android will assemble as we wanted, but after the fact you can encounter a couple of troubles.

Error 3

When you start the emulator with the specified "-gpu on" parameter to enable hardware rendering acceleration, you will receive the following message and a black screen in the emulator:

Failed to load libGL.so
error libGL.so: cannot open shared object file: No such file or directory
Failed to load libGL.so
error libGL.so: cannot open shared object file: No such file or directory

In normal mode, the emulator starts up normally, but it was interesting to figure it out, and it turned out that after the computer rebooted, the fans continued to work at maximum and did not turn off. To put it mildly, a very unpleasant effect, with such noise it is extremely uncomfortable to work.

Correction

By checking the packages, it turned out that when installing one of them, the proprietary graphics driver from NVidia was removed and as a result, the system forgot how to adjust the fan speed and where to look for the desired library. The malicious package turned out to be libncurses5-dev: i386, note that when installing it, the following request will be:

sudo apt-get install libncurses5-dev:i386
The following packages will be REMOVED:
  dkms gcc gcc-4.6 nvidia-304

Accordingly, the solution to the problem is simply reinstalling the proprietary driver in the console or through the control panel.

Error 4

Occurs when the emulator starts without specifying a system kernel file. In a previous article, I forgot to indicate this point, in this I correct so that the description is completely complete. So, when starting the AOSP 4.0.4 emulator, we get the message:

emulator: ERROR: bad workspace: cannot find prebuilt kernel in: /home/user/Development/workspace_aosp/android-4.0.4_r1.1/prebuilts/qemu-kernel/arm/kernel-qemu-armv7

The problem arose due to the fact that in more recent versions of AOSP prebuilts were moved to another directory and this fix got into the assembly scripts for older versions, but the location was not changed.

Correction

Specify the location of the kernel when starting the emulator, the path relative to the assembly root:

emulator -kernel prebuilt/android-arm/kernel/kernel-qemu-armv7

or for better performance:

emulator -kernel prebuilt/android-arm/kernel/kernel-qemu-armv7 -memory 1024 -gpu on

Conclusion

In general, the Linux build was faster and the debriefing took less time, although the situation with the graphics driver and fan at first confused me. Therefore, the assembly under Linux can be assessed as less problematic, although not entirely unambiguously :).