第三章 Android 启动过程的底层实现

转载请标明出处:

http://blog.csdn.net/yujun411522/article/details/46367787

本文出自:【yujun411522的博客】

3.1 android正常模式启动流程

主要流程如下:

1.系统加电,执行bootloader,bootloader会将内核加载到内存中。

2.内核加载到内存之后首先进入内核引导阶段,最后调用start_kernel进入内核启动,start_kernel最终会启动init程序

3.init程序负责解析init.rc文件并开启守护进程,最重要的两个守护进程就是zygoteServiceManager

4.zygote启动子进程system_server,在system_server中开启android核心服务并添加到SystemManager之中,系统进入systemReady状态。

5.在systemReady状态下AMS和zygote的socket通信,启动Home应用进入系统桌面。

这里只介绍步骤2和步骤3。

直接看init程序是如何启动的

3.2 init进程执行过程

init是linux用户空间的第一个进程,它的进程号是1,工作主要有以下几个部分:

1.初始化文件系统和日志系统,主要是linux标准函数调用

2.解析init.rc和init<hardware>.rc初始化文件,其中init.rc文件的解析非常重要

3.解析上面的文件之后执行Action和Service

4.循环监听处理事件

init进程对应的代码是在system\core\init\Init.c,看它的入口函数main:

int main(int argc, char **argv)
{
    int fd_count = 0;
    struct pollfd ufds[4];
    char *tmpdev;
    char* debuggable;
    char tmp[32];
    int property_set_fd_init = 0;
    int signal_fd_init = 0;
    int keychord_fd_init = 0;
    //如果传入的argv[0]参数是ueventd,执行ueventd_main函数
    if (!strcmp(basename(argv[0]), "ueventd"))
        return ueventd_main(argc, argv);

    /* clear the umask */
    //如果是文件,文件权限为666,目录权限是777
    umask(0);

        /* Get the basic filesystem setup we need put
         * together in the initramdisk on / and then we'll
         * let the rc file figure out the rest.
         */
   //创建目录并挂载
    mkdir("/dev", 0755);
    mkdir("/proc", 0755);
    mkdir("/sys", 0755);

    mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755");
    mkdir("/dev/pts", 0755);
    mkdir("/dev/socket", 0755);
    mount("devpts", "/dev/pts", "devpts", 0, NULL);
    mount("proc", "/proc", "proc", 0, NULL);
    mount("sysfs", "/sys", "sysfs", 0, NULL);

        /* indicate that booting is in progress to background fw loaders, etc */
    close(open("/dev/.booting", O_WRONLY | O_CREAT, 0000));

        /* We must have some place other than / to create the
         * device nodes for kmsg and null, otherwise we won't
         * be able to remount / read-only later on.
         * Now that tmpfs is mounted on /dev, we can actually
         * talk to the outside world.
         */
    open_devnull_stdio();
    //初始化日志系统
    klog_init();

    //解析init.rc配置文件(这个是重点分析的)
    INFO("reading config file\n");
    init_parse_config_file("/init.rc");

    /* pull the kernel commandline and ramdisk properties file in */
    import_kernel_cmdline(0, import_kernel_nv);
    /* don't expose the raw commandline to nonpriv processes */
    chmod("/proc/cmdline", 0440);
    //读取/proc/cpuinfo得到机器hardware名称
    get_hardware_name(hardware, &revision);
    snprintf(tmp, sizeof(tmp), "/init.%s.rc", hardware);
    //解析tmp 文件,也就是/init.<hardware>.rc文件
    init_parse_config_file(tmp);

    //解析完上面两个rc文件之后得到很多Action。
    //这里执行名称为early-init的Action
    action_for_each_trigger("early-init", action_add_queue_tail);

    //触发内置的Action。第一个参数是函数指针,第二个参数是action的名称
    queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
    queue_builtin_action(property_init_action, "property_init");
    queue_builtin_action(keychord_init_action, "keychord_init");
    queue_builtin_action(console_init_action, "console_init");
    queue_builtin_action(set_init_properties_action, "set_init_properties");

    // 执行名称为init的action
    /* execute all the boot actions to get us started */
    action_for_each_trigger("init", action_add_queue_tail);

    /* skip mounting filesystems in charger mode */
    //如果正在充电则执行下面的action
    if (strcmp(bootmode, "charger") != 0) {
        action_for_each_trigger("early-fs", action_add_queue_tail);
        action_for_each_trigger("fs", action_add_queue_tail);
        action_for_each_trigger("post-fs", action_add_queue_tail);
        action_for_each_trigger("post-fs-data", action_add_queue_tail);
    }
    //触发内置Action
    queue_builtin_action(property_service_init_action, "property_service_init");
    queue_builtin_action(signal_init_action, "signal_init");
    queue_builtin_action(check_startup_action, "check_startup");

    if (!strcmp(bootmode, "charger")) {
        action_for_each_trigger("charger", action_add_queue_tail);
    } else {
        action_for_each_trigger("early-boot", action_add_queue_tail);
        action_for_each_trigger("boot", action_add_queue_tail);
    }

        /* run all property triggers based on current state of the properties */
    queue_builtin_action(queue_property_triggers_action, "queue_propety_triggers");

#if BOOTCHART
    queue_builtin_action(bootchart_init_action, "bootchart_init");
#endif

//执行完上面初始化和触发action的过程之后进入一个死循环,执行Command
    for(;;) {
        int nr, i, timeout = -1;

        execute_one_command();
       //如果service异常退出,重启它
        restart_processes();
       //监听来自property service事件,后面会介绍
        if (!property_set_fd_init && get_property_set_fd() > 0) {
            ufds[fd_count].fd = get_property_set_fd();
            ufds[fd_count].events = POLLIN;
            ufds[fd_count].revents = 0;
            fd_count++;
            property_set_fd_init = 1;
        }
        //监听来自signal事件 ,signal是用来处理子进程退出时的操作,防止子进程编程僵尸进程

        if (!signal_fd_init && get_signal_fd() > 0) {
            ufds[fd_count].fd = get_signal_fd();
            ufds[fd_count].events = POLLIN;
            ufds[fd_count].revents = 0;
            fd_count++;
            signal_fd_init = 1;
        }
       //监听来自keychord设备事件
        if (!keychord_fd_init && get_keychord_fd() > 0) {
            ufds[fd_count].fd = get_keychord_fd();
            ufds[fd_count].events = POLLIN;
            ufds[fd_count].revents = 0;
            fd_count++;
            keychord_fd_init = 1;
        }
         //如果异常终止的service重启,设置等待时间
        if (process_needs_restart) {
            timeout = (process_needs_restart - gettime()) * 1000;
            if (timeout < 0)
                timeout = 0;
        }

        if (!action_queue_empty() || cur_action)
            timeout = 0;

#if BOOTCHART
        if (bootchart_count > 0) {
            if (timeout < 0 || timeout > BOOTCHART_POLLING_MS)
                timeout = BOOTCHART_POLLING_MS;
            if (bootchart_step() < 0 || --bootchart_count == 0) {
                bootchart_finish();
                bootchart_count = 0;
            }
        }
#endif
        //多路监听设备
        nr = poll(ufds, fd_count, timeout);
        if (nr <= 0)
            continue;

        for (i = 0; i < fd_count; i++) {
            if (ufds[i].revents == POLLIN) {
                if (ufds[i].fd == get_property_set_fd())
                    handle_property_set_fd();//处理property service事件
                else if (ufds[i].fd == get_keychord_fd())
                    handle_keychord();//处理keychord事件
                else if (ufds[i].fd == get_signal_fd())
                    handle_signal();//处理signal事件
            }
        }
    }
    return 0;
}

