This article was first published on wechat official account “Liu Wangshu”

Associated series Android AOSP Basic series Android system startup series Application process startup series Android In-depth understanding of the four major components of Android Context series Android in-depth understanding of JNI series WMS series AMS series Android package management mechanism series Android input system series

preface

In the last article Android AOSP foundation (two) AOSP source download, we will successfully download the AOSP down, many times we not only need to view the source code, but also the following requirements:

  • Dynamic debugging Android system source code
  • Customizing Android
  • Swipe the latest version of Android onto your Android device
  • Import the system source code into Android Studio

In order to achieve these requirements, we need to compile the system source code.

1. Compilation system overview

Understand the following concepts to get a general idea of the Android build system. Makefile The Android build system is essentially a separate project written in a Makefile. It defines the compilation rules and realizes “automatic compilation”. It not only integrates the codes scattered in hundreds of Git libraries, but also outputs the products to a directory and packages them into mobile ROM. It can also generate the SDK and NDK used in application development. Therefore, a compilation system written in makefiles can also be called a Makefile compilation system. The part of the build system that defines the parameters necessary for a module to be compiled with the platform. In plain English, it tells the compilation system what rules to use to compile your source code and generate the corresponding object files.

Ninja Ninja is a small compilation system dedicated to speed, and if other compilation systems are considered high-level languages, the Ninja goal is assembly.

Soong Soong, a replacement for Google’s previous Makefile compilation system, parses android.bp files and converts them into Ninja files

Used to parse android. bp files into Ninja syntax files.

Kati kati is a small project developed by Google specifically for Android, based on Golang and C++. The goal is to convert makefiles in Android into Ninja files.

Android.bp Android.bp, which is used to replace the configuration file android. mk.

The connection between the concepts of Android.mk, Ninja, Soong, Blueprint, Kati, android. bp is as follows:

Blueprint parses the contents of the Android.bp file. Blueprint is like a library file that handles the relevant syntax, while Soong defines how to handle the corresponding syntax and command implementation. In plain English, Soong parses the Android. Bp syntax defined by Blueprint and converts it to Ninja files. The Makefile will be converted to a Ninja file via KATi. As Android projects get bigger, it takes longer to build with Makefiles, so Google introduced Ninja for Android 7.0. Ninja has significant advantages over Makefiles in terms of speed and parallelism for large project management. Makefile The default file name is Makefile or Makefile, and the suffix. Make or. Mk is also commonly used. The default file name for Ninja is Build. Ninja, and all other files have a. Ninja suffix. Makefiles differ from Ninja in that makefiles are designed to be written for developers, while Ninja designs are designed to be generated for other programs. If makefiles are Java, then Ninja is assembly.

2. The way source code is compiled

There are several ways to compile the source code for the Androd system.

  • Compile system source code directly in Linux (Android official support)
  • Compile source code directly in Mac OS (Android official support)
  • Compiled with Docker and supported on Mac OS and Windows

It should be noted that the lowest supported version of Docker is Windows7. It is recommended to use Docker in Windows10 environment, because in Windows7, Docker Toolbox and containers in VirtualBox are needed for communication, which is relatively inefficient. Considering the majority of people’s devices and access to the degree of difficulty, this is to explain in Linux directly compiled system source code, if your system is not Ubuntu, you can view the Android AOSP foundation (a) VirtualBox install Ubuntu this article.

3. Prepare the compilation environment

1. Install jdk8

sudo apt-get update
sudo apt-get install openjdk-8-jdk
Copy the code

2. To use Ubuntu 14+, install the following dependency packages:

sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip
Copy the code

3. Set the number of processors. Choose Settings > System > Processor Options to set the number of processors.

4. Source code consolidation

BGF is to compile the entire Android source code. There are three main steps in BGF, which are described below.

1. Initialize the environment

In the AOSP root directory, enter the following command:

sourceBuild /envsetup.sh // Delete the build folder before compilingCopy the code

Initialize the environment with the envsetup.sh script in the build directory, which introduces additional execution scripts.

2. Select compile target input command:

lunch
Copy the code

The lunch command is a command defined in envsetup.sh that allows the user to select a build target. The following information is output:

You're building on Linux

