Compiling a new version of Android source code on an old 32-bit system sounds like a technical challenge that is destined to go through difficult twists and turns from the beginning, and the compatibility issues behind it often cause developers to consume a lot of energy.
The importance of preparation
Before starting to compile, it is critical to ensure that the operating system environment is sufficiently prepared. Ubuntu 10.04 is a relatively old distribution, and its default software source is very likely to be invalid, so it must be manually updated or replaced with a data mirror source that can be used normally. When installing various development toolkits required for compilation, be sure to pay attention to the differences between 32-bit and 64-bit library files to prevent subsequent steps from failing due to missing dependencies.
The basis is correct configuration of the Java environment. For source code in the Android 3.0 (Honeycomb) era, the official recommendation is to use JDK 6 instead of JDK 5. The mainstream method at that time was by adding a specific PPA source and installing the sun-java6-jdk package. After installation, you must manually check and set environment variables such as JAVA_HOME so that they point to the actual installation path of JDK 6. This is a prerequisite for the compiled script to correctly identify the Java environment.
Obtaining and configuring core tools
As the first step to download the source code, you need to obtain the code management tool Repo. Because it does not belong to the standard system package, the user must download it in person. Generally, you need to create the bin folder in the user directory, add it to the system path, and then use the curl command to obtain the repo script from Google's server and give execution permissions. And this process must pay attention to network connectivity.
After the repo is configured, the code repository can be initialized. The first step is to create a specially set working directory, like ~/.android_source, and then execute the repo init command in this directory to specify the remote address of the source code repository. For early Android versions, the code repository address is different from now, so you have to confirm the correct Git address.
The long process of downloading source code
Initiate the repo sync command to synchronize the code. The entire Android source code tree is extremely large. Even for the relatively early version 3.0, the volume may reach several GB after adding the SDK. Under network conditions around 2010, downloading using ordinary home broadband would take several hours or even all night. During this time, network stability must be maintained.
Once the synchronization process is interrupted due to network conditions, you can execute the repo sync command again to continue downloading. Sometimes you have to try several times. You may also want to consider looking for a domestic code mirror source and change the initialization address of the repo to speed up. However, this requires ensuring the integrity and timeliness of the mirror.
Key obstacles in the compilation process
At the beginning of compilation, the first step is to run the environment setup script, such as source build/envsetup.sh , and then use the lunch command to select the target device model to be compiled. Then execute the make command to start the build operation. On 32-bit systems, compilation is most likely to stop suddenly here.
The system will throw an explicit error stating that you are trying to build on a 32-bit operating system, as of Android 2.2 (Froyo) only 64-bit system builds are supported. This error does not originate from the code itself, but is a mandatory check in the core files of the build system.
Modify build system rules
In order to bypass this restriction, the configuration file of the build system must be modified. The error message will usually give a prompt to check build/core/main.mk file. Open the file with a text editor and find the conditional judgment code block containing the words "32-bit" and "64-bit".
This code block usually uses ifneq and error instructions to forcefully cause the build to stop. The solution is to use the "#" symbol to comment these lines of key code, thereby masking the mandatory check of the 64-bit system, and save the file after modification. This is an unconventional operation and may introduce unknown risks. However, it is the only way to continue trying on old hardware.
Next steps and potential risks
After adding comments to the check, run the make command again, and the compilation process can continue. However, this only bypasses the first level. In the subsequent compilation process, you may still encounter various errors caused by insufficient memory, conflicting library file versions, or incompatible tool chains. You need to troubleshoot one by one according to the specific error information.
In the end, whether a complete system image can be successfully compiled depends on the hardware resources, the system environment configuration, and the developer's debugging capabilities. Even in 2011, Google had already switched to recommending development in a 64-bit environment. Building on a 32-bit system was a non-standard, unofficially supported "trouble". The process and results were all full of uncertainty.
When transplanting similar old systems or old projects, would you prefer to completely upgrade the hardware environment, or would you rather enjoy the process of solving complex compatibility problems? Feel free to share your experiences and opinions in the comment area. If you feel this article is helpful, please support it by giving it a like.