init要做的工作还是很多的。

第一阶段是初始化文件系统,不作讨论。从第二部分开始分析

3.3 init.rc文件解析

先来看一些init.rc文件,它在system\core\rootdir\init.rc

#on用来声明这是一个Action,early-init是该Action的触发条件,也是它的名称
on early-init
    #执行命令
    start ueventd
# create mountpoints
      #执行命令
    mkdir /mnt 0775 root system

 //省略。。。
#service声明是这是一个Service,servicemanager 是Service名称,/system/bin/servicemanager是程序地址
service servicemanager /system/bin/servicemanager
#class、user等都是option
    class core
    user system
    group system
    critical
    onrestart restart zygote
    onrestart restart media

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
    class main
    socket zygote stream 666
    onrestart write /sys/android_power/request_state wake
    onrestart write /sys/power/state on
    onrestart restart media
    onrestart restart netd
 //....

可以看出init.rc有自己的文件格式,该格式是由android init language定义的。简要说明一下:

3.3.1 android init language(android 初始化语言)

一共有四种类型Action、Service、Command、Options

两个基本关键字on和service

辅助指令的关键字Trigger

使用on来声明一个Action,使用service声明一个Service

一个Action或者一个Service是Section,init.rc就是由一个一个的Section组成

Command是最小的功能单位,代表一个linux命令或者一个方法调用

