rildandroid

Ⅰ android.rild.kernel.logs文件可以删吗

一些日志文件，是可以删掉的，大部分都是用来记录一些行为或者缓存的数据。

Ⅱ HAL 硬件抽象层

绑定式 HAL 。以 HAL 接口定义语言 (HIDL) 或 Android 接口定义语言 (AIDL) 表示的 HAL。这些 HAL 取代了早期 Android 版本中使用的传统 HAL 和旧版 HAL。在绑定式 HAL 中，Android 框架和 HAL 之间通过 Binder 进程间通信 (IPC) 调用进行通信。所有在推出时即搭载了 Android 8.0 或后续版本的设备都必须只支持绑定式 HAL。

直通式 HAL 。以 HIDL 封装的传统 HAL 或 旧版 HAL 。这些 HAL 封装了现有的 HAL，可在绑定模式和 Same-Process（直通）模式下使用。升级到 Android 8.0 的设备可以使用直通式 HAL。

Android 要求所有 Android 设备（无论是搭载 Android O 的设备还是升级到 Android O 的设备）上的下列 HAL 均为绑定式：

[email protected]。取代 Android 8.0 中已不存在的 fingerprintd。

[email protected]。Android 8.0 中的新 HAL。

[email protected]。此 HAL 提供的原始接口可能无法继续使用，并且已更改。因此，mpstate_board 必须在指定的设备上重新实现（这是一个可选的 HAL）。

[email protected]。在 Android 8.0 中，此 HAL 必须为绑定式，因此无需在可信进程和不可信进程之间分享文件描述符。

[email protected]。取代由存活于自身进程中的 rild 提供的接口。

[email protected]。Android 8.0 中的新 HAL。

[email protected]。Android 8.0 中的新 HAL，可取代此前加载到 system_server 中的旧版 WLAN HAL 库。

[email protected]。在现有 wpa_supplicant 进程之上的 HIDL 接口。

注意 ：Android 提供的以下 HIDL 接口将一律在绑定模式下使用：android.frameworks.*、android.system.* 和 android.hidl.*（不包括下文所述的 [email protected]）。

Android 要求所有 Android 设备（无论是搭载 Android O 的设备还是升级到 Android O 的设备）上的下列 HAL 均在直通模式下使用：

[email protected]。将内存映射到其所属的进程中。

[email protected]。在同一进程中传递项（等同于 openGL）。

上方未列出的所有 HAL 在搭载 Android O 的设备上都必须为绑定式。

Ⅲ ril位于android哪一层

上图清楚的标识了ril在整个Android系统各层的表现形式，我们这里主要分析Ril（RIDL、librefrenece_ril.so、libril.so）;
…/Hardware/ril/rild RILD的代码实现，有main函数，作为ril层的入口点，常驻系统进程，负责与上下层交互
…/Hardware/ril/libril 负责与守护进程交互？？？
…/Hardware/ril/reference-ril/ Ril库的实现，主要负责与modem进行交互

实现详细分析：

从init.rc中service ril-daemon /system/bin/rild -l /system/lib/libreference-ril.so -- -d /dev/ttyUSB1 -u /dev/ttyUSB2
可以知道，Android启动时，系统会启动一个与ril相关的service （ril-daemon），其入口命令为/system/bin/rild

