1. Preface
In Android security research, we often have to improve and compile the Android code, as almost all of the current handset manufacturers have a closed policy on their underlying drivers, Causes us to finish the Android compiles the system not to be able to brush our compilation to the ordinary Android phone, therefore in the general scientific experiment we have compiled the modified Android source code as the simulator, in the form of the simulator proves the experiment success or not.
In fact, Android as an open-source mobile device operating system, Google initially took into account the problem of real-computer compilation, and the solution to this problem is reflected in each Google I/O conference issued by the official mobile phone, the Nexus series of mobile phones. Nexus series mobile phone as Google's release of the Android benchmarking machine, not only to a certain extent to represent and lead the development of the year's Android phones, more solve the problem of developers to compile the source code. This series of equipment using a completely open device layer-driven form allows developers to implement the ability to burn their own source code to the real machine, so that the source code to compile the real machine debugging is no longer a problem. Let me explain how this work is done.
2. Experimental environment and equipment
Laboratory Equipment: NEXUS5 (Japanese version D821).
Lab Environment: Ubuntu14.04 (x64) + JDK 1.7 + python 2.7.6 + make 3.81
3. Preparatory work
The first thing to declare is that this is a 0 basic tutorial, the above experimental environment is the original state of the author's computer, it does not necessarily conform to the requirements of our experiment, so we will gradually improve the experimental environment, so that the purpose is to put my experiment in the problems encountered and the solution to the full display to everyone, Let everyone take a few detours.
3.1. Some preparation for the compilation environment
We refer to the Android OpenSource project website (http://source.android.com/source/ requirements.html) on the Guide to the experiment, in AOSP's Guide to the hardware requirements of the compilation and software requirements to make detailed provisions. This time we want to compile the source code is the Android 4.4.x version, according to the information in the official website, we want to use 64-bit Ubuntu to compile, and at least 100G of disk space; On the software side, because we compiled the 4.4.x (Kitkat) version of the source code, we need the JDK 1.6, in addition, official guide has some other requirements: Python2.6--2.7,gnu make 3.81--3.82,git1.7 or newer (here we don't need to configure Git, Because the source in Officialguide is obtained through git + repo online download, and we take another way to get the source code).
In my build environment, the operating system is 64-bit Ubuntu 14.04, and the disk space reserves the 100G,JDK version of 1.7,make version 3.81,python version 2.7.6.
Now we can see that the Java environment version is higher than the required JDK 1.6, so below we need to do the JDK downgrade work.
First we have to find the JDK 1.6 package, currently on the official website of Oracle has been unable to download, can only own Baidu. Here I provide a JDK 1.6 for Linux x64 installation package for everyone to use: Http://pan.baidu.com/s/1c2e8x6S.
The installation package for JDK 1.6 is a bin file and we need to install it first.
Put this file in your own definition, here I put in the Java file under Home, of course, can also be placed elsewhere. First of all to modify the permissions of this file, or the direct installation will be error, the system will tell you not enough permissions.
chmod 777 Jdk-6u45-linux-x64.bin
After you modify the permissions, you can run the installation.
./jdk-6u45-linux-x64.bin
This process is actually creating the directory of the JDK.
After the Jdk1.6 directory is generated, we need to modify the environment variables, the original Java variables are configured in the/etc/profile, where only the environment variables in this file need to be modified.
After the modification, just make the/etc/profile effective.
Source/etc/profile
After executing this command, reboot.
Then we can check if it takes effect: java–version
Modified successfully!
There may be situations where the make version does not meet the requirements, for this case refer to this blog: http://blog.csdn.net/lr2131/article/details/45673603 (with the Make and Installation guide).
In addition, we need to install some dependent packages on the configuration of the compiled environment, and Google has given the dependencies that different versions of Ubuntu need to install in AOSP Official guide (http://source.android.com/source/ initializing.html), excerpt as follows:
3.2. Some preparation for the source code and the driver version
When we are ready to compile the environment, we should be ready to compile the source code. The goal of the experiment was to burn android4.4.x to Nexus 5, as Google's official device has now been updated to the seventh generation, with a wide variety of smartphones, tablets, smart watches, laptops and other smart devices, and different generations of equipment compatible with the source code version is also within a certain range. As a result, Google has built a wide variety of detailed branches of Android source to fit different devices, such as: Branch ANDROID-5.1.1_R3 (build:lmy48b) only supports Nexus 5, and ANDROID-5.1.1_R1 ( BUILD:LMY47V) support for Nexus 7 (Flo/grouper), Nexus, Nexus Player, because there are different operations agreed plate-making equipment, different operator-specific equipment can not even share a branch of the source code, For example: ANDROID-5.1.1_R4 (build:lmy47z) supports all NEXUS6 devices except T-mobile USA, while T-mobile custom version of the Nexus 6 device requires ANDROID-5.1.1_R5 (build: LYZ28E) branch to support. To sum up, we can conclude that in the real machine compilation, choose the correct source branch is very important, otherwise, once there is no choice, it takes a lot of time to compile, even if the burning to the real machine will also appear to open the situation (the most common is the mobile phone after the card in Google's boot interface).
First of all, we need to determine which of our devices corresponds to the source branch, my device is the Japanese version of the Nexus 5 (ie D821) Nexus 5 mobile phones are only two major versions: D820 and d821,d820 are for the United States to sell models, commonly known as the U.S. version, D821 is all editions except the US version, the so-called Asia-Pacific Edition. Of course, in different countries and regions will also have a different version of the operator, in response to this situation should also pay attention to see if there is a corresponding proprietary source branch. We can use http://source.android.com/source/build-numbers.html to query their own device belongs to the corresponding source branch, because we want to compile the Android 4.4.x version of the source code, Therefore, only the branch of this version is listed with the device's corresponding relationship:
Let's start by explaining what each column in the table represents:
The first column is the build code, and we find the driver for the corresponding device based on the build code and download it.
The second column is the Branch (branch) code, and the different branches correspond to different devices.
The third column is the Android version code, here we focus on the 4.4 series version, therefore is KitKat.
The fourth column is the corresponding device name, it is worth noting that the same device, even if the different operators are released may use different branches of the source code, such as ANDROID-4.4.4_R2 is only for the operators of the custom version of the branch, and R1 support the remaining Nexus 5 devices.
Here, we choose ANDROID-4.4.4_R1 to compile because it supports my device. Note To remember this branch of the build number: ktu84p, after we use this code to find the corresponding device driver and download.
The way to get the source code in Official guide is obtained online through git+ repo, and because the Android source site https://android.googlesource.com/Under normal circumstances can not access, So we do not take the official offer to obtain the source code. In fact, we find on the Baidu will find that there are a lot of downloaded and packaged good Android source code, such as Baidu network disk There are many, I also found from Baidu Network disk, in this share I need the source of the link, for everyone to download the use: HTTP://PAN.BAIDU.COM/S/1SKJJKFJ. Note that it is best to unzip directly under Linux when extracting, and do not use graphical tools such as 2345 for the Windows environment. Pro-Test proves that the use of graphical interface decompression will result in missing files and folders in the source code. I provide the source code is a 7z format of the compressed package, in Linux under the method of extracting files of this format can see: http://www.educity.cn/linux/1241489.html.
Before compiling the work, we can use the compiler cache tool compliercache(ccache) to speed up the compilation. First, we add the following in the environment variable:
Export use_ccache=1
and make the environment variable file effective. Then, we execute at the command line
Prebuilts/misc/linux-x86/ccache/ccache-m 50G
Can.
After downloading the good source code, we will add the driver file to the source code. We can find the hardware driver of the corresponding device and source branch in Https://developers.google.com/android/nexus/drivers#hikey. At this point, the build code in the previous step should come in handy, we find the corresponding driver according to the build code, we just selected the source branch of the corresponding build code is ktu84p, therefore, download the driver of this code name.
The download is three tgz files, we only need to extract three files sequentially, get three shell script files, we first put it in the source root directory.
To execute the three script files sequentially, it is important to note that the role of three script files is to generate the driver file, but before performing the operation, it will let you read the relevant protocol, you must always press the ENTER key to read a line down, and not a click on the end, because the program in the end will let you enter "I ACCEPT", If you press the end of a button, which means that the last step also presses the ENTER key, it will perform the default action, that is, do not accept the protocol, the operation to generate the driver file will not be executed. Here is a little trick, always press ENTER, note the command line flashed the protocol entry, when reading the eighth item can be slowed down, a moment to press ENTER key, finally slowly to the last step, input I accept can. These three files are the same operation flow. Shows the directory of driver files generated after executing the script file.
4. Compiling
After completing the above tasks, we can do the source code compilation work. First, we entered the Android source directory in the terminal, I put my source code in the home.
Initialize the compilation environment, enter
. build/envsetup.sh
This effect can occur.
Load models, enter the lunch command, and list the results that may be compiled by different devices.
In this step, we choose number 6th: Aosp_hammerhead_userdebug, because our Nexus 5 device designator is hammerhead.
AOSP represents a compiled system that is pure and does not have a Google services framework. And the BuildType is also divided into user, Userdebug and Eng, the specific differences see.
After selecting a good device, the system will generate detailed compilation information, here we can confirm the source of the branch, the build number is correct.
Then we can compile, input make–j16 or make–j8,j after the parameter depends on your computer processor core number, j= core number, because my computer is 8 core, so I choose
Make–j16
After nearly three hours of compiling, our source code finally compiled, and at this time, in the source code root directory out of an out directory, the results of the compilation is stored inside.
5. Brush Machine
After compiling the source code, we started to burn the compiled system into the phone. First, connect our Nexus 5 to the computer, be sure to turn on the USB debugging, the phone may prompt the computer to debug this phone, allow. Then, we make the phone into recovery mode, or just the terminal (under the source root directory), enter the following command:
sudo adb reboot bootloader
The phone will then enter recovery mode.
Then we start to brush the machine:
FastBoot flashall–w or Fastboot-w flashall
The process of brushing is about one risotto, and the machine will automatically turn on after the end of the brush.
The brush machine succeeds, we have seen our compiled native AOSP version of the source code.
Android source code compilation NEXUS5 Real Machine compilation