| Introduction: |
| ============= |
| |
| The Android emulator builds now uses several prebuilt host binaries |
| (shared libraries or executables), in order to simplify and speed up the |
| build. |
| |
| These binaries typically come from third-party open-source projects, |
| for example: |
| |
| - libffi, gettext, glib and other dependencies required by the code base |
| under external/qemu-android |
| |
| - The LLVM and Mesa3D graphics libraries used to implement software-based |
| GPU emulation. |
| |
| This documents explains how these prebuilts were generated, how they are |
| typically stored and managed by the android-rebuild.sh script. |
| |
| |
| I. List of Android emulator prebuilt packages: |
| ============================================== |
| |
| The following file lists the location of all source packages for the prebuilts |
| required by the emulator build: |
| |
| android/dependencies/PACKAGES.TXT |
| |
| This is a simple text file that contains one-line per package. For a detailed |
| description of the file format, read the comments in: |
| |
| android/scripts/utils/package_list_parser.py |
| |
| It is possible to apply a set of patches on top of an official source package |
| by using a PATCHES=<file> field in a PACKAGES.TXT package description. For |
| example, this is used to apply a few patches on top of the official Mesa3D |
| release (see current content of android/dependencies/ and PACKAGES.TXT). |
| |
| You should call the following script to download all source packages from |
| known reliable sources, and verify their content through sha1sum: |
| |
| android/scripts/download-sources.sh |
| |
| IMPORTANT: You must also call this script every time you modify PACKAGES.TXT. |
| |
| Note that by default, this will copy PACKAGES.TXT and patch files located |
| under android/dependencies/ into the following target directory: |
| |
| $AOSP/prebuilts/android-emulator-build/archive/ |
| |
| You can change this destination by using the --install-dir=<dir> option, or |
| defining the ANDROID_EMULATOR_PREBUILTS_DIR environment variable to point |
| to a different location. |
| |
| |
| II. Android SDK specific toolchains: |
| ==================================== |
| |
| To avoid surprises and unexpected differences when people use different |
| systems to build the same sources, special toolchains are used to build |
| all prebuilts, more specifically: |
| |
| - A Linux toolchain, based on GCC 4.8, which compiles against GLibc 2.11, |
| which is ancient enough to let binaries run on Debian Stable and |
| RedHat systems. |
| |
| - A cross-toolchain (x86_64-w64-mingw32) which generates Win32 and Win64 |
| binaries under Linux. This is a lot more faster than trying to rebuild |
| these with a solution like Cygwin on Windows. |
| |
| - For OS X, we use a prebuilt Clang binary (currently 3.5) and well as need |
| to ensure that the corresponding binaries run at least on OS 10.8, the |
| minimal supported version of the system for the SDK. |
| |
| To make things easier, a script is provided that can generate a 'wrapper' |
| toolchain: |
| |
| android/scripts/gen-android-sdk-toolchain.sh --host=<system> <dst-dir> |
| |
| Where <system> is a host system name as in [1], and <dst-dir> is a |
| directory where wrapper scripts for gcc, cc, ld, ar, and other toolchain |
| programs will be created to target |
| |
| Note that these scripts have a system-specific prefix: |
| |
| - The Linux compiler will be called x86_64-linux-gcc. |
| - The Windows compiler will be called x86_64-w64-mingw32-gcc. |
| - The Darwin compiler doesn't use a prefix. |
| |
| This is done to make typical GNU 'configure' script work easier. One would |
| typically use the configure --host option to ensure the wrapper toolchain |
| is being used, i.e.: |
| |
| - On Linux, use --host=x86_64-linux |
| - On Linux, when generating Windows binaries, use --host=x86_64-w64-mingw32 |
| - On Darwin, don't use --host, since the wrapper toolchain doesn't use |
| a 'binprefix' at all. |
| |
| Use the --help option to see more options available when calling this script. |
| |
| Typically, one would prepend <dst-dir> to your PATH before launching |
| the configure script, as an example, here's how to recompile a given |
| opensource package on Linux: |
| |
| /path/to/external/qemu/android/scripts/gen-android-sdk-toolchain.sh \ |
| /tmp/my-toolchain |
| |
| PATH=/tmp/my-toolchain:$PATH |
| |
| cd /path/to/opensource-package-1.0/ |
| ./configure --host=x86_64-linux --prefix <install-dir> <other-options> |
| make -j8 |
| make install |
| |
| However, several shell scripts are provided to automate this. |
| |
| |
| III. Rebuild scripts for third-party packages: |
| ============================================== |
| |
| the android/scripts/ directory contains many shell scripts used to rebuild |
| specific third-party libraries or executables. In particular: |
| |
| - They all use shared functions from android/scripts/utils/ that make |
| it easy to parse the PACKAGES.TXT file, extract source tarball to |
| temporary build directories, generate SDK toolchain wrappers, and |
| configure simple projects. |
| |
| - On Linux, they will build binaries for linux-x86_64, windows-x86 and |
| windows-x86_64 automatically. |
| |
| Also, they support the --darwin-ssh=<hostname> which allows one |
| to perform a remote build of Darwin binaries through SSH. |
| |
| - They place all generated binaries under: |
| |
| $AOSP/prebuilts/android-emulator-build/<name> |
| |
| Where <name> is a unique name corresponding to this group of binaries. |
| |
| Most features are explained when using the --help option on one of these |
| scripts. |
| |
| If you consider adding new prebuilt binaries, consider writing such a |
| specialized script to get the same benefits. A good starting point is |
| looking at one of the existing scripts and try to modify it. |
| |
| Another thing to do is open a buganizer entry to request a new git |
| repository under: |
| |
| $AOSP/prebuilts/android-emulator-build/<new-project-name> |
| |
| Consider providing an archive of the original content for this directory |
| (i.e. generated by your own build script) to populate it first. |
| |
| |
| IV. How prebuilt binaries are used by the build: |
| ================================================ |
| |
| The android-rebuild.sh script is in charge of placing prebuilt binaries |
| to the correct location under $OUT_DIR/, which defaults to objs/ |
| |
| In particular: |
| |
| - qemu-android binaries must be placed under: |
| |
| $OUT_DIR/qemu/<system>/qemu-system-<qemu-arch> |
| |
| Note that these binaries are generated by running: |
| |
| android/scripts/ |
| |
| - Swiftshader must be placed under: |
| |
| $OUT_DIR/lib/gles_swiftshader/ (32-bit ones) |
| $OUT_DIR/lib64/gles_swiftshader/ (64-bit ones) |
| |
| - Mesa libraries must be placed under: |
| |
| $OUT_DIR/lib/gles_mesa/ (32-bit ones) |
| $OUT_DIR/lib64/gles_mesa/ (64-bit ones) |
| |
| - Qt shared libraries should go into: |
| |
| $OUT_DIR/lib/qt/ (32-bit ones) |
| $OUT_DIR/lib64/qt/ (64-bit ones) |
| |
| - Any third-party host executable (if any) should go under: |
| |
| $OUT_DIR/bin/ (32-bit ones) |
| $OUT_DIR/bin64/ (64-bit ones) |
| |
| Note that the top-level 'emulator' launcher program will modify the runtime |
| library search path (e.g. LD_LIBRARY_PATH on Linux) to ensure that libraries |
| under <lib>/, <lib>/qt/ or <lib>/gles_swiftshader/, whenever that makes sense. |
| |
| The PATH is not modified though, so use explicit bin/ or bin64/ prefixes |
| when invoking host binaries. |
| |
| |
| |
| [1] Valid host system names are: |
| |
| darwin-x86_64 |
| linux-x86_64 |
| windows-x86_64 |
| linux-x86 |
| windows-x86 |