Research on the Development of the Android platform for Refresh (1)

I haven't been on the blog for a long time. I don't even remember the real user name and password. Back to the truth, a friend recently asked me how to create a QR code for the Android platform. I finally convinced myself to study how to create an Android platform, maybe the method I learned is not comprehensive, and I have taken a lot of detours, but this is a trace of exploration, we hope that we can save valuable time for those who are interested in this and try to avoid mistakes I have made.

Here, we need to explicitly declare:
Because the Android platform has been updated too frequently, it may not be easy to use or be completely correct (just record some experiments I have performed on my Nexus One ). I am not responsible for any problems with your mobile phone !!

If you are a good English friend, you can simply look at the official reference website in English without having to look at the noise:
Http://forum.xda-developers.com/showthread.php? T = 566235
Http://android-dls.com/wiki/index.php? Title = HOWTO: _ unpack % 2c_edit % 2c_and_re-pack_boot_images

Users who only use the android source code to do some simple experiments can refer to the following websites:
Http://nhenze.net /? Tag = build-android
Http://developer.htc.com/adp.html

Speaking of Android refresh, it sounds mysterious. In fact, it is just a digital zip package. If you want to create a refresh box by yourself, you must understand the basic working principle of the refresh box. Let's start with the Android system:

When the Android system starts, it first performs operations such as hardware self-check. After these operations are completed (at least it should know whether the current machine has electricity ), check the current mobile phone button status (next, the so-called flash mode switch, different Android phones have different key combinations to enter the flash mode). If the key status is in the flash mode, then the system will call a program called Recovery in ROM (this is the so-called Flash program, it is just a tool program, it is used to check the integrity of the refresh and the validity of the digital signature. At present, the legitimacy of the digital signature will not be a problem for most root machines. Then, the Recovery Program will decompress the recovery program and then write the files in the recovery into the Rom, to complete the flash process). If the key is not marked as the flash mode, the system will create a memory disk and start loading the corresponding file system from the Rom, and copy the relevant files to the memory disk, and then boot Linux, then start the Virtual Machine Dalvik, then create a working process to load and run the framework, and then you will see the standby screen. Of course there are still many things happening in this process, and many services are started. To simplify the process, I will only explain it here, if you are interested, you can compare them with the Linux Startup Process.

To sum up, in fact, the Recovery Program is a compressed ROM file package. After the flash mode is enabled, the Recovery Program will write the files in the recovery into the ROM storage area to replace the original files in the ROM storage area; when you start the phone next time, the system will load the replaced files from the ROM and use these files to start and run the system. This is all the functions and functions of the Refresh. If you don't understand it, you can read it several times. The essence of the refresh is file coverage and replacement operations. I believe you can understand it!

OK. Now we know that the zip package of the ROM file is the so-called brush package. The process of creating a refresh is to prepare these files and then compress these files into a zip package. At the end of the process, sign the file using the signature tool, you can test and release the refresh feature. Although it is just one sentence, the process of preparing these files is very painful and long.

What files are contained in the update.zip package? How are these files made? Hohoat: Now, the problem is solved by starting from the beginning. After Uncompressing this update.zip package, we can see two directories and one file:

Boot. IMG <--- file, which is the kernel image generated by compiling the kernel source code, and then ramdisk compiled with the android source code. IMG was created through the mkbootimg tool together. Friends who save time can copy a usable image from other online refresh tools, which is almost the same.

META-INF <--- directory, this directory is manually created, mainly used to store an upgrade script Update-script (the content of this script is highly associated with the files contained in the system directory) and save the signature of several APK files in the refresh folder.

System <--- Directory, which is generated by compiling the source code of the Android platform,

The best learning method is to unpack the update.zip package on the Internet now, read and analyze the package one by one, modify the package one by one, and try to do your own refresh.

For this boot. IMG, the basic idea is to compile the android kernel code, generate the kernel image, and then use mkbootimg to refer to the following two wiki websites:
Http://android-dls.com/wiki/index.php? Title = HOWTO: _ unpack % 2c_edit % 2c_and_re-pack_boot_images

Http://android-dls.com/wiki/index.php? Title = replace_recovery_partition

The following practices are even completed in Linux (slackware 13.1 ):
(1) download and compile the android source code.
If you do not know the commands such as repo sync, you can refer to the articles on the Internet about downloading Android source code and compiling. These articles are very rich as I know. You must pay attention to the platform selection before compiling. Drivers for different platforms are different! You can use the following parameters:
$ CD Android-Src <--- enter the android source code directory
$. Build/envsetup. sh <--- set environment variables. After running the command, you can enter the HELP command to see how many convenient commands the Google team provides, this is very helpful for us to modify the code and re-compile it later.
$ Lunch generic-Eng <--- start to configure the compilation options of the android source code
After running the preceding command, the following output is displayed:
Wayne @ WAYNE :~ /Android-Src $ lunch generic-Eng

