Android build system analysis 1

If you have nothing to worry about, analyze the android build system and hope to help your work. It may be helpful to others.

 

Android is undoubtedly a very large system. It seems that it is also a very young and dynamic system. By studying its build subsystem, we can at least see how a large system is written.

 

Makefile, many people may think that this is too simple or even not required in many cases. I just need to compile the source code in GCC. This idea can be used when the program is small, but if you want to write a large system, if you want to keep up with the previous manual workshop model, it will only bring a lot of trouble to yourself.

 

We are not concerned with makefile syntax and remote usage. Instead, we will learn what problems it solves with makefile about build management in the Android system.

 

Pink ink debut

 

Product. Android supports several products, such as HTC's dream, hero, nexus, and Motorola Droid, and Google's own generic Android source code.

 

Variant. During Android build, you can specify several variant types, such as user, userdeubg, Eng, and tests. Through these options, different programs can be compiled. Eng is for engineers and user is for end customers.

 

Subsystem. There are many different programs in the Android platform. There are some running on the mobile phone and some running on the PC. There are programs and libraries. There are dynamic libraries and static libraries. There are code and documents. There are C, C ++, and Java. There is also a keyboard/character ing table. These are all compiled.

 

Inheritance relationship. There is an inheritance relationship between roles of many products. For example, Google's own product is not actually a product, but a reference design. However, the products of all other manufacturers must be inherited from Google's reference design. If every vendor needs to define many of its own standards from the ground up, it will be very labor-intensive and difficult to maintain. Just like a human-created Tower, it is impossible to succeed. Google defines a set of standards to encourage manufacturers to use them.

 

Dog bark

 

Okay. Let's take a look at the code.

 

There are some. mk files under build/target/product. The format is makefile, where:

 

Core. mk defines product_packages. That is to say, basically all Android-based systems must have these packages. Browser, contacts, launcher, and phone are all defined here. Other manufacturers' versions do not have to define these packages.

 

Generic. mk defines several additional packages and inherits core. mk.

 

Speaking of this, you may find it strange that inheritance is not an object-oriented concept. How can we "inherit" in makefile? In this case, it is wrong. Makefile can be inherited. Even the assembly language, you can inherit. The language is only convenient, but the key is how people use it.

 

C ++ provides inheritance, but it is not a language specifically designed for build management. Makefile is a language specifically designed for the build system. However, when we see a system like android that uses the concept of inheritance, experienced developers will certainly not be so rigid, because a language is helpless without any inherent features. They will consider two solutions

 

1. Change Language. For example, I re-write a build language. In Java, Ant and jam of the boost C ++ library.

 

2. You can use existing programming languages to implement the required features.

 

In general, the factors that affect the final decision should undoubtedly be the cost. It costs a lot to invent a new language. So we can see that Android Developers chose the latter.