Trigger是触发条件,如果满足这个条件就执行Action,也是Action的名称

Option用来修饰Service,描述Service的一些信息

分别来介绍

1.Action

Action就是一组被命名的Command执行序列。在满足触发器条件时就会将该action放到一个队里中,下面会介绍。

格式如下:

on <trigger>

<command>

<command>

<command>

.....

2.Trigger

触发器,用来判断特定类型条件的发生,用在Action之中

常见的trigger

1.boot:  /init.conf加载后第一个被触发的trigger。

2.property:<property name>=<property value>:当name的值为value时触发。

on property:ro.debuggable=1
start console

3.device-added-<path>: 设备添加时触发

4.device-removed-<path>:设备移除时触发

5.service-exited-<name>:服务退出时触发

3.command

命令,可以是linux命令或者函数调用

常见的command:

    exec <path> [ <argument> ]*  执行路径为path的命令,参数是argument
    export <name> <value>    在全局环境变量中设在环境变量 <name>为<value>。
    ifup <interface>      启动网络接口<interface>
    import <filename>     解析一个init配置文件,扩展当前配置。
    hostname <name>      设置主机名。
    chmod <octal-mode> <path>     更改文件访问权限。
    chown <owner> <group> <path>    更改文件的所有者和组。
    class_start <serviceclass>   启动所有指定服务类下的未运行服务。
    class_stop <serviceclass>   停止指定服务类下的所有已运行的服务。
    domainname <name>    设置域名。
    insmod <path>        加载<path>中的模块。
    mkdir <path> [mode] [owner] [group]    创建一个目录<path>,
    mount <type> <device> <dir> [ <mountoption> ]*   试图在目录<dir>挂载指定的设备
    setprop <name> <value>    设置系统属性 <name> 为 <value>值.
    setrlimit <resource> <cur> <max>      设置<resource>的rlimit(资源限制)。
    start <service>   启动指定服务(如果此服务还未运行)。
    stop <service>    停止指定服务(如果此服务在运行中)。
    symlink <target> <path>      创建一个指向<path>的软连接<target>。
    sysclktz <mins_west_of_gmt>    设置系统时钟基准(0代表时钟滴答以格林威治平均时(GMT)为准)
    trigger <event>      触发一个事件。
    write <path> <string> [ <string> ]*      打开路径为<path>的一个文件,并写入一个或多个字符串。

4.Service

就是init进程启动或者重新启动的程序,格式:

service<name><path>[<argument>]*

<option>

<option>

<option>

...

<option>

其中name是服务名称,path是程序路径,argument是参数,option是服务设置选项

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
    class main
    socket zygote stream 666
    onrestart write /sys/android_power/request_state wake
    onrestart write /sys/power/state on
    onrestart restart media
    onrestart restart netd

zygote是服务名称, /system/bin/app_process是程序路径, -Xzygote /system/bin --zygote --start-system-server是参数

