A preliminary understanding of the Linux part of the Android platform

Android is based on the Linux kernel. For friends who like to study the underlying layer, it is natural that they will not miss the opportunity to understand something on the Linux level. Of course, the final goal is to figure out how Linux is combined with the upper-layer lib and virtual machine, but this will happen after Google has completely open-source android. Many details about Linux running can be seen through the ADB shell.

First, use the emulator console to start the simulator and enter the shell interface. After a try, it is found that although many commands are not available, such as find, basic operations such as ls are still possible. Then ECHO $ PATH observes specific available applications and finds that all available applications are concentrated in/sbin,/system/sbin,/system/bin.

Check/sbin

-Rwxr-XR-x Root 228776 recovery

-Rwxr-XR-x Root 102832 adbd

Not to mention, the adbd should be a daemon for communicating with your external ADB. This can also be inferred from the process view. As for the recovery, it should be a repair program, but the specific usage cannot be determined at present. In addition, the programs in this directory should be called by the system itself based on real-time conditions and will not be called by the user in person.

Go to the/system directory and find that there is no sbin directory and bin directory. There are many applications, except for the commonly used Linux Command Line programs provided by toolbox, is Google's own Android development program. In general, the toolbox provided by Android is still relatively simple. If you don't like this kind of operation, it doesn't matter. It works with ADB push, we can install busybox on the Android platform.

Continue, use PS to see the process:

Root 1 0 252 164 c0082240 unzip ab0c S/init

Root 2 0 0 0 c0048eac 00000000 s kthreadd

Root 3 2 0 0 c003acf0 00000000 s ksoftirqd/0

Root 4 2 0 0 c0045e5c 00000000 s events/0

Root 5 2 0 0 c0045e5c 00000000 s khelper

Root 8 2 0 0 c0045e5c 00000000 s suspend/0

Root 33 2 0 0 c0045e5c 00000000 s kblockd/0

Root 36 2 0 0 c0045e5c 00000000 s cqueue/0

Root 38 2 0 0 c0150c44 00000000 s kseriod

Root 74 2 0 0 c005bed0 00000000 s pdflush

Root 75 2 0 0 c005bed0 00000000 s pdflush

Root 76 2 0 0 c005f880 00000000 s kswapd0

Root 77 2 0 0 c0045e5c 00000000 s AIO/0

Root 199 2 0 0 c014e2f4 00000000 s mtdblockd

Root 215 2 0 0 c0045e5c 00000000 s kmmcd

Root 229 2 0 0 c0045e5c 00000000 s rpciod/0

Root 446 1 4416 216 ffffffff performanceb4 S/sbin/adbd

Root 447 1 2816 284 ffffffff afe08b9c S/system/bin/usbd

Root 448 1 636 212 c017c114 afe08e9c S/system/bin/debugadh

Root 449 1 12576 580 ffffffff afe08b9c S/system/bin/rild

Root 450 1 56576 14776 c01dc388 afe083dc s zygote

Root 451 1 18528 2064 ffffffff afe0861c S/system/bin/Runtime

Bluetooth 452 1 1200 756 c0082240 afe0947c S/system/bin/container-daemon

Root 461 450 107792 19320 ffffffff afe0861c s system_server

App_4 502 450 74292 14436 ffffffff afe09604 s com. Google. Android. Home

Phone 503 450 74832 15044 ffffffff afe09604 s com. Google. Android. Phone

App_0 531 450 74620 14400 ffffffff afe09604 s com. Google. process. Content

App_5 608 450 73780 11760 ffffffff afe09604 s LK. Test

App_7 662 450 82012 13124 ffffffff afe09604 s com. Google. Android. lunarlander

App_0 809 450 74204 15780 ffffffff afe09604 s com. Google. Android. Maps

App_6 828 450 76844 14600 ffffffff afe09604 s com. Google. Android. Samples

System 873 450 76464 13028 ffffffff afe09604 s com. Google. Android. Development

Root 971 446 720 292 c0020.a4 afe092ac S/system/bin/sh

Root 2736 971 928 308 00000000 afe083dc R PS

Similarly, there are various threads, the programs called by the system, and the user's own program processes, such as LK. test and COM. google. android. lunarlander is running in the project, Com. google. android. maps, Com. google. android. phone is the program you see when the android simulator is running. Interestingly, from the perspective of/system/bin/usbd in the process, it seems that all client debugging is via USB. Of course it is not pull now. Now you are just using a simulator. Well, will the USB debugger be expensive when the supporting hardware comes out in the future? Hey.

Finally, let's take a look at the file system and mount it:

Rootfs/rootfs RW 0 0

/Dev/pts/dev/PTS devpts RW 0 0

/Proc RW 0 0

/Sys sysfs RW 0 0

/Dev/block/mtdblock0/system yaffs2 RW, nodev, noatime, nodiratime 0 0

/Dev/block/mtdblock1/Data yaffs2 RW, nodev, noatime, nodiratime 0 0

There is nothing new. Compared with the desktop, there is no virtual memory file system, and the root file system is the/tools/lib/images/ramdisk In the SDK installation directory of the simulator. IMG loaded. The system uses the yaffs2 file system. Both system and data are 64 MB large, and nearly half of them are used. The specific system image is the tools/lib/image/system. IMG In the SDK installation directory.

From the above analysis, this Linux is still quite normal. Another interesting topic is that the current installation of software, or the package method, has been condemned by many people in the developer group, google currently does not have a standard install program for Android programs, nor does it have a repository description. Some small programs can be roughly installed by analyzing the android file changes, but if there are any large projects in the future, it is better to set a standard installation method rule. You cannot rely on Eclipse to help us, huh, huh.

The following steps can be used to analyze the current installation mode.

Before installing the software:

1. emulator-wipe-Data

2. ADB push busybox ./

3. ADB shell./busybox tar-CF/tmp/data.tar/Data

4. ADB pull/tmp/data.tar.

5. mkdir original

6. CD original

7. Tar-XF ../data.tar

After installing the software:

1. ADB shell./busybox tar-CF/tmp/data.tar/Data

2. ADB pull/tmp/data.tar.

3. mkdir after_install

4. CD after_install

5. Tar-XF ../data.tar

The specific difference is that two related files are added under/data/APP and data/data, and the files are stored in/data/system/packages. the installed program information is added to XML. It seems that the menu also shows whether the new installer is obtained from this file and how to display relevant information, such as the name or something.