Lunch menu... pick a combo:
     1. aosp_arm-eng
     2. aosp_arm64-eng
     3. aosp_mips-eng
     4. aosp_mips64-eng
     5. aosp_x86-eng
     6. aosp_x86_64-eng
     7. aosp_car_arm-userdebug
     8. aosp_car_arm64-userdebug
     9. aosp_car_x86-userdebug
     10. aosp_car_x86_64-userdebug
     11. mini_emulator_arm64-userdebug
     12. m_e_arm-userdebug
     13. m_e_mips64-eng
     14. m_e_mips-userdebug
     15. mini_emulator_x86_64-userdebug
     16. mini_emulator_x86-userdebug
     17. uml-userdebug
     18. aosp_cf_x86_auto-userdebug
     19. aosp_cf_x86_phone-userdebug
     20. aosp_cf_x86_tablet-userdebug
     21. aosp_cf_x86_tablet_3g-userdebug
     22. aosp_cf_x86_tv-userdebug
     23. aosp_cf_x86_wear-userdebug
     24. aosp_cf_x86_64_auto-userdebug
     25. aosp_cf_x86_64_phone-userdebug
     26. aosp_cf_x86_64_tablet-userdebug
     27. aosp_cf_x86_64_tablet_3g-userdebug
     28. aosp_cf_x86_64_tv-userdebug
     29. aosp_cf_x86_64_wear-userdebug
     30. cf_x86_auto-userdebug
     31. cf_x86_phone-userdebug
     32. cf_x86_tablet-userdebug
     33. cf_x86_tablet_3g-userdebug
     34. cf_x86_tv-userdebug
     35. cf_x86_wear-userdebug
     36. cf_x86_64_auto-userdebug
     37. cf_x86_64_phone-userdebug
     38. cf_x86_64_tablet-userdebug
     39. cf_x86_64_tablet_3g-userdebug
     40. cf_x86_64_tv-userdebug
     41. cf_x86_64_wear-userdebug
     42. aosp_marlin-userdebug
     43. aosp_marlin_svelte-userdebug
     44. aosp_sailfish-userdebug
     45. aosp_walleye-userdebug
     46. aosp_walleye_test-userdebug
     47. aosp_taimen-userdebug
     48. hikey-userdebug
     49. hikey64_only-userdebug
     50. hikey960-userdebug

Which would you like? [aosp_arm-eng]
Copy the code

BUILDTYPE = aoSP_arm-eng BUILD type = AOSP_ARM BUILD type = ENG BUILD type = eng

Where BUILD indicates the environment in which the compiled image can run, AOSP represents the Android open source project, and ARM indicates that the system runs on the PROCESSOR of ARM architecture. See official documentation for more information. BUILDTYPE refers to build types, and there are three:

  • User: the version used for official release to the market. If you do not have the root permission, you cannot dedug and ADB is disabled by default.
  • Userdebug: Enables root and debug permissions based on the user version. Adb is enabled by default. Generally used for debugging the real machine.
  • Eng: Developer’s version, with maximum permissions (root, etc.), with additional debugging tools for development configuration. Generally used in simulators.

If you don’t have a Nexus device and just want to BUILD and run it in the emulator, then BUILD can be aoSP_x86 and BUILDTYPE eng, Which would you like? [AOSP_ARM-eng] directly enter the corresponding serial number 5.

You can also specify the compile target directly:

lunch aosp_x86-eng
Copy the code

Or (The serial number may be different for different system versions. It is not recommended to use serial number directly.)

lunch 5
Copy the code

The -jn parameter is used to set the number of parallel tasks to be compiled, so as to improve the compilation speed. Previously, I had a CPU core of 6, so the N value should be between 6 and 12. Here we set 6 parallel tasks to compile:

make -j6
Copy the code

After a successful consolidation, the following information will be printed:

The compilation is slower due to virtual machine refactoring, which takes 2 hours and 46 minutes. Will end up in the out/target/product/generic_x86 / directory created three important image file: system.. Img, userdata img, ramdisk. Img. Img: system image, which contains the main Android directory and files, is parsed by init.c and mounted to /system directory. Userdata. img: a user image that stores userdata in the Android operating system. It is parsed by init.c and mounted to /data. Ramdisk. img: the root file system image, which contains important files for booting Android, such as init.rc.

After compiling, you can run the Android VIRTUAL machine with the following command:

source build/envsetup.sh
lunch 5
emulator
Copy the code

If you want to run the vm after compiling, you can run the following command:

emulator
Copy the code

If nothing goes wrong, the emulator starts, and if something goes wrong, there are plenty of solutions online.

5. Single source code

For example, if we want to compile the system Settings application module, we will execute it in the AOSP root directory:

source build/envsetup.sh
lunch 5
Copy the code

Go to Settings directory:

cd packages/apps/Settings
Copy the code

Mm compiles modules in the current directory, not dependent modules.

mm
Copy the code

After the compilation is successful, a message is displayed indicating the path for storing the generated file.

In addition to the Settings. Odex file, also can be in the out/target/product/generic_x86 / system/priv – app/Settings generated directory Settings. The apk.

In addition, the following commands can be single-compiled:

  • MMM: Compiles the module in the specified directory, not other modules it depends on.
  • Mma: Compiles modules and their dependencies in the current directory.
  • Mmma: Compiles all modules in the specified path, including dependencies.

If you modify the source code and want to view the resulting APK file, there are two ways:

  1. Install APK via ADB push or ADB Install.
  2. Use the make snod command to regenerate system.img and run the emulator to view it.

Thank you: www.jianshu.com/p/f514a9312… Wuxiaolong. Me / 2018/07/25 /… Blog.csdn.net/nwpushuai/a… Note. Qidong. Name / 2017/08 / and… www.jianshu.com/p/80013a768… Note. Qidong. Name / 2017/08 / and…

Share big front-end, Android, Java and other technologies to help 50,000 programmers grow and advance.