下面的class,onrestart都是option

5.option

用来辅助设置service选项

常见的:

     critical: 说明这是一个对于设备关键的服务。如果一定时间退出多次,系统将会重启并进入recovery(恢复)模式。
     disabled:说明这个服务禁用,不会自动启动此服务,但是可以手动启动。
     setenv <name> <value> :设置环境变量       在进程启动时将环境变量<name>设置为<value>。
     socket <name> <type> <perm> [ <user> [ <group> ] ]     创建一个Uinx域的名为/dev/socket/<name> 的套接字,并传递它的文件描述符给已启动的进程。<type> 必须是 "dgram"或"stream"。User 和 group默认为0。
     user <username>    在启动这个服务前改变切换到用户username,此时默认为root。
     group <groupname> [ <groupname> ]*  在启动这个服务前改变切换到用户组username,此时默认为root。
     oneshot:只启动一次,一旦关闭就不再重启
     class <name> 指定一个服务类别。所有同一类的服务可以同时启动和停止。默认为"default"类服务。
     onrestart <Command>       当服务重启,执行一个命令

3.3.2 解析配置文件函数

init.c中的main函数中已经指明解析配置文件的函数是init_parse_config_file函数,该函数在system\core\init\init.parser.c文件中

int init_parse_config_file(const char *fn)
{
    char *data;
     //读取配置文件
    data = read_file(fn, 0);
    if (!data) return -1;
     //重点是这个函数,解析配置文件
    parse_config(fn, data);
    DUMP();
    return 0;
}

接着看parse_config函数

static void parse_config(const char *fn, char *s)
{
    struct parse_state state;//保存解析状态
    char *args[INIT_PARSER_MAXARGS];//存储参数
    int nargs;//参数个数

    nargs = 0;
    state.filename = fn;//解析得文件路径
    state.line = 0;//当前解析的行号
    state.ptr = s;//当前解析的内容
    state.nexttoken = 0;//当前解析是那种类型的行,有文件结束T_EOF,新的一行T_NEWLINE,参数T_TEXT
    state.parse_line = parse_line_no_op;//parse_line_no_op是空操作
    for (;;) {
        switch (next_token(&state)) {
        case T_EOF://文件结束
            state.parse_line(&state, 0, 0);
            return;
        case T_NEWLINE://新的一行
            state.line++;
            if (nargs) {
                int kw = lookup_keyword(args[0]);//是哪一个关键字
                if (kw_is(kw, SECTION)) {//如果该关键字是section
                    state.parse_line(&state, 0, 0);
                    parse_new_section(&state, kw, nargs, args);//在这里才真正开始开始解析Section
                } else {
                    state.parse_line(&state, nargs, args);
                }
                nargs = 0;
            }
            break;
        case T_TEXT:
            if (nargs < INIT_PARSER_MAXARGS) {
                args[nargs++] = state.text;
            }
            break;
        }
    }
}

关键函数是parse_new_section

void parse_new_section(struct parse_state *state, int kw,int nargs, char **args)
{
    printf("[ %s %s ]\n", args[0],nargs > 1 ? args[1] : "");
    switch(kw) {
    case K_service://如果是Service的Section,开始解析Service
        state->context = parse_service(state, nargs, args);//保存调用过parse_service的service
        if (state->context) {
            state->parse_line = parse_line_service;//parse_line_service 才是真正的解析并填充Service函数
            return;
        }
        break;
    case K_on://如果是Action的Section,开始解析Action
        state->context = parse_action(state, nargs, args);//保存调用过parse_action的action
        if (state->context) {
            state->parse_line = parse_line_action;//parse_line_action才是真正的解析并填充Action函数
            return;
        }
        break;
    case K_import:
        if (nargs != 2) {
            ERROR("single argument needed for import\n");
        } else {
            int ret = init_parse_config_file(args[1]);
            if (ret)
                ERROR("could not import file %s\n", args[1]);
        }
    }
    state->parse_line = parse_line_no_op;
}

