[FE training-materials-updates] Remove \\ at the end of some paragraphs
michael.opdenacker at free-electrons.com
michael.opdenacker at free-electrons.com
Tue Jun 5 07:05:37 CEST 2012
- Log -----------------------------------------------------------------
http://git.free-electrons.com/training-materials/commit/?id=07ecbc988c18b501f5ee0ae3ce90686224af4fff
commit 07ecbc988c18b501f5ee0ae3ce90686224af4fff
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date: Tue Jun 5 07:03:50 2012 +0200
Remove \\ at the end of some paragraphs
This makes spacing between paragraphs look weird
and we should let LaTeX manage spacing by itself.
We don't have this in the other labs anyway.
diff --git a/common/labs.sty b/common/labs.sty
index 97bc70a..7fa6347 100644
--- a/common/labs.sty
+++ b/common/labs.sty
@@ -127,15 +127,15 @@
{
\section{About this document}
- This document can be found on \url{\@trainingurl}.\\
+ This document can be found on \url{\@trainingurl}.
It was generated from LaTeX sources found on \url{http://git.free-electrons.com/training-materials}.
- More details about our training sessions can be found on \url{http://free-electrons.com/training}.\\
+ More details about our training sessions can be found on \url{http://free-electrons.com/training}.
\section{Copying this document}
- \copyright~2004-\the\year, Free Electrons, \url{\@feurl}.\\
+ \copyright~2004-\the\year, Free Electrons, \url{\@feurl}.
\begin{wrapfigure}{l}{0.1\textwidth}
\vspace{-15pt}
@@ -146,7 +146,6 @@
This document is released under the terms of the \@cchref. This means that you
are free to download, distribute and even modify it, under certain conditions.
- \\
Corrections, suggestions, contributions and translations are welcome!
\newpage
diff --git a/labs/android-adb/android-adb.tex b/labs/android-adb/android-adb.tex
index 1d7c4f8..ac8fd5d 100644
--- a/labs/android-adb/android-adb.tex
+++ b/labs/android-adb/android-adb.tex
@@ -13,34 +13,34 @@ After this lab, you will be able to use ADB to:
ADB is distributed by Google as part of their SDK for Android. First,
you need to go to
\url{http://developer.android.com/sdk/index.html}. Get the SDK for
-Linux, and follow the instructions to install it.\\
+Linux, and follow the instructions to install it.
Once the SDK is installed, launch the \code{android} binary, go to the
\code{Available Packages} tabs, select \code{Android SDK Platform-tools} and
click on the \code{Install Selected} button. Once you are done, you have \code{adb} on
-your workstation !
+your workstation!
However, the Android source code also has an embedded SDK, so you
should also have the \code{adb} binary in \code{out/host/linux-x86/bin/}
-directory and in your PATH.
+directory and in your \code{PATH}.
\section{Disable USB suspend}
The kernel we have built uses USB suspend to save power. This will
-prove painful during the next labs, beginning with this one.\\
+prove painful during the next labs, beginning with this one.
To do so, go to the \code{kernel} directory. First, use the
\code{android_omap3_defconfig} file as an initial configuration. Load it using
\code{ARCH=arm make android_omap3_defconfig} and then modify it using
\code{ARCH=arm make menuconfig} to disable \code{CONFIG_USB_SUSPEND}
and enable \code{CONFIG_USB_OTG_WAKELOCK}. We will also need to enable
-OHCI support to use the missile launcher.\\
+OHCI support to use the missile launcher.
Once you're done, exit and the configuration tool will save the new
file as \code{.config}. You can save it to a defconfig file by
running \code{ARCH=arm make savedefconfig}. Then, copy the newly created
\code{defconfig} file to the \code{arch/arm/configs} directory with
-the \code{android_devkit8000_defconfig} name.\\
+the \code{android_devkit8000_defconfig} name.
Once this is done, change the BeagleBoard product definition so that
it uses this new file.
@@ -49,7 +49,7 @@ it uses this new file.
If you execute any command right now, you are very likely to have a
permission denied error. This is because the USB device associated to
-the DevKit8000 doesn't have the right permissions to let you open it.\\
+the DevKit8000 doesn't have the right permissions to let you open it.
We need to make sure that \code{udev} sets the right permissions so that we can access
it as a user. To do so, create the file
@@ -64,18 +64,18 @@ Now, plug and unplug the DevKit8000, and you should now be able to use
ADB provides many useful features to work with an existing Android device.
The first we will see is how to get the system logs from the whole system. To do
-this, just run \code{adb logcat}\\
+this, just run \code{adb logcat}.
You will see the device logs on your terminal. This is a huge amount of
information though, and it is difficult to find your way in all these lines.
The first thing we can do is download a little wrapper to \code{adb} to provide colored
logs. You can find it here: \url{http://jsharkey.org/downloads/coloredlogcat.pytxt}. Once downloaded, just run it and you will see the logs colored and
-formatted to be easily readable.\\
+formatted to be easily readable.
ADB also provides filters to have a clearer output. These are formatted by the
\code{Tag:Priority} syntax. For example, if you want all logs from \code{MyApp},
-just run \code{adb logcat MyApp:*}.\\
+just run \code{adb logcat MyApp:*}.
Now try to save all logs from Dalvik to a file using only \code{adb}.
@@ -83,7 +83,7 @@ Now try to save all logs from Dalvik to a file using only \code{adb}.
Having a shell on the device can prove pretty useful. ADB provides such a feature,
even though the Android-embedded shell is quite minimal. To access this shell,
-just type \code{adb shell}.\\
+just type \code{adb shell}.
You can also run a command directly on the device thanks to \code{adb shell}. To do
this, just append the command to run at the end. Now, try to get all the mounted
diff --git a/labs/android-application/android-application.tex b/labs/android-application/android-application.tex
index 196b1e1..05e3ad3 100644
--- a/labs/android-application/android-application.tex
+++ b/labs/android-application/android-application.tex
@@ -24,7 +24,7 @@ DummyBackend for debug).
The whole application now uses 3 layers to work, the application itself, which
is a perfectly standard Android application, relying on Java $\rightarrow$ C
bindings integrated in the Android framework, which in turn relies on libusb
-that we included in the system libraries.\\
+that we included in the system libraries.
We can't have a real USB missile launcher for participant,
so the \code{DummyBackend} class is provided to test that your application and the
diff --git a/labs/android-boot/android-boot.tex b/labs/android-boot/android-boot.tex
index 3a3aa45..e16fc45 100644
--- a/labs/android-boot/android-boot.tex
+++ b/labs/android-boot/android-boot.tex
@@ -19,10 +19,10 @@ The Android emulator uses QEMU to create a virtual ARM9 SoC called Goldfish.
In the standard Android source code we fetched, the kernel source is not included.
So the first thing to do is download the Android kernel sources.
-\code{git clone https://android.googlesource.com/kernel/goldfish.git kernel}\\
+\code{git clone https://android.googlesource.com/kernel/goldfish.git kernel}
Now that we have kernel sources, we need a toolchain to compile them. Fortunately,
-Android provides one. First, add the toolchain to your path.
+Android provides one. First, add the toolchain to your \code{PATH}.
\code{export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH}
@@ -52,9 +52,9 @@ from the official kernel to get a point of reference to know which commits
differ. Git is great for that and offers everything we need to do so.
First, add the linux-stable repository from Greg Kroah-Hartmann to our
-repository:\\
+repository:
-\code{git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git}\\
+\code{git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git}
Now, we need to fetch the changes from this remote repository:
@@ -69,9 +69,9 @@ differ from the linux kernel by doing:
\code{git log v<kernel-version>..HEAD}
-Find in that set of commits the one that adds the wakelocks.\\
+Find in that set of commits the one that adds the wakelocks.
-Now, extract the set of patches with the \code{git format-patch} command.\\
+Now, extract the set of patches with the \code{git format-patch} command.
Congrats! You now have all the patches to apply to a vanilla kernel to obtain a
full Android kernel.
diff --git a/labs/android-first-compilation/android-first-compilation.tex b/labs/android-first-compilation/android-first-compilation.tex
index e948ba2..68acdcd 100644
--- a/labs/android-first-compilation/android-first-compilation.tex
+++ b/labs/android-first-compilation/android-first-compilation.tex
@@ -31,7 +31,7 @@ You will see that \code{build/envsetup.sh} hasn't modified your \code{PATH}.
This will be done during the build job.
The target product for the emulator is {\it generic}, and we want to have an
-engineering build. To do this, run \code{lunch generic-eng}.
+engineering build. To do this, run \code{lunch generic-eng}
\section{Compile the root filesystem}
diff --git a/labs/android-jni-library/android-jni-library.tex b/labs/android-jni-library/android-jni-library.tex
index 2a15ee2..ee43f56 100644
--- a/labs/android-jni-library/android-jni-library.tex
+++ b/labs/android-jni-library/android-jni-library.tex
@@ -19,7 +19,7 @@ mostly have to modify function prototypes from your previous
application to make it work with JNI.
As a reminder, JNI requires the function prototype to be like:
-\code{JNIEXPORT <jni type> JNICALL Java_<package_class>_function(JNIEnv *env, jobject this)}.\\
+\code{JNIEXPORT <jni type> JNICALL Java_<package_class>_function(JNIEnv *env, jobject this)}.
Aside from the \code{jni} folder, there is also a \code{java} folder that
contains a Java Interface, \code{MissileBackendImpl}. In the same folder,
@@ -30,7 +30,7 @@ file.
\section{Integrate it in the build system}
Now you can integrate it into the build system, so that it generates a .jar
-library that is in our product, with the proper dependencies expressed.\\
+library that is in our product, with the proper dependencies expressed.
You can find documentation about how to integrate device-specific parts of the
framework in the \code{device/sample/frameworks} folder.
@@ -40,18 +40,18 @@ framework in the \code{device/sample/frameworks} folder.
We should now have a system with the files
\code{/system/framework/com.fe.android.backend.jar}, containing the Java
classes, \code{/system/lib/liblauncher_jni.so}, containing the JNI bindings and
-\code{/system/lib/libusb.so}.\\
+\code{/system/lib/libusb.so}.
Test what you did using the Main class present in the Java source code
by directly invoking Dalvik through the \code{dalvikvm} command. You
-will have to provide both the classpath and the class name to make it work.\\
+will have to provide both the classpath and the class name to make it work.
\section{Going further}
You will find that the binary we developed in the previous lab and
the bindings share a lot of common code. This is not very convenient
to solve bugs affecting this area of the code, since we have to make
-the fix at two different places.\\
+the fix at two different places.
If you have some time left at the end of this lab, use it to make this
common code part of a shared library used by both the bindings and the
diff --git a/labs/android-native-app/android-native-app.tex b/labs/android-native-app/android-native-app.tex
index 0a5d2e7..e399413 100644
--- a/labs/android-native-app/android-native-app.tex
+++ b/labs/android-native-app/android-native-app.tex
@@ -11,19 +11,19 @@ After this lab, you will be able to:
Copy the \code{mlbin.c} file from the
\code{/home/<user>/felabs/android/native-app} directory and put it
-into the \code{external/ml} folder.\\
+into the \code{external/ml} folder.
As you can see, the application is almost empty, so you need to fill
it with the appropriate code. You will need to implement an
initialization function, basic functions to control the launcher and
-finally a freeing function.\\
+finally a freeing function.
You will need the \code{libusb_init}, \code{libusb_get_device_list},
\code{libusb_get_device_descriptor}, \code{libusb_open},
\code{libusb_detach_kernel_driver} and \code{libusb_claim_interface}
functions to initialize our program, the matching functions to exit
properly are \code{libusb_exit}, \code{libusb_close}
-and \code{libusb_reclaim_interface}.\\
+and \code{libusb_reclaim_interface}.
You can send an instruction by using the code
\begin{lstlisting}
@@ -36,14 +36,14 @@ libusb_control_transfer(devh, 0x21, 0x09, 0, 0, data, 5, 300};
Just as for \code{libusb}, you now need to make an \code{Android.mk} file
giving all the details needed by the build system to compile. But
unlike \code{libusb}, this binary is an executable and depends on another
-piece of software.\\
+piece of software.
Make it compile and be integrated in the generated images. Once you
have the images, boot the board, plug a missile launcher and test the
-application. You should see the launcher move.\\
+application. You should see the launcher move.
However, when you start your tests, you will find that \code{libusb} cannot open
the usb devices because of restricted permissions. This can be fixed
through \code{ueventd.rc} files. Add a device-specific uevend
configuration file to your build to make the files under
-\code{/dev/usb/} world readable.\\
+\code{/dev/usb/} world readable.
diff --git a/labs/android-native-library/android-native-library.tex b/labs/android-native-library/android-native-library.tex
index 3c09dc1..6e067e4 100644
--- a/labs/android-native-library/android-native-library.tex
+++ b/labs/android-native-library/android-native-library.tex
@@ -10,11 +10,11 @@ After this lab, you will be able to
\section{Building a static library}
To get the libusb source code, go to \url{www.libusb.org} and download
-version 1.0.8. Extract the archive in the \code{external/libusb} folder.\\
+version 1.0.8. Extract the archive in the \code{external/libusb} folder.
For this library, all the needed \code{.c} files are located in the \code{libusb}
folder and its subfolders. The headers are located in the same folders. Make
-the build system generate a \code{libusb-static.so} file.\\
+the build system generate a \code{libusb-static.so} file.
You will find one missing header that you will need to generate. Indeed, the
\code{config.h} generated by autoconf is not generated at all, because the
diff --git a/labs/android-new-board/android-new-board.tex b/labs/android-new-board/android-new-board.tex
index c323656..21d1444 100644
--- a/labs/android-new-board/android-new-board.tex
+++ b/labs/android-new-board/android-new-board.tex
@@ -26,7 +26,7 @@ One of the platform supported by the Linaro's Android is the BeagleBoard, which
is very similar to the DevKit8000 we use. Moreover, in the last kernel versions,
the kernel needed for both of these cards have been unified, so we can boot the
exact same kernel on both these boards. For these reasons, we will use this
-distribution as a starting point for the rest of the labs.\\
+distribution as a starting point for the rest of the labs.
First, we need to download the source code. We will use the 11.11 release, which
is based on Android 2.3 Gingerbread and Linux 3.1.1.
@@ -45,13 +45,14 @@ You will also need to download the associated Linaro toolchain at
\section{Build Android for the BeagleBoard}
As we said earlier, the DevKit8000 is very similar to the BeagleBoard, so we
-will first compile a build for the BeagleBoard. The command to run is:\\
+will first compile a build for the BeagleBoard. The command to run is:
+
\code{make TARGET_PRODUCT=beagleboard TARGET_TOOLS_PREFIX=~/android/linaro/android-toolchain-eabi/bin/arm-eabi- boottarball systemtarball userdatatarball -j8}
This will build three tarballs in \code{out/target/product/beagleboard}:
\code{boot.tar.bz2}, \code{system.tar.bz2}, \code{userdata.tar.bz2}, plus the images of Xloader,
U-Boot, Linux kernel and its initramfs (which are also contained in
-\code{boot.tar.bz2}).\\
+\code{boot.tar.bz2}).
We then need to put these images on SD card so that we can boot on this system.
Linaro developed a set of scripts that takes the three tarballs and aggregates
@@ -69,7 +70,7 @@ bzr branch lp:linaro-image-tools
Now, we can remove the SD card and insert it into its slot in the DevKit8000,
and we can boot on it holding the boot key while switching the board on. On the
serial port, you should see Android going through its booting process, until
-you finally have a shell on the serial link.\\
+you finally have a shell on the serial link.
However, as you may have seen, while the system boots, you have no display at
all, so we will need to fix this.
@@ -80,7 +81,7 @@ The first problem we see is that the display remains blank the whole time. This
is because of the generated U-Boot being targeted for the BeagleBoard and not
for the DevKit8000. In the BeagleBoard product definition, find where the U-boot
config file to use is set and change this configuration to use the default
-configuration for the DevKit8000 (\code{devkit8000_config}).\\
+configuration for the DevKit8000 (\code{devkit8000_config}).
Compile and test your changes. You should now see the display working, while it
has a major glitch: it prints only a portion of the screen.
@@ -96,15 +97,15 @@ command line. On the SD card's boot partition, you will find a file named
\code{boot.txt} which is a U-Boot's script setting all the needed parameters for the
board to boot properly, including the kernel command line. Change the
\code{omapdss.def_disp} and \code{omapfb.mode} properties so that it uses the LCD instead of
-the DVI output and at the correct resolution.\\
+the DVI output and at the correct resolution.
You can find some documentation for these options in the file
\code{kernel/Documentation/arm/OMAP/DSS}, in the Kernel boot arguments section.
-\\
-You'll then have to generate from this \code{boot.txt} file a \code{boot.scr} file
+You will then have to generate from this \code{boot.txt} file a \code{boot.scr} file
using the following command:
-\code{mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Execute uImage.bin' -d boot.txt boot.scr}\\
+
+\code{mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Execute uImage.bin' -d boot.txt boot.scr}
Once this is done, test your changes by booting the board. You should see the
display working correctly now.
@@ -115,7 +116,7 @@ If you test the touchscreen with the previous Android build you made, you should
see that it is almost unusable, while the system receives some inputs. This mean
that the kernel has the driver for the touchscreen controller, but it returns
bogus values. If you pay attention however, you will find that the touchscreen
-doesn't have the same orientation as the display.\\
+doesn't have the same orientation as the display.
Get back to the documentation of the DSS to find an option that might address
this problem.
@@ -124,13 +125,13 @@ this problem.
These tweaks are not persistent because the \code{boot.scr} file is generated at run
time by the \code{linaro-android-media-create} tool. To automate this, modify it to add
-a ``devkit8000'' target device with the proper command line for the kernel.\\
+a ``devkit8000'' target device with the proper command line for the kernel.
To do so, you will need to edit the files
\code{linaro_image_tools/media_create/boards.py} and
\code{linaro_image_tools/media_create/android_boards.py} to add \code{class} entries in each
file to specify the correct boot command for your board. It should not take more than 10 lines to
-add.\\
+add.
You can also add \code{no_console_suspend} to the bootargs as Android by
default suspends the shell on the serial line after a minute or so, making it pretty
@@ -140,29 +141,29 @@ hard to use it properly.
If you happen to launch an application, you will find that you cannot
get back to the home screen, as no button is mapped to \code{back} or \code{home}
-keys.\\
+keys.
The button mapping is done in two steps. First, in the kernel, the
board should define the buttons available. In this case, we will use
the small black buttons right next to the screen on the
DevKit8000. These buttons are handled by the \code{gpio-keys} driver,
-and defined in the devkit8000 board file in the kernel.\\
+and defined in the devkit8000 board file in the kernel.
If you look into that file, you will see that only one button is
defined, the one corresponding to the button labeled \code{user key}
-on the board.\\
+on the board.
We will map this button to the back key in Android. In the
\code{gpio_keys_button} structure, there is a \code{code} field. The
value of this field defines the keycode sent to the input
subsystem when you press that button, and will be later dispatched to
the userspace. Replace the keycode used by \code{KEY_EXIT} and look up
-its value in the \code{include/linux/input.h} file.\\
+its value in the \code{include/linux/input.h} file.
The Android input system loads keymaps and keylayouts for each input
driver loaded. To load it properly, it uses the same name than the
input driver, with an extension. In our case, the input driver being
-\code{gpio-keys}, we will need to modify the \code{gpio-keys.kl} file.\\
+\code{gpio-keys}, we will need to modify the \code{gpio-keys.kl} file.
This file consists in a list of entries, corresponding to what actions
every keycode should trigger in the system. Add a new entry to this file
diff --git a/labs/android-system-customization/android-system-customization.tex b/labs/android-system-customization/android-system-customization.tex
index db8eeac..cba50a0 100644
--- a/labs/android-system-customization/android-system-customization.tex
+++ b/labs/android-system-customization/android-system-customization.tex
@@ -13,16 +13,16 @@ After this lab, you will be able to:
Revert the changes you made to the beagleboard product and define a new product
named \textit{training} instead. This product will have all the attributes of
the beagleboard product for now, plus the extra packages we'll add along the
-labs.\\
+labs.
As we are still using the same platform, the product name returned by the
kernel doesn't change, even though we compiled a different product. Change
the name of the product that is used through the command line passed to the
kernel to match the name of your product. You can pass the product name through
-the \code{android.hardwareboot} property.\\
+the \code{android.hardwareboot} property.
Now, setup a custom init config file that will be used only by your product and
-make it create the file \code{/data/hello_world}.\\
+make it create the file \code{/data/hello_world}.
The system should compile and boot flawlessly on the DevKit8000, with all the
corrections we made earlier.
@@ -40,4 +40,5 @@ modifying the original source code.
As we have seen, properties are extensively used around the Android system.
Extend the \code{system.prop} file of the \textit{training} product by adding a
\code{foo.bar} property.
+
Boot the system and use getprop to check if the property has indeed been added.
http://git.free-electrons.com/training-materials/commit/?id=6299956a047f8b32665ec75fd4bb3b8d1ce417f2
commit 6299956a047f8b32665ec75fd4bb3b8d1ce417f2
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date: Tue Jun 5 06:42:46 2012 +0200
Misc source and compilation fixes
- The emulator is found in the PATH after the build
- Removed unnecessary "\\" at the end of some paragraphs,
making spacing between paragraphs look weird.
diff --git a/labs/android-first-compilation/android-first-compilation.tex b/labs/android-first-compilation/android-first-compilation.tex
index ae49100..e948ba2 100644
--- a/labs/android-first-compilation/android-first-compilation.tex
+++ b/labs/android-first-compilation/android-first-compilation.tex
@@ -13,19 +13,27 @@ Stay in the \code{/home/<user>/felabs/android/aosp/android} directory.
\section{Build environment}
Now that \code{repo sync} is over, we will compile an Android system for the
-emulator. First, be sure that the emulator is in your path. You can check
-by running the \code{emulator} command in a terminal.\\
+emulator. This will include building the emulator itself.
-Now, run \code{source build/envsetup.sh}.
+First, run \code{source build/envsetup.sh}.
This file contains many useful shell functions and aliases, such as \code{croot} to
go to the root directory of the Android source code or \code{lunch}, to select
-the build options.\\
+the build options.
+
+Check your \code{PATH} environment variable:
+
+\begin{verbatim}
+echo $PATH
+\end{verbatim}
+
+You will see that \code{build/envsetup.sh} hasn't modified your \code{PATH}.
+This will be done during the build job.
The target product for the emulator is {\it generic}, and we want to have an
-engineering build. To do this, run \code{lunch generic-eng}.\\
+engineering build. To do this, run \code{lunch generic-eng}.
-\section{Compile the root filesystem
+\section{Compile the root filesystem}
The build system will use the proper setup to build this target. Before running
\code{make}, first check the number of CPUs cores in your workstation, as seen by
@@ -49,7 +57,17 @@ make -j 8
\end{verbatim}
Go grab (several cups of) coffee, and you will have the system compiled in three
-images in the folder \code{out/target/product/generic}.
+images in the \code{out/target/product/generic} folder.
+
+\textbf{Known issue}: in rare circumstances, some builds can fail when \code{make}
+is run with multiple jobs in parallel. If this happens, you can run \code{make}
+with no option after the failure, and this is likely to make the issue disappear.
+
+\section{Test your Android build}
+
+Now, look at the \code{PATH} environment variable again. It should now contain
+extra directories with new binaries produced by the build job.
-Run the emulator with these newly generated images and check the build version
-in the Settings application in Android.
+Run the \code{emulator} command. It will run the emulator with the newly generated images.
+Wait a few minutes for the emulator to load the system, and then
+check the build version in the \code{Settings} application in Android.
diff --git a/labs/android-source-code/android-source-code.tex b/labs/android-source-code/android-source-code.tex
index 45fa964..3f04e2e 100644
--- a/labs/android-source-code/android-source-code.tex
+++ b/labs/android-source-code/android-source-code.tex
@@ -25,11 +25,11 @@ sudo apt-get install git-core curl
Android sources are made of many separate Git repositories, each containing a piece
of software needed for the whole stack. This organization adds a lot of
flexibility, allowing to easily add or remove a particular piece from the source
-tree, but also introduces a lot of overhead to manage all these repos.\\
+tree, but also introduces a lot of overhead to manage all these repos.
To address this issue, Google created a tool called Repo. As Repo is just a
python script, it has not made its way in the Ubuntu packages, and we need to
-download it from Google.\\
+download it from Google.
\begin{verbatim}
mkdir $HOME/bin
@@ -38,7 +38,7 @@ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > $HOME/bin/repo
chmod a+x $HOME/bin/repo
\end{verbatim}
-We can now fetch the Android source code:\\
+We can now fetch the Android source code:
\begin{verbatim}
mkdir android
http://git.free-electrons.com/training-materials/commit/?id=18449a6bdedd7fc79df8f38021e5165b8f31731b
commit 18449a6bdedd7fc79df8f38021e5165b8f31731b
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date: Mon Jun 4 17:25:07 2012 +0200
Instruct to use "make -j x"
diff --git a/labs/android-first-compilation/android-first-compilation.tex b/labs/android-first-compilation/android-first-compilation.tex
index c7e93ab..ae49100 100644
--- a/labs/android-first-compilation/android-first-compilation.tex
+++ b/labs/android-first-compilation/android-first-compilation.tex
@@ -10,7 +10,7 @@ During this lab, you will:
Stay in the \code{/home/<user>/felabs/android/aosp/android} directory.
-\section{Compile a filesystem}
+\section{Build environment}
Now that \code{repo sync} is over, we will compile an Android system for the
emulator. First, be sure that the emulator is in your path. You can check
@@ -18,15 +18,35 @@ by running the \code{emulator} command in a terminal.\\
Now, run \code{source build/envsetup.sh}.
-It contains many useful shell functions and aliases, such as \code{croot} to
+This file contains many useful shell functions and aliases, such as \code{croot} to
go to the root directory of the Android source code or \code{lunch}, to select
the build options.\\
The target product for the emulator is {\it generic}, and we want to have an
engineering build. To do this, run \code{lunch generic-eng}.\\
-The build system will use the proper setup to build this target, so that we
-only have \code{make} to run now.\\
+\section{Compile the root filesystem
+
+The build system will use the proper setup to build this target. Before running
+\code{make}, first check the number of CPUs cores in your workstation, as seen by
+the operating system (hyperthreading could make your OS see 4 cores instead of 2,
+for example).
+
+\begin{verbatim}
+cat /proc/cpuinfo
+\end{verbatim}
+
+You can use \code{make -j} (\code{j} stands for {\it jobs} to instruct \code{make}
+to run multiple compile jobs in parallel, taking advantage of the multiple
+CPU cores, and making sure that I/Os
+and CPU cores are always at 100\%. This will significantly reduce build time.
+
+For example, if Linux sees 4 cores, you will get good performance by specifying
+the double number of parallel jobs:
+
+\begin{verbatim}
+make -j 8
+\end{verbatim}
Go grab (several cups of) coffee, and you will have the system compiled in three
images in the folder \code{out/target/product/generic}.
-----------------------------------------------------------------------
Summary of changes:
common/labs.sty | 7 +--
labs/android-adb/android-adb.tex | 22 +++----
labs/android-application/android-application.tex | 2 +-
labs/android-boot/android-boot.tex | 12 ++--
.../android-first-compilation.tex | 62 ++++++++++++++++----
labs/android-jni-library/android-jni-library.tex | 10 ++--
labs/android-native-app/android-native-app.tex | 12 ++--
.../android-native-library.tex | 4 +-
labs/android-new-board/android-new-board.tex | 35 +++++------
labs/android-source-code/android-source-code.tex | 6 +-
.../android-system-customization.tex | 7 ++-
11 files changed, 109 insertions(+), 70 deletions(-)
More information about the training-materials-updates
mailing list