Build Android under Ubuntu Linux

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

Briefly introductory. In one of the projects, I am working on modifications of the original Android code to create firmware for a specific piece of hardware. The version for the assembly was chosen already relatively old - AOSP 4.0.4, but it is based on a stable code branch from the hardware manufacturer. I initially 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 a more or less recent Ubuntu Linux 12.04.3, currently recommended version of Linux for building Android.

The main problem in the new environment is the old problem - the old versions of AOSP are not tracked and new edits are not made to the build system. Therefore, if the build of the master is not particularly difficult, then the assembly of 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 highlights and difficulties of assembling AOSP are well described in the official documentation . As with 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 section "Known Issues" to solve the problem of " Build error with 4.0.x and earlier on Ubuntu 11.10 " it is proposed to use the old Ubuntu 10.04 release, which you don’t really want to do if you intend to work on the OS and other tasks besides the AOSP assembly.

Decision

The installation was done on a virtually clean Ubuntu, with the exception of a few application programs. The initial setting of the environment was made in accordance with the official description.

Below I give the error texts from the console and the methods of correction. Depending on the version of AOSP and your environment, they may appear all 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 not at all an error, but the need to install proprietary Oracle Java packages for the assembly, which for some time are not included in the Ubuntu distribution.

Correction

To build Android, we need JDK version 6, respectively, for this, we prescribe an 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 version 7, 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 in which the necessary libGL x86 library is installed. 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 for installation is the libgl1-mesa-dev package which contains libGL, but the x64 version, which is not suitable for building AOSP.

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

 /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 packages: i386 and libgl1-mesa-dev install the libgl1-mesa-dev package: i386:

 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 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 version of the gcc compiler used in the system (4.6.x) has a problem with redefining the _FORTIFY_SOURCE symbol, which is also written 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 warning and error text will be as follows:

 <command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default] 

or

 <command-line>:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror] <built-in>: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 

More information about setting up 2 versions of gcc and using gcc-4.4 as a priority version can be found in this blog. For our purposes, it is enough to install the necessary packages and run 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 gather as we wanted, but after the fact you can still face a couple of troubles.

Error 3

When you start the emulator with the specified "-gpu on" parameter to enable hardware acceleration of the drawing, 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, moreover, it turned out that after restarting the computer, the fans continue to work at maximum and are not muffled. To put it mildly, it’s not a very pleasant effect, it’s extremely uncomfortable to work with such noise.

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 find the necessary library. The malicious package was libncurses5-dev: i386, note that when installing it, the following query 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 to reinstall the proprietary driver in the console or through the control panel.

Error 4

Occurs when starting the emulator without specifying the system core file. In the previous article, I forgot to specify this point, this one is being corrected so that the description is completely complete. So when you start 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 transferred to another directory and this fix fell into the build scripts for the old versions, but did not change the location.

Correction

When you start the emulator, specify the location of the kernel, 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 build for Linux was faster and debriefing took less time, although the situation with the graphics driver and fan put me at a dead end at first. Therefore, the build for Linux can be assessed as less problematic, although not entirely unambiguous :).