解析Service调用了parse_service和parse_line_service

解析Action调用了parse_action和parse_line_action

3.3.3 解析Service

1.parse_service

先介绍几个概念:service结构体、service_list变量、list_init函数、list_add_tail函数

service结构体用来保存和service相关信息,定义在/system/core/init/init.h文件中

struct service {
        /* list of all services */
//用于将结构体连接成一个双向链表,init中有一个全局变量service_list,专门保存解析后的service
   struct listnode slist;//用于将结构体连接成一个双向链表,init中有一个全局变量

    const char *name;//名称
    const char *classname;//classname,默认是default
    unsigned flags;//属性标志
    pid_t pid;//进程号
    time_t time_started;    /* time of last start 上次启动时间   */
    time_t time_crashed;    /* first crash within inspection window 上次异常退出时间 */
    int nr_crashed;         /* number of times crashed within window  异常退出次数*/

    uid_t uid;//用户id
    gid_t gid;//用户组id
    gid_t supp_gids[NR_SVC_SUPP_GIDS];
    size_t nr_supp_gids;
    //service使用的socket
    struct socketinfo *sockets;
    //service环境变量
    struct svcenvinfo *envvars;
    //service中的onrestart是一个option,但是它后面是一系列的command,可以看做是一个action
    struct action onrestart;  /* Actions to execute on restart. */

    /* keycodes for triggering this service via /dev/keychord */
     //和keychord有关的
    int *keycodes;
    int nkeycodes;
    int keychord_id;
     //io优先级
    int ioprio_class;
    int ioprio_pri;
    //参数个数
    int nargs;
    /* "MUST BE AT THE END OF THE STRUCT" */
    //参数列表
    char *args[1];
}

2.service_list成员变量:init进程中的一个双向链表,专门保存解析后的service,它的类型是listnode类型:

struct listnode
{
     struct listnode * next;
     struct listnode * prev;
 };

存放链表的前后指针,将链表中的指针部分和数据部分分离,使得这个结构和数据类型无关,避免了不同数据类型定义大量重复的链表操作。

3.list_init函数在system/core/libcutils/list.c中

void list_init(struct listnode *node)
{
    node->next = node;
    node->prev = node;
}

4.list_add_tail函数在system/core/libcutils/list.c中

void list_add_tail(struct listnode *head, struct listnode *item)
{
    item->next = head;
    item->prev = head->prev;
    head->prev->next = item;
    head->prev = item;
}

将item将加入到head链表的尾部

再来看parse_service函数:

static void *parse_service(struct parse_state *state, int nargs, char **args)
{
    struct service *svc;//定义的service结构体,用来保存解析出来的service
     //异常处理代码
    if (nargs < 3) {
        parse_error(state, "services must have a name and a program\n");
        return 0;
    }
    if (!valid_name(args[1])) {
        parse_error(state, "invalid service name '%s'\n", args[1]);
        return 0;
    }

    svc = service_find_by_name(args[1]);
    if (svc) {
        parse_error(state, "ignored duplicate definition of service '%s'\n", args[1]);
        return 0;
    }

    nargs -= 2;
    svc = calloc(1, sizeof(*svc) + sizeof(char*) * nargs);//为Service分配内存空间
    if (!svc) {
        parse_error(state, "out of memory\n");
        return 0;
    }
    为svc结构体填充数据赋值
    svc->name = args[1];
    svc->classname = "default";//默认为default类比
    memcpy(svc->args, args + 2, sizeof(char*) * nargs);
    svc->args[nargs] = 0;
    svc->nargs = nargs;
    svc->onrestart.name = "onrestart";
    //Service中的onrestart 是Action类型的链表,初始化该链表
    list_init(&svc->onrestart.commands);
    //将service中的slist加入到service_list 中
    list_add_tail(&service_list, &svc->slist);
    return svc;
}

parse_service仅仅填充了service的一小部分内容,其中大部分内容需要parse_line_service完成

2.parse_line_service

