Summary of AOSP upgrade codebase difficulties

1. Summary

This article describes some difficult problems and solutions that the author encountered when upgrading the codebase.

2. Process

2.1 Prepare source code

The entire upgrade strategy is two steps:

Diff the source code of the upgraded version and the source code of the pre-upgraded version to get a patch
Apply the patch to the vendor's own node and resolve the conflict

Therefore, the first step is to prepare the source code of the two versions before and after the upgrade .

2.2 Configure git repository

The purpose of configuring the git repository is to use git for diff. The reason why you don’t use the diff command that comes with Linux is because of the problem described in the next step.

Initialize the source code of the pre-upgrade version as a git warehouse, which can be submitted to the server (gerrit)

2.3 Source code replacement

This is the trickiest step. Originally, the author deleted all the code before the upgrade, and then copied the code after the upgrade directly. I thought that git would detect the difference immediately, and the difference was the upgrade content. Then the author submitted it to the server. The review found that there were a large number of completely consistent modifications. .

After a bit of google, I learned that this problem occurs because the format of the line breaks of the two codes is different. Let me introduce briefly:

There are two types of line breaks:

CR (Carriage Return), namely\r
LF(Line Feed)，即\n

Line breaks used on different OS:

Unix/Linux: LF, hex is0x0A
MacOS: CR, hex is0x0D
Dos/Windows: CRLF, hex is0x0D0A

Due to the difference in newline characters, the commands that come with Linux diffare not easy to use, and git itself is also based on diffthe encapsulated VCS, so the way of diff will not work (or I just can’t find a way, I don’t know how to ignore the newline characters during diff differences, readers can research by themselves).

The AOSP downloaded by the author on the Linux server is later modified in Windows, so when the file is opened or edited by using some IDE (such as AS, if the LF is not mandatory), it will be converted to CRLF, which leads to the final When submitting, the contents of the two files seem to be exactly the same, but the line break encoding format has been secretly changed, which is recognized by git as modified. (Developing Android with Windows is a joke, and the author is also very helpless)

So the author thought to himself, since it was LF at first, then I will only operate on the Linux server, so as to avoid being forced to transfer.

Return the old version to before the upgrade, delete all files, go to the cp directory of the new version, and submit it with git, all in one go.

Looking at the review code, isn't this still the same as before? Why didn't it work? And noticed a hint:

old mode 100644
new mode 100755

Still google Dafa, and finally found a solution in stackoverflow.

2.4 modify git configuration

ignore file mode (permissions) differences

git config --global core.filemode false

Disable automatic conversion of newline formatting

git config --global core.autocrlf false

Do not commit files containing mixed newlines

git config --global core.safecrlf true

2.5 submit patch

Then repeat the previous steps: roll back the old version to before the upgrade, delete all files, go to the cp directory of the new version, submit it with git, review it, and it’s done!

So far, the difference of codebase upgrade has been obtained.

2.6 apply patch

Switch back to the vendor's own version node, cherry-pick the difference from gerrit, and resolve the conflict.

So far, the codebase upgrade is complete.

3. Conclusions

Line break format: This pit is hard to describe, developers should try to keep the same OS environment
Linux commands: For commonly used commands, you still need to be proficient in using them
Git command: ditto