（一）那么首先看看rild（/hardware/ril/rild/*）；该目录下有两文件radiooptions.c、rild.c
Radiooptions.c 看Makefile知道最终会被编译成radiooptions二进制工具，放在/system/bin/下面，具体用法我在这里就不说了，我到终点里面执行一下，把他的help信息打出了，再详细的就自己看吧，源码不长，也不复杂。
# radiooptions

Ⅳ 如何查找唤醒android系统

如果在休眠中系统被中断或者其他事件唤醒,接下来的代码就会开始执行,这个唤醒的顺序是和休眠的循序相反的,所以系统设备和总线会首先唤醒，使能系统中断,使能休眠时候停止掉的非启动CPU,以及调用suspend_ops->finish(),而且在suspend_devices_and_enter()函数中也会继续唤醒每个设备,使能虚拟终端,最后调用suspend_ops->end().

在返回到enter_state()函数中的,当suspend_devices_and_enter()返回以后,外设已经唤醒了,但是进程和任务都还是冻结状态,这里会调用suspend_finish()来解冻这些进程和任务,而且发出Notify来表示系统已经从suspend状态退出,唤醒终端.

到这里,所有的休眠和唤醒就已经完毕了,系统继续运行了.

Android系统Suspend和resume的函数流程
Android 休眠(suspend)介绍
在一个打过android补丁的内核中,state_store()函数会走另外一条路,会进入到request_suspend_state()中,这个文件在earlysuspend.c中.这些功能都是android系统加的,后面会对earlysuspend和lateresume进行介绍。

涉及到的文件:

linux_source/kernel/power/main.c

linux_source/kernel/power/earlysuspend.c

linux_source/kernel/power/wakelock.c

特性介绍

1）EarlySuspend

Early suspend是android引进的一种机制,这个机制作用在关闭显示的时候,一些和显示有关的设备,比如LCD背光,重力感应器,触摸屏,这些设备都会关掉，但是系统可能还是在运行状态(这时候还有wakelock)进行任务的处理，例如在扫描SD卡上的文件等.在嵌入式设备中,背光是一个很大的电源消耗，所以android会加入这样一种机制。

2）LateResume

Late Resume是和suspend配套的一种机制,是在内核唤醒完毕开始执行的，主要就是唤醒在EarlySuspend的时候休眠的设备.

当所有的唤醒已经结束以后,用户进程都已经开始运行了,唤醒通常会是以下的几种原因:

来电

如果是来电,那么Modem会通过发送命令给rild来让rild通知WindowManager有来电响应,这样就会远程调用PowerManagerService来写"on"到/sys/power/state来执行lateresume的设备,比如点亮屏幕等.

用户按键用户按键事件会送到WindowManager中,WindowManager会处理这些按键事件,按键分为几种情况,如果案件不是唤醒键(能够唤醒系统的按键)那么WindowManager会主动放弃wakeLock来使系统进入再次休眠,如果按键是唤醒键,那么WindowManger就会调用PowerManagerService中的接口来执行Late Resume.

Late Resume会依次唤醒前面调用了EarlySuspend的设备.

3）WakeLock

Wake Lock在Android的电源管理系统中扮演一个核心的角色.Wake Lock是一种锁的机制,只要有人拿着这个锁，系统就无法进入休眠,可以被用户态程序和内核获得。这个锁可以是有超时的或者是没有超时的,超时的锁会在时间过去以后自动解锁。如果没有锁了或者超时了,内核就会启动休眠的那套机制来进入休眠。

3）AndroidSuspend

当用户写入mem或者standby到/sys/power/state中的时候,state_store()会被调用,然后Android会在这里调用request_suspend_state()而标准的Linux会在这里进入enter_state()这个函数.如果请求的是休眠,那么early_suspend这个workqueue就会被调用,并且进入early_suspend状态。调用request_suspend_state()后在suspend_work_queue工作线程上面注册一个early_suspend_work工作者，

然后又通过staticDECLARE_WORK(early_suspend_work, early_suspend);注册一个工作任务early_suspend。所以系统最终会调用early_suspend函数。

注册加入suspend和resume流程
platform_device_register()-->platform_device_add()-->device_add()-->device_pm_add()-->，最终加入到了dpm_list的链表中，在其中的dpm_suspend和dpm_suspend中通过遍历这个链表来进行查看哪个device中包含suspend和resume项。

系统唤醒和休眠

Kernel层[针对AndroidLinux2.6.28内核]:

其主要代码在下列位置:

Drivers/base /main.c

kernel/power /main.c

kernel/power/wakelock.c

kernel/power/earlysuspend.c

其对Kernel提供的接口函数有

EXPORT_SYMBOL(wake_lock_init);//初始化Suspendlock,在使用前必须做初始化

EXPORT_SYMBOL(wake_lock);//申请lock,必须调用相应的unlock来释放它

static DEFINE_TIMER(expire_timer,expire_wake_locks, 0, 0);//定时时间到，加入到suspend队列中；

EXPORT_SYMBOL(wake_unlock);//释放lock

EXPORT_SYMBOL_GPL(device_power_up);//打开特殊的设备

EXPORT_SYMBOL_GPL(device_power_down);//关闭特殊设备

EXPORT_SYMBOL_GPL(device_resume);//重新存储设备的状态；

EXPORT_SYMBOL_GPL(device_suspend);:保存系统状态，并结束掉系统中的设备；

EXPORT_SYMBOL(register_early_suspend);//注册earlysuspend的驱动

EXPORT_SYMBOL(unregister_early_suspend);//取消已经注册的earlysuspend的驱动

Android的suspent执行流程
函数的流程如下所示：

应用程序通过对/sys/power/state的写入操作可以使系统进行休眠的状态，会调用/kernel/power/main.c中的state_store函数。pm_states包括：

PM_SUSPEND_ON，PM_SUSPEND_STANDBY，PM_SUSPEND_MEM满足的状态。

1）当状态位PM_SUSPEND_ON的状态的时候，request_suspend_state()；当满足休眠的状态的时候，调用request_suspend_state在suspend_work_queue工作线程上创建early_suspend_work队列，queue_work(suspend_work_queue,&early_suspend_work)。

2）然后通过DECLARE_WORK(early_suspend_work,early_suspend);在early_suspend_work工作队列中添加工作任务调用early_suspend，所以early_suspend函数会被调用。

3）early_suspend函数中通过

list_for_each_entry(pos,&early_suspend_handlers, link) {

if (pos->suspend != NULL)

pos->suspend(pos)；

在链表中找注册的suspend函数，这个suspend是early的。early_suspend后面调用wake_unlock函数。语句：wake_unlock(&main_wake_lock);

4）wake_unlock()中调用mod_timer启动expire_timer定时器，当定时时间到了，则执行expire_wake_locks函数，将suspend_work加入到suspend_work_queue队列中，分析到这里就可以知道了early_suspend_work和suspend_work这两个队列的先后顺序了（先执行early，定义一段时间后才执行suspend_work），然后会在suspend_work队列中加入suspend的工作任务，所以wakelock.c中的suspend函数会被调用。

5）suspend调用了pm_suspend，通过判断当前的状态，选择enter_state()，在enter_state中，经过了suspend_prepare，suspend_test和suspend_device_and_enter()，在suspend_device_and_enter中调用dpm_suspend_start()，然后调用dpm_suspend()。

6）dpm_suspend中利用while循环在dpm_list链表查找所有devic，然后调用device_suspend来保存状态和结束系统的设备。到了这里，我们就又可以看见在初始化的时候所看到的队列dpm_list。

dpm_list链表的添加是在device_pm_add中完成，请看上一节中。

Wake Lock
我们接下来看一看wakelock的机制是怎么运行和起作用的,主要关注wakelock.c文件就可以了。

wake lock有加锁和解锁两种状态,加锁的方式有两种,一种是永久的锁住,这样的锁除非显示的放开,是不会解锁的,所以这种锁的使用是非常小心的.第二种是超时锁,这种锁会锁定系统唤醒一段时间,如果这个时间过去了,这个锁会自动解除.

锁有两种类型:

WAKE_LOCK_SUSPEND这种锁会防止系统进入睡眠

WAKE_LOCK_IDLE这种锁不会影响系统的休眠,作用我不是很清楚.

在wakelock中,会有3个地方让系统直接开始suspend(),分别是:

1）在wake_unlock()中,如果发现解锁以后没有任何其他的wakelock了,就开始休眠

2）在定时器都到时间以后,定时器的回调函数会查看是否有其他的wakelock,如果没有,就在这里让系统进入睡眠.

3）在wake_lock()中,对一个wakelock加锁以后,会再次检查一下有没有锁,我想这里的检查是没有必要的,更好的方法是使加锁的这个操作原子化,而 不是繁冗的检查.而且这样的检查也有可能漏掉.

Android于标准Linux休眠的区别

pm_suspend()虽然会调用enter_state()来进入标准的Linux休眠流程，但是还是有一些区别:

当进入冻结进程的时候，android首先会检查有没有wakelock，如果没有,才会停止这些进程，因为在开始suspend和冻结进程期间有可能有人申请了wake lock,如果是这样,冻结进程会被中断.

在suspend_late()中,会最后检查一次有没有wakelock,这有可能是某种快速申请wakelock,并且快速释放这个锁的进程导致的,如果有这种情况,这里会返回错误,整个suspend就会全部放弃.如果pm_suspend()成功了,LOG的输出可以通过在kernelcmd里面增加"no_console_suspend"来看到suspend和resume过程中的log输出。

Android的电源管理主要是通过Wakelock来实现的，在最底层主要是通过如下队列来实现其管理：

LIST_HEAD(dpm_list);

系统正常开机后进入到AWAKE状态,，Backlight会从最亮慢慢调节到用户设定的亮度,系统screenoff timer(settings->sound & display-> Display settings ->Screen timeout)开始计时，在计时时间到之前，如果有任何的activity事件发生,如Touchclick, keyboard pressed等事件,则将Resetscreen off timer, 系统保持在AWAKE状态.如果有应用程序在这段时间内申请了Fullwake lock,那么系统也将保持在AWAKE状态,除非用户按下powerkey.在AWAKE状态下如果电池电量低或者是用AC供电screenoff timer时间到并且选中Keepscreen on while pluged in选项,backlight会被强制调节到DIM的状态。

如果Screenoff timer时间到并且没有Fullwake lock或者用户按了powerkey,那么系统状态将被切换到NOTIFICATION,并且调用所有已经注册的early_suspend_handlers函数,通常会把LCD和Backlight驱动注册成earlysuspend类型,如有需要也可以把别的驱动注册成earlysuspend,这样就会在第一阶段被关闭.接下来系统会判断是否有partialwake lock acquired, 如果有则等待其释放,在等待的过程中如果有useractivity事件发生,系统则马上回到AWAKE状态;如果没有partialwake lock acquired, 则系统会马上调用函数pm_suspend关闭其它相关的驱动,让CPU进入休眠状态。

系统在Sleep状态时如果检测到任何一个Wakeupsource,则CPU会从Sleep状态被唤醒,并且调用相关的驱动的resume函数,接下来马上调用前期注册的earlysuspend驱动的resume函数,最后系统状态回到AWAKE状态.这里有个问题就是所有注册过earlysuspend的函数在进Suspend的第一阶段被调用可以理解,但是在resume的时候,Linux会先调用所有驱动的resume函数,而此时再调用前期注册的earlysuspend驱动的resume函数有什么意义呢?个人觉得android的这个earlysuspend和lateresume函数应该结合Linux下面的suspend和resume一起使用,而不是单独的使用一个队列来进行管理。

Ⅳ android系统shell脚本中传带空格参数

问题：需要通过shell脚本，执行“setprop rild.libargs -d /dev/ttyUSB2”命令，即：设置rild.libargs=-d /dev/ttyUSB2。
写法：

LTE_ARGS="rild.libargs"
DATA_PATH="-d /dev/ttyUSB2"
DATA_PATH2="-d /dev/ttyUSB3"
setprop " DATA_PATH"

说明：上面将$DATA_PATH加了双引号，即把“-d /dev/ttyUSB2”当做一个整体，如果不加的话会提示：“setprop: Max 2 arguments”。

Ⅵ Android 怎样在应用程序中通过串口（比如ttyS0)来发送和接收数据

可以参考rild的实现

Ⅶ Android系统下的build.prop文件

Android系统下的build.prop文件，用adb shell进入，再进入到system目录，查看该目录下的文件，会看到build.prop文件，用exit命令退出。

C:\Users\Administrator\Desktop>adb root
adbd is already running as root

C:\Users\Administrator\Desktop>adb remount
remount succeeded
//把文件拉到桌面
C:\Users\Administrator\Desktop>adb pull /system/build.prop
436 KB/s (4474 bytes in 0.010s)
//修改之后，推送回/system/，例如修改了ro.sf.hwrotation=180,使屏幕旋转180°
C:\Users\Administrator\Desktop>adb push C:\Users\Administrator\Desktop\build
p /system/
19 KB/s (4459 bytes in 0.227s)

C:\Users\Administrator\Desktop>adb shell

root@T508AC:/ # cd system/
root@T508AC:/system # ls
app
bin
build.prop
etc
fonts
framework
lib
lost+found
manifest.xml
media
priv-app
tts
usr
vendor
xbin
//执行这个命令才可以生效
root@T508AC:/system # chmod 644 build.prop
//重启设备就可以看到屏幕旋转180读已经生效了
root@T508AC:/system # reboot

build.prop的文件内容：

ro.build.id=LMY49F
ro.build.display.id=rk3288-eng 5.1.1 LMY49F eng.zhangfeng.20190306.051048 test-keys
ro.build.version.incremental=eng.zhangfeng.20190306.051048
ro.build.version.sdk=22
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=5.1.1
ro.build.version.security_patch=2016-03-01
ro.build.version.base_os=
ro.build.date=Wed Mar 6 05:16:23 EST 2019
ro.build.date.utc=1551867383
ro.build.type=eng
ro.build.user=zhangfeng
ro.build.host=build
ro.build.tags=test-keys
ro.build.flavor=rk3288-eng
ro.proct.model=T508AC
ro.proct.brand=Android
ro.proct.name=T508AC
ro.proct.device=T508AC
ro.proct.board=rk30sdk
ro.jiebao.version=T508AC_OS_E0A_V0.0.29_LYNQ

ro.proct.cpu.abi=armeabi-v7a
ro.proct.cpu.abi2=armeabi
ro.proct.cpu.abilist=armeabi-v7a,armeabi
ro.proct.cpu.abilist32=armeabi-v7a,armeabi
ro.proct.cpu.abilist64=
ro.proct.manufacturer=rockchip
ro.proct.locale.language=zh
ro.proct.locale.region=CN
ro.wifi.channels=
ro.board.platform=rk3288

ro.build.proct=rk3288

ro.build.description=rk3288-eng 5.1.1 LMY49F eng.zhangfeng.20190306.051048 test-keys
ro.build.fingerprint=Android/rk3288/rk3288:5.1.1/LMY49F/zhangfeng03060514:eng/test-keys
ro.build.characteristics=tablet

ro.ril.ecclist=112,911
ro.opengles.version=196609
wifi.interface=wlan0
rild.libpath=/system/lib/libril-rk29-dataonly.so
rild.libpath.jb=/system/lib/libreference-ril-jb.so
rild.libpath.LYNQ=/system/lib/libreference-ril-LYNQ.so
rild.libpath.HW=/system/lib/libreference-ril-HW.so
rild.libpath.LS=/system/lib/libreference-ril-LS.so
rild.libargs=-d /dev/ttyUSB2
persist.tegra.nvmmlite = 1
ro.audio.monitorOrientation=true

persist.sys.strictmode.visual=0
persist.sys.strictmode.disable=1

debug.nfc.fw_download=false
debug.nfc.se=false

ro.rk.screenoff_time=60000
ro.rk.screenshot_enable=true
ro.rk.def_brightness=200
ro.rk.homepage_base= http://www.google.com/webhp?client= {CID}&source=android-home
ro.rk.install_non_market_apps=false
sys.hwc.compose_policy=6
sys.wallpaper.rgb565=0
sf.power.control=2073600
sys.rkadb.root=0
ro.sf.fakerotation=false
ro.sf.hwrotation=180
ro.rk.MassStorage=false
ro.rk.systembar.voiceicon=true
ro.rk.systembar.tabletUI=false
ro.rk.LowBatteryBrightness=false
ro.tether.denied=false
sys.resolution.changed=false
ro.default.size=100
persist.sys.timezone=
ro.proct.usbfactory=rockchip_usb
wifi.supplicant_scan_interval=15
ro.factory.tool=0
ro.kernel.android.checkjni=0

ro.sf.lcd_density=160
ro.adb.secure=0

ro.com.android.dateformat=MM-dd-yyyy
ro.config.ringtone=Ring_Synth_04.ogg
ro.config.notification_sound=pixiest.ogg
ro.carrier=unknown
ro.config.alarm_alert=Alarm_Classic.ogg
ro.target.proct=tablet
ro.factory.hasGPS=true
dalvik.vm.heapstartsize=16m
dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m
net.dns1=8.8.8.8
net.dns2=8.8.4.4
camera2.portability.force_api=1
persist.sys.strictmode.visual=false
dalvik.vm.jniopts=warnonly
ro.rk.bt_enable=true
ro.factory.hasUMS=true
persist.sys.usb.config=mass_storage
testing.mediascanner.skiplist=/mnt/internal_sd/Android/
ro.factory.storage_suppntfs=true
ro.factory.without_battery=false
keyguard.no_require_sim=true
ro.com.android.dataroaming=true
ril.function.dataonly=1
ro.config.enable.remotecontrol=false
ro.proct.version=1.0.0
ro.proct.ota.host= www.rockchip.com:2300
persist.sys.dalvik.vm.lib.2=libart.so
dalvik.vm.isa.arm.features=div
ro.kernel.android.checkjni=1
dalvik.vm.image-dex2oat-filter=verify-none
dalvik.vm.dex2oat-filter=interpret-only
dalvik.vm.dexopt-flags=m=y
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt

ro.fota.platform=RK3288_5.1
ro.fota.type=pad_phone
ro.fota.app=5
ro.fota.oem=jiebao-RK3288_5.1
ro.fota.device=T508AC
ro.fota.version=T508AC_OS_E0A_V0.0.29_LYNQ_20190306-0516

Ⅷ android rild占满CPU

CPU和内存小。在PC上运行android虚拟机AVD，打开任务管理器我们会发现AVD进程对CPU和内存的占用非常高，所以CPU和内存较小的电脑就会出现androidrild占满CPU的情况，所以androidrild占满CPU是因为CPU和内存小。

Ⅸ 当我们按下电源键，Android 究竟做了些什么

一、启动电源及系统启动

系统从 ROM 中开始启动，加载引导程序到 RAM ，然后执行。

二、引导程序

引导程序是 Android 操作系统开始运行前的一个小程序，因此它需要针对特定主板与芯片，并不是 Android 操作系统的一部分。引导程序是OEM厂商或运行商进行加锁、限制的地方。

1、两个阶段 检测外部 RAM 以及为第二阶段加载程序； 设置网络、内存等，搭建内核运行环境（为了达到特殊目的时，引导程序可以根据配置参数或者输入数据来设置内核）。 2、引导程序的加载器

Android引导程序可以在ootableootloaderlegacyusbloader找到，传统的加载器包含的两个文件：

init.s 初始化堆栈，清零BSS段，会调用 main.c 中的 _main()函数 （bss segment：通常是指用来存放程序中未初始化的全局变量的一块内存区域；BSS - Block Started by Symbol。BSS段属于静态内存分配）； main.c 初始化硬件，创建 linux 标签。 三、内核启动

Android 内核启动方式类似桌面 linux，主要步骤：

1. 设置缓存 2. 被保护存储器 3. 计划列表 4. 加载驱动

当内核完成系统设置，接下来即将启动系统的第一个进程 —init 进程

四、init 进程

作为 Android 系统的第一个进程，其PID为0，通过解析 init.rc 脚本来构建出系统初始运行形态，这一阶段中，“Android” logo 会显示出来。

备注：系统中，大多数系统服务程序都是在该脚本中描述并被相继启动的。

init.rc 由4种类型声明组成：Actions、Commands、Services、Options

Actions： 响应某事件的过程。当“trigger”所描述的触发事件产生时，则依次执行各种“command”； 源码角度来看，系统会对 init.rc 中各“trigger”进行匹配，当发现符合条件的 Action，就将它加入“命令执行队列”尾部（除非 Action 已存在队列中），然后系统再对这些命令按顺序进行。 on <trigger> ##触发条件 <command1> ##执行命令 <command2> ##可执行多个命令 ... Commands： 命令将在所属事件发生时被一个个执行。 Services： 可执行程序，它们在特定选项的约束下会被 init 程序运行或者重启 备注：Service 可以在配置中指定是否需要退出重启，那么，当 Service 出现异常 crash 时，可有机会复原。 service <name><pathname> [<argument>]* <option> <option> Options: 对 service 的约束选项 五 &六、 ServiceManager、Zygote、SystemServer

科普： Daemons - 守护进程

init进程通过解析 init.rc 来陆续启动其他关键的系统服务进程，其中最重要的是 ServiceManager、Zygote 和 SystemServer 三者，下面我们逐一解析：

1、ServiceManager — Binder 机制支撑者

概述：ServiceManager 是 Binder 机制中的支撑者，负责某 Binder 服务注册信息到底层 Binder 驱动分配的值解析。

ServiceManager 由 init 进程解析 rc 脚本时启动，属于 core 类，其他同类进程包括：uenetd、console、adbd等。根据 core 组的特性，这些进程会同时启动或停止。另外，ServiceManager 配置含有 critical 属性，这意味着它是系统关键进程（如果进程不幸在4分钟内异常退出超过4次，设备将重启并进入还原模式）。当 ServiceManager 每次重启时，其他关键进程：zygote、media、surfaceflinger 等也会被 restart。

2、Zygote — “孕育”新线程与进程

Android 中大多数应用进程与系统进程都是通过 Zygote 来生成的。Zygote 同样由 init 解析 rc 脚本时启动，属于 main 类，同属 main 类的系统进程有：netd、debuggerd、rild等。Zygote并不是处于独立的程序中的，它所在程序名为“app_process”，观察 app_process 主函数实现知道，如果 init.rc 中指定了 —zygote选项，app_process 接下来将启动“ZygoteInit”，并传入“start-system-server”,这样，ZygoteInit 就会运行在虚拟机上（Dalvik VM）上了。

ZygoteInit 函数有两项重要工作：

预装载各种系统类； 搭建 SystemServer 环境，并启动 SystemServer（大部分的 Android 系统服务都在其中，由 Java 编写）。

ZygoteInit 流程总结（摘自：Gityuan — Android 系统启动-Zygote 篇）：

解析init.zygote.rc中的参数，创建AppRuntime并调用AppRuntime.start()方法； 调用AndroidRuntime的startVM()方法创建虚拟机，再调用startReg()注册JNI函数； 通过JNI方式调用ZygoteInit.main()，第一次进入Java世界； registerZygoteSocket()建立socket通道，zygote作为通信的服务端，用于响应客户端请求； preload()预加载通用类、drawable和color资源、openGL以及共享库以及WebView，用于提高ap启动效率； zygote完毕大部分工作，接下来再通过startSystemServer()，fork得力帮手system_server进程，也是上层framework的运行载体； zygote功成身退，调用runSelectLoop()，随时待命，当接收到请求创建新进程请求时立即唤醒并执行相应工作。

ZygoteInit 结束后，开机Logo就出来了。 注意：这里并不包括开机动画，而是开机前 “Android” Logo 出现的那个画面，开机动画出现之前还需要进行各种加载，开机动画是在“Android” Logo 出现之后才播放的。

3、SystemServer — 大部分 Android 系统服务所在地

SystemServer 是 Android 进入 Launcher 前的最后准备，它提供了众多的由“Java”语言编写的系统服务。 如果 init.rc 中为 zygote 指定启动参数 —start-system-server，那么 ZygotyeInit 就会调用 startSystemServer 来进入 SystemServer。

startSystemServer函数解析：

首先 ZygoteInit 通过 Zygote.forkSystemServer 来生成一个新的线程（fork），用于承载各种系统服务。（源码角度：Zygote 内部由 Native 函数 Dalvik_dalvik_system_Zygote_forkSystemServer 来进一步实现，最终调用底层接口的 fork 接口来实际产生进程）； 根据fork特性，子进程与父进程将获得相同的代码环境。pid为0为子进程，否则为父进程；如果是前者，则进一步调用 handleSystemServerProcess(parseArgs)函数来完成最核心的工作 —“启动各系统服务”（源码角度：handleSystemServerProcess 方法将 startSystemServer 中的 parsedArgs.remainingArgs 参数传给 RuntimeInit.zygoteInit，后者又调用 nativeZygoteInit 函数）； nativeZygoteInit 调用后，接着，三个重要的 static 函数就要被执行了：init1 - 完成本地Service(SurfaceFlinger、AudioFlinger等)启动，完成后调用 init2、init2 - 新建一个新的带 Looper 的线程 ServerThread来启动 Java层各 Service。

Ⅹ android怎么用代码实现kill命令

由于adb shell中的kill命令后面跟的参数是pid，因此先ps所有的应用程序：
adb在shell下：
ps
USER PID PPID VSIZE RSS WCHAN PC NAME
root 1 0 296 204 c008de04 0000c74c S /init
root 2 0 0 0 c004b334 00000000 S kthreadd
root 3 2 0 0 c003cf68 00000000 S ksoftirqd/0
root 4 2 0 0 c00486b8 00000000 S events/0
root 5 2 0 0 c00486b8 00000000 S khelper
root 10 2 0 0 c00486b8 00000000 S suspend
root 42 2 0 0 c00486b8 00000000 S kblockd/0
root 45 2 0 0 c00486b8 00000000 S cqueue
root 47 2 0 0 c016f13c 00000000 S kseriod
root 51 2 0 0 c00486b8 00000000 S kmmcd
root 96 2 0 0 c0065c7c 00000000 S pdflush
root 97 2 0 0 c0065c7c 00000000 S pdflush
root 98 2 0 0 c006990c 00000000 S kswapd0
root 100 2 0 0 c00486b8 00000000 S aio/0
root 268 2 0 0 c016c884 00000000 S mtdblockd
root 302 2 0 0 c0181200 00000000 S mmcqd
root 309 2 0 0 c00486b8 00000000 S rpciod/0
root 548 1 740 312 c0141bb0 afe0c1bc S /system/bin/sh
system 549 1 808 264 c01654b4 afe0c45c S /system/bin/servicemanager
root 550 1 848 392 c008e3f4 afe0c584 S /system/bin/vold
root 551 1 668 264 c0192c20 afe0cdec S /system/bin/debuggerd
radio 552 1 5392 684 ffffffff afe0cacc S /system/bin/rild
root 553 1 72432 20840 c008e3f4 afe0c584 S zygote
media 554 1 17720 3496 ffffffff afe0c45c S /system/bin/mediaserver
root 556 1 800 300 c01f3b04 afe0c1bc S /system/bin/installd
root 560 1 840 356 c00ae7b0 afe0d1dc S /system/bin/qemud
root 563 1 3332 152 ffffffff 0000e8c4 S /sbin/adbd
system 577 553 186652 24600 ffffffff afe0c45c S system_server
radio 617 553 106860 17432 ffffffff afe0d3e4 S com.android.phone
app_3 619 553 108804 19168 ffffffff afe0d3e4 S android.process.acore
app_15 643 553 95536 13220 ffffffff afe0d3e4 S com.android.mms
app_0 660 553 94292 12604 ffffffff afe0d3e4 S com.android.alarmclock
app_4 671 553 96440 13636 ffffffff afe0d3e4 S android.process.media
app_5 681 553 96556 13124 ffffffff afe0d3e4 S com.android.email
root 709 563 740 328 c003aa1c afe0d08c S /system/bin/sh
app_3 713 553 96328 12920 ffffffff afe0d3e4 S com.android.inputmethod.lat
in
app_9 720 553 94476 14524 ffffffff afe0d3e4 S com.android.music
root 726 709 884 336 00000000 afe0c1bc R ps
#

例如要关掉music

# kill 720
kill 720
# ps
ps
USER PID PPID VSIZE RSS WCHAN PC NAME
root 1 0 296 204 c008de04 0000c74c S /init
root 2 0 0 0 c004b334 00000000 S kthreadd
root 3 2 0 0 c003cf68 00000000 S ksoftirqd/0
root 4 2 0 0 c00486b8 00000000 S events/0
root 5 2 0 0 c00486b8 00000000 S khelper
root 10 2 0 0 c00486b8 00000000 S suspend
root 42 2 0 0 c00486b8 00000000 S kblockd/0
root 45 2 0 0 c00486b8 00000000 S cqueue
root 47 2 0 0 c016f13c 00000000 S kseriod
root 51 2 0 0 c00486b8 00000000 S kmmcd
root 96 2 0 0 c0065c7c 00000000 S pdflush
root 97 2 0 0 c0065c7c 00000000 S pdflush
root 98 2 0 0 c006990c 00000000 S kswapd0
root 100 2 0 0 c00486b8 00000000 S aio/0
root 268 2 0 0 c016c884 00000000 S mtdblockd
root 302 2 0 0 c0181200 00000000 S mmcqd
root 309 2 0 0 c00486b8 00000000 S rpciod/0
root 548 1 740 312 c0141bb0 afe0c1bc S /system/bin/sh
system 549 1 808 264 c01654b4 afe0c45c S /system/bin/servicemanager
root 550 1 848 392 c008e3f4 afe0c584 S /system/bin/vold
root 551 1 668 264 c0192c20 afe0cdec S /system/bin/debuggerd
radio 552 1 5392 684 ffffffff afe0cacc S /system/bin/rild
root 553 1 72432 20840 c008e3f4 afe0c584 S zygote
media 554 1 17720 3496 ffffffff afe0c45c S /system/bin/mediaserver
root 556 1 800 300 c01f3b04 afe0c1bc S /system/bin/installd
root 560 1 840 356 c00ae7b0 afe0d1dc S /system/bin/qemud
root 563 1 3332 152 ffffffff 0000e8c4 S /sbin/adbd
system 577 553 186648 24656 ffffffff afe0c45c S system_server
radio 617 553 106860 17528 ffffffff afe0d3e4 S com.android.phone
app_3 619 553 108804 19168 ffffffff afe0d3e4 S android.process.acore
app_15 643 553 95536 13220 ffffffff afe0d3e4 S com.android.mms
app_0 660 553 94292 12604 ffffffff afe0d3e4 S com.android.alarmclock
app_4 671 553 96440 13636 ffffffff afe0d3e4 S android.process.media
app_5 681 553 96556 13124 ffffffff afe0d3e4 S com.android.email
root 709 563 740 328 c003aa1c afe0d08c S /system/bin/sh
app_3 713 553 96328 12920 ffffffff afe0d3e4 S com.android.inputmethod.la
in
root 728 709 884 336 00000000 afe0c1bc R ps
#