========================================================== ====
Platform_version_codename = REL
Platform_version = 2.1-update1
Target_product = generic
Target_build_variant = ENG
Target_simulator = false
Target_build_type = release
Target_arch = arm
Host_arch = x86
Host_ OS = Linux
Host_build_type = release
Build_id = eclair
========================================================== ====

$ Make-J2 <--- only friends with dual-core CPUs can try this parameter. Users with quad-core CPUs can try-J4. Otherwise, they can simply run make: D.

Then there is a long wait, which takes about 1-2 hours (even if the machine is slow). After the compilation is complete, the hard disk will take about 8 GB.

(2) After compilation, enter Wayne @ WAYNE :~ The/Android-src/out/target/product/Generic Directory should see the following file:
Android-info.txt
Data
OBJ
Ramdisk. img
SDK
System
Userdata. img
Clean_steps.mk
Installed-files.txt
Previous_build_config.mk
Root
Symbols
System. img
Is system. IMG very familiar ?! In this case, the refresh folder also seems to have a directory named system. What are there in this system. IMG? This is actually the content in a directory named system in the current directory, but it is saved as the format of the yaffs file system. We can use the unyaffs tool to parse system. IMG to understand what we are talking about.
The unyaffs code is:
Http://code.google.com/p/unyaffs/downloads/list
The compilation method is very simple. You only need to download the source code and then run:
$ Gcc-C unyaffs. c
$ Gcc-O unyaffs. o
You can generate the unyaffs unpack tool. You can use this tool to unpack your own system. IMG, and then modify the content.
Unyaffs is easy to use:
$ Unyaffs system. IMG [Press enter]
You can decompress system. IMG into a directory named system, which contains the entire android File System (what is a file system ?! If you ask this question, I will not even talk about it. Go home and chew on the computer-specialized operating system in the university)

(3) At the beginning, it is not suitable for everything from the beginning. We should be honest with each other. Let's start by modifying the refresh of other experts.
First, copy a refresh token downloaded from the internet and find a directory to decompress the package (of course, this is the safest practice. It is not a problem to make these directories by yourself, but it takes a lot of time)
$ Unzip xxxxxx.zip <--- this xxxxx.zip is a refresh token downloaded from the Internet (it must be basically the same as your code version. Here I use a refresh token of 2.1)

(4) replace the original system directory
After decompressing and refreshing, you will see the two directories mentioned at the beginning, one file:
Boot. img
META-INF
System
Now, you can copy the system directory to another path and back it up to prevent other problems from these modifications. Then run Wayne @ WAYNE :~ Copy the system in the/Android-src/out/target/product/Generic Directory to the current working directory. Note that many "Symbolic Links" in this system directory point to toolbox. These links are useless and can be automatically created using the update-script later. Therefore, you need to delete these links using a script.
Refer:
Http://forum.xda-developers.com/showthread.php? T = 566235
The attachment of this webpage is changed to deleteextras.txt to a deleteextras. Sh script to clear these symbolic links.

(5) modify the update-Script script
Modify the META-INF/COM/Google/Android directory that is called Update-script Script script, as long as you modify it, it mainly deletes some non-existing files and adds definitions such as the permissions of some files (the syntax is very clear and clear at a glance ). Prepare the APK installer that requires "pre-installation" to the refresh box and copy the APK to the system/APP directory. The boot. IMG won't be changed if it can be changed, because it involves driver and kernel issues and cannot be started when a problem occurs.

(6)re-package into update.zip
$ Zip-r update.zip. <--- note that the last "." is indispensable, which indicates the meaning of the current path.

(7) signatures for well-prepared refresh accounts
In the link mentioned above, there is a tool named autosign. It is a jar toolkit. However, it is depressing that the author of this Toolkit forgot to add the following name to manifest. MF when creating the jar package:
Main-class: testsign
I tried to solve this problem by using the tool and re-creating a jar package.
To facilitate your use, I have even pasted the modified signature tool as an attachment to save your time.
In addition, you need to mention that this signature tool is made using JDK 1.6.10. Therefore, you must meet the requirements of the Java tool version.
Run the following command to sign the hacker:
$ Java-jar testsign. Jar update.zip update_signed.zip

OK. After the signature is completed, you can back up the items in the mobile phone and test it.

Good luck!

 

Http://blog.chinaunix.net/link.php? Url = http://blogimg.chinaunix.net %2fblog%2fupfile2%2f100310105708.gz