static void parse_line_service(struct parse_state *state, int nargs, char **args)
{
    struct service *svc = state->context;//取出刚才创建的service
    struct command *cmd;
    int i, kw, kw_nargs;

    if (nargs == 0) {
        return;
    }

    svc->ioprio_class = IoSchedClass_NONE;//设置IO优先级

    kw = lookup_keyword(args[0]);//配置service中的option关键字
    switch (kw) {
     //......
    case K_onrestart://处理onrestart选项
        nargs--;
        args++;
        kw = lookup_keyword(args[0]);
        if (!kw_is(kw, COMMAND)) {//如果onrestart 选项后面不是command 提示错误
            parse_error(state, "invalid command '%s'\n", args[0]);
            break;
        }
        kw_nargs = kw_nargs(kw);
        if (nargs < kw_nargs) {
            parse_error(state, "%s requires %d %s\n", args[0], kw_nargs - 1,
                kw_nargs > 2 ? "arguments" : "argument");
            break;
        }
        //service中onrestart  option的command序列创建过程
        cmd = malloc(sizeof(*cmd) + sizeof(char*) * nargs);
        cmd->func = kw_func(kw);
        cmd->nargs = nargs;
        memcpy(cmd->args, args, sizeof(char*) * nargs);
        list_add_tail(&svc->onrestart.commands, &cmd->clist);
        break;
    case K_critical:
        svc->flags |= SVC_CRITICAL;
        break;
    case K_setenv: { /* name value */
        struct svcenvinfo *ei;
        if (nargs < 2) {
            parse_error(state, "setenv option requires name and value arguments\n");
            break;
        }
        ei = calloc(1, sizeof(*ei));
        if (!ei) {
            parse_error(state, "out of memory\n");
            break;
        }
        ei->name = args[1];
        ei->value = args[2];
        ei->next = svc->envvars;
        svc->envvars = ei;
        break;
    }

    //如果需要创建socket
    case K_socket: {/* name type perm [ uid gid ] */
        struct socketinfo *si;
        if (nargs < 4) {
            parse_error(state, "socket option requires name, type, perm arguments\n");
            break;
        }
        if (strcmp(args[2],"dgram") && strcmp(args[2],"stream")
                && strcmp(args[2],"seqpacket")) {
            parse_error(state, "socket type must be 'dgram', 'stream' or 'seqpacket'\n");
            break;
        }
        si = calloc(1, sizeof(*si));
        if (!si) {
            parse_error(state, "out of memory\n");
            break;
        }
        si->name = args[1];
        si->type = args[2];
        si->perm = strtoul(args[3], 0, 8);
        if (nargs > 4)
            si->uid = decode_uid(args[4]);
        if (nargs > 5)
            si->gid = decode_uid(args[5]);
        si->next = svc->sockets;
        svc->sockets = si;
        break;
    }
    ...
    default:
        parse_error(state, "invalid option '%s'\n", args[0]);
    }
}

时间: 2025-01-11 08:30:55

第三章 Android 启动过程的底层实现的相关文章

第四章 Android启动过程的上层实现

Android中有两个世界,一个是Java世界,一个是Native世界.第三章介绍的是native世界的启动,那么java世界是什么时候启动的呢?还记得在解析完init.rc文件之后启动很多的服务,其中非常重要的两个服务就是zygote和servicemanager.其中zygote就是android世界的第一个虚拟机,在android中扮演非常重要的角色,下面讨论的内容就是android启动剩下的流程,先看一个android上层启动的流程: 1 ini进程在解析完init.rc文件之后启动了一

Android 启动过程的底层实现

转载请标明出处: http://blog.csdn.net/yujun411522/article/details/46367787 本文出自:[yujun411522的博客] 3.1 android正常模式启动流程 主要流程例如以下: 1.系统加电.运行bootloader,bootloader会将内核载入到内存中. 2.内核载入到内存之后首先进入内核引导阶段,最后调用start_kernel进入内核启动.start_kernel终于会启动init程序 3.init程序负责解析init.rc文

Android 渗透测试学习手册 第三章 Android 应用的逆向和审计

第三章 Android 应用的逆向和审计 作者:Aditya Gupta 译者:飞龙 协议:CC BY-NC-SA 4.0 在本章中,我们将查看 Android 应用程序或.apk文件,并了解其不同的组件. 我们还将使用工具(如 Apktool,dex2jar 和 jd-gui)来逆向应用程序. 我们将进一步学习如何通过逆向和分析源代码来寻找 Android 应用程序中的各种漏洞. 我们还将使用一些静态分析工具和脚本来查找漏洞并利用它们. 3.1 Android 应用程序拆解 Android 应

Android启动过程深入解析

Android启动过程深入解析 2014/06/20 分享到:7 本文由 伯乐在线 - 云海之巅 翻译.未经许可,禁止转载!英文出处:kpbird.欢迎加入翻译小组. 当按下Android设备电源键时究竟发生了什么? Android的启动过程是怎么样的? 什么是Linux内核? 桌面系统linux内核与Android系统linux内核有什么区别? 什么是引导装载程序? 什么是Zygote? 什么是X86以及ARM linux? 什么是init.rc? 什么是系统服务? 当我们想到Android启

Android启动过程

Android启动过程 1.  加载Linux内核 2. Android init进程对各种设备进行初始化,运行Android Framework所需用的各种Daemon(后台进程/守护进程),Context Manager,MediaServer,Zygote等 以下是init进程执行的Daemon进程: USB Daemon(usbd): 管理USB连接 Android Debug Bridge Daemon(adbd): Android  Debug Bridge连接管理 Debugger

【ALearning】第三章 Android基本常见控件

本章主要介绍基本的平常较多使用的控件,包括TextView.EditView.ImageView.Button等.本章将介绍相关控件基本属性的使用,为以后章节的进阶学习提供基础.案例中引用的LinearLayout布局,可先不必深究,后续章节将会详细介绍. TextView TextView控件的基本属性,android:layout_width 布局宽度android:layout_height 布局高度.这两个属性参数是必须的. TextView 中android:layout_width与

Android教材 | 第三章 Android界面事件处理(二)—— 杰瑞教育原创教材试读

 编者按 JRedu 杰瑞教育原创系列教材将于年后与大家正式见面.为更好的借鉴读者意见,我们将会陆续地在博客园推出一系列教材试读.我们也热忱的欢迎广大博友与我们互动,提出宝贵意见. 本篇博客将推出教材第三章第二部分的试读(传送门:第一部分),请大家继续提出宝贵意见,我们也将为积极互动的博友,免费提供我们的原创教材以及更多福利,也欢迎大家加入最下方QQ群与我们交流,谢谢大家! 3.5 系统设置事件处理 3.5.1onConfigurationChanged响应事件 在App开发过程中,有时候需要获

Android启动过程——init,Zygote,SystemServer

一.Android设备启动经历的三个阶段:Boot Loader:Linux Kernel.Android系统服务:每一个阶段都有自己的启动画面. 1.Android中第一个被启动的进程--init,init进程的PID为1,其它的服务都由其进行创建.它是通过解析init.rc脚本来构建出系统的初始执行状态的.init进程是在系统启动启动过程中启动的. 2.init.rc语法规则: 1)Actions动作 一个Action实际上就是对应某个事件的过程. 以下给出boot事件的脚本 /* \sys

Android启动过程——init.rc,Zygote,SystemServer

一.Android设备启动经历的三个阶段:Boot Loader:Linux Kernel:Android系统服务:每个阶段都有自己的启动画面. 1.Android中第一个被启动的进程--init,init进程的PID为0,其他的服务都由其进行创建.它是通过解析init.rc脚本来构建出系统的初始运行状态的.init进程是在系统启动启动过程中启动的. 2.init.rc语法规则: 1)Actions动作 一个Action实际上就是相应某个事件的过程.下面给出boot事件的脚本 /* \syste