Service Manager在Android進程間通信機制Binder中的身份--守護進程

原創 zzc901205 2020-02-22 11:19

       Android進程間通信機制Binder的總體架構，它由Client， Server， Service Manager和驅動程序Binder四個組件構成。

Service Manager是整個Binder機制的守護進程，用來管理開發這創建的各種Server，並向Client提供查詢Server遠程接口的功能。

       既然Service Manager組件是用來管理Server並且向Client提供查詢Server遠程接口的功能，那麼，Service Manager就必然要和Server以及Client進行通信了。Service Manager，Server和Client三者分別運行在獨立的進程中，他們之間的通信業屬於進程間通信，而且採用的是Binder機制進行進程間通信，因此，Service Manager在充當Binder機制的守護進程的同時，也在充當Server角色，Service Manager是一種特殊的Sever。


       下面圍繞Service Manager如何成爲整個Binder機制的守護進程這條主線來一步一步分析相關源碼，包括從用戶空間到內核空間的相關源代碼-----希望讀者在閱讀下面的內容之前，先閱讀一下參考資料Android深入淺出之Binder機制和Android Binder設計與實現，熟悉相關概念和數據結構，這有助於理解下面要分析的源代碼。


  Service Manager在用戶空間的源代碼位於frameworks/base/cmds/servicemanager目錄下，主要是由binder.h、binder.c和service_manager.c三個文件組成。Service Manager的入口位於service_manager.c文件中的main函數：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. int main(int argc, char **argv)  
  2. {  
  3.     struct binder_state *bs;  
  4.     void *svcmgr = BINDER_SERVICE_MANAGER;  
  5.   
  6.     bs = binder_open(128*1024);  
  7.   
  8.     if (binder_become_context_manager(bs)) {  
  9.         LOGE("cannot become context manager (%s)\n", strerror(errno));  
  10.         return -1;  
  11.     }  
  12.   
  13.     svcmgr_handle = svcmgr;  
  14.     binder_loop(bs, svcmgr_handler);  
  15.     return 0;  
  16. }  
        main函數主要有三個功能：一是打開Binder設備文件；二是告訴Binder驅動程序自己是Binder上下文管理者，即我們前面所說的守護進程；三是進入一個無窮循環，充當Server的角色，等待Client的請求。進入這三個功能之間，先來看一下這裏用到的結構體binder_state、宏BINDER_SERVICE_MANAGER的定義：

        struct binder_state定義在frameworks/base/cmds/servicemanager/binder.c文件中：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. struct binder_state  
  2. {  
  3.     int fd;  
  4.     void *mapped;  
  5.     unsigned mapsize;  
  6. };  
        fd是文件描述符，即表示打開的/dev/binder設備文件描述符；mapped是把設備文件/dev/binder映射到進程空間的起始地址；mapsize是上述內存映射空間的大小。

        宏BINDER_SERVICE_MANAGER定義frameworks/base/cmds/servicemanager/binder.h文件中：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. /* the one magic object */  
  2. #define BINDER_SERVICE_MANAGER ((void*) 0)  
        它表示Service Manager的句柄爲0。Binder通信機制使用句柄來代表遠程接口，這個句柄的意義和Windows編程中用到的句柄是差不多的概念。前面說到，Service Manager在充當守護進程的同時，它充當Server的角色，當它作爲遠程接口使用時，它的句柄值便爲0，這就是它的特殊之處，其餘的Server的遠程接口句柄值都是一個大於0 而且由Binder驅動程序自動進行分配的。

        函數首先是執行打開Binder設備文件的操作binder_open，這個函數位於frameworks/base/cmds/servicemanager/binder.c文件中：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. struct binder_state *binder_open(unsigned mapsize)  
  2. {  
  3.     struct binder_state *bs;  
  4.   
  5.     bs = malloc(sizeof(*bs));  
  6.     if (!bs) {  
  7.         errno = ENOMEM;  
  8.         return 0;  
  9.     }  
  10.   
  11.     bs->fd = open("/dev/binder", O_RDWR);  
  12.     if (bs->fd < 0) {  
  13.         fprintf(stderr,"binder: cannot open device (%s)\n",  
  14.                 strerror(errno));  
  15.         goto fail_open;  
  16.     }  
  17.   
  18.     bs->mapsize = mapsize;  
  19.     bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);  
  20.     if (bs->mapped == MAP_FAILED) {  
  21.         fprintf(stderr,"binder: cannot map device (%s)\n",  
  22.                 strerror(errno));  
  23.         goto fail_map;  
  24.     }  
  25.   
  26.         /* TODO: check version */  
  27.   
  28.     return bs;  
  29.   
  30. fail_map:  
  31.     close(bs->fd);  
  32. fail_open:  
  33.     free(bs);  
  34.     return 0;  
  35. }  
       通過文件操作函數open來打開/dev/binder設備文件。設備文件/dev/binder是在Binder驅動程序模塊初始化的時候創建的，我們先看一下這個設備文件的創建過程。進入到kernel/common/drivers/staging/android目錄中，打開binder.c文件，可以看到模塊初始化入口binder_init：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static struct file_operations binder_fops = {  
  2.     .owner = THIS_MODULE,  
  3.     .poll = binder_poll,  
  4.     .unlocked_ioctl = binder_ioctl,  
  5.     .mmap = binder_mmap,  
  6.     .open = binder_open,  
  7.     .flush = binder_flush,  
  8.     .release = binder_release,  
  9. };  
  10.   
  11. static struct miscdevice binder_miscdev = {  
  12.     .minor = MISC_DYNAMIC_MINOR,  
  13.     .name = "binder",  
  14.     .fops = &binder_fops  
  15. };  
  16.   
  17. static int __init binder_init(void)  
  18. {  
  19.     int ret;  
  20.   
  21.     binder_proc_dir_entry_root = proc_mkdir("binder", NULL);  
  22.     if (binder_proc_dir_entry_root)  
  23.         binder_proc_dir_entry_proc = proc_mkdir("proc", binder_proc_dir_entry_root);  
  24.     ret = misc_register(&binder_miscdev);  
  25.     if (binder_proc_dir_entry_root) {  
  26.         create_proc_read_entry("state", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_state, NULL);  
  27.         create_proc_read_entry("stats", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_stats, NULL);  
  28.         create_proc_read_entry("transactions", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_transactions, NULL);  
  29.         create_proc_read_entry("transaction_log", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_transaction_log, &binder_transaction_log);  
  30.         create_proc_read_entry("failed_transaction_log", S_IRUGO, binder_proc_dir_entry_root, binder_read_proc_transaction_log, &binder_transaction_log_failed);  
  31.     }  
  32.     return ret;  
  33. }  
  34.   
  35. device_initcall(binder_init);  

        創建設備文件的地方在misc_register函數裏面，關於misc設備的註冊，我們在Android日誌系統驅動程序Logger源代碼分析一文中有提到，有興趣的讀取不訪去了解一下。其餘的邏輯主要是在/proc目錄創建各種Binder相關的文件，供用戶訪問。從設備文件的操作方法binder_fops可以看出，前面的binder_open函數執行語句：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. bs->fd = open("/dev/binder", O_RDWR);  

        就進入到Binder驅動程序的binder_open函數了：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static int binder_open(struct inode *nodp, struct file *filp)  
  2. {  
  3.     struct binder_proc *proc;  
  4.   
  5.     if (binder_debug_mask & BINDER_DEBUG_OPEN_CLOSE)  
  6.         printk(KERN_INFO "binder_open: %d:%d\n", current->group_leader->pid, current->pid);  
  7.   
  8.     proc = kzalloc(sizeof(*proc), GFP_KERNEL);  
  9.     if (proc == NULL)  
  10.         return -ENOMEM;  
  11.     get_task_struct(current);  
  12.     proc->tsk = current;  
  13.     INIT_LIST_HEAD(&proc->todo);  
  14.     init_waitqueue_head(&proc->wait);  
  15.     proc->default_priority = task_nice(current);  
  16.     mutex_lock(&binder_lock);  
  17.     binder_stats.obj_created[BINDER_STAT_PROC]++;  
  18.     hlist_add_head(&proc->proc_node, &binder_procs);  
  19.     proc->pid = current->group_leader->pid;  
  20.     INIT_LIST_HEAD(&proc->delivered_death);  
  21.     filp->private_data = proc;  
  22.     mutex_unlock(&binder_lock);  
  23.   
  24.     if (binder_proc_dir_entry_proc) {  
  25.         char strbuf[11];  
  26.         snprintf(strbuf, sizeof(strbuf), "%u", proc->pid);  
  27.         remove_proc_entry(strbuf, binder_proc_dir_entry_proc);  
  28.         create_proc_read_entry(strbuf, S_IRUGO, binder_proc_dir_entry_proc, binder_read_proc_proc, proc);  
  29.     }  
  30.   
  31.     return 0;  
  32. }  
         這個函數的主要作用是創建一個struct binder_proc數據結構來保存打開設備文件/dev/binder的進程的上下文信息，並且將這個進程上下文信息保存在打開文件結構struct file的私有數據成員變量private_data中，這樣，在執行其它文件操作時，就通過打開文件結構struct file來取回這個進程上下文信息了。這個進程上下文信息同時還會保存在一個全局哈希表binder_procs中，驅動程序內部使用。binder_procs定義在文件的開頭：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static HLIST_HEAD(binder_procs);  
        結構體struct binder_proc也是定義在kernel/common/drivers/staging/android/binder.c文件中：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. struct binder_proc {  
  2.     struct hlist_node proc_node;  
  3.     struct rb_root threads;  
  4.     struct rb_root nodes;  
  5.     struct rb_root refs_by_desc;  
  6.     struct rb_root refs_by_node;  
  7.     int pid;  
  8.     struct vm_area_struct *vma;  
  9.     struct task_struct *tsk;  
  10.     struct files_struct *files;  
  11.     struct hlist_node deferred_work_node;  
  12.     int deferred_work;  
  13.     void *buffer;  
  14.     ptrdiff_t user_buffer_offset;  
  15.   
  16.     struct list_head buffers;  
  17.     struct rb_root free_buffers;  
  18.     struct rb_root allocated_buffers;  
  19.     size_t free_async_space;  
  20.   
  21.     struct page **pages;  
  22.     size_t buffer_size;  
  23.     uint32_t buffer_free;  
  24.     struct list_head todo;  
  25.     wait_queue_head_t wait;  
  26.     struct binder_stats stats;  
  27.     struct list_head delivered_death;  
  28.     int max_threads;  
  29.     int requested_threads;  
  30.     int requested_threads_started;  
  31.     int ready_threads;  
  32.     long default_priority;  
  33. };  
        這個結構體的成員比較多，這裏就不一一說明了，簡單解釋一下四個成員變量threads、nodes、 refs_by_desc和refs_by_node，其它的我們在遇到的時候再詳細解釋。這四個成員變量都是表示紅黑樹的節點，也就是說，binder_proc分別掛會四個紅黑樹下。threads樹用來保存binder_proc進程內用於處理用戶請求的線程，它的最大數量由max_threads來決定；node樹成用來保存binder_proc進程內的Binder實體；refs_by_desc樹和refs_by_node樹用來保存binder_proc進程內的Binder引用，即引用的其它進程的Binder實體，它分別用兩種方式來組織紅黑樹，一種是以句柄作來key值來組織，一種是以引用的實體節點的地址值作來key值來組織，它們都是表示同一樣東西，只不過是爲了內部查找方便而用兩個紅黑樹來表示。

         這樣，打開設備文件/dev/binder的操作就完成了，接着是對打開的設備文件進行內存映射操作mmap：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);  

         對應Binder驅動程序的binder_mmap函數：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static int binder_mmap(struct file *filp, struct vm_area_struct *vma)  
  2. {  
  3.     int ret;  
  4.     struct vm_struct *area;  
  5.     struct binder_proc *proc = filp->private_data;  
  6.     const char *failure_string;  
  7.     struct binder_buffer *buffer;  
  8.   
  9.     if ((vma->vm_end - vma->vm_start) > SZ_4M)  
  10.         vma->vm_end = vma->vm_start + SZ_4M;  
  11.   
  12.     if (binder_debug_mask & BINDER_DEBUG_OPEN_CLOSE)  
  13.         printk(KERN_INFO  
  14.             "binder_mmap: %d %lx-%lx (%ld K) vma %lx pagep %lx\n",  
  15.             proc->pid, vma->vm_start, vma->vm_end,  
  16.             (vma->vm_end - vma->vm_start) / SZ_1K, vma->vm_flags,  
  17.             (unsigned long)pgprot_val(vma->vm_page_prot));  
  18.   
  19.     if (vma->vm_flags & FORBIDDEN_MMAP_FLAGS) {  
  20.         ret = -EPERM;  
  21.         failure_string = "bad vm_flags";  
  22.         goto err_bad_arg;  
  23.     }  
  24.     vma->vm_flags = (vma->vm_flags | VM_DONTCOPY) & ~VM_MAYWRITE;  
  25.   
  26.     if (proc->buffer) {  
  27.         ret = -EBUSY;  
  28.         failure_string = "already mapped";  
  29.         goto err_already_mapped;  
  30.     }  
  31.   
  32.     area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP);  
  33.     if (area == NULL) {  
  34.         ret = -ENOMEM;  
  35.         failure_string = "get_vm_area";  
  36.         goto err_get_vm_area_failed;  
  37.     }  
  38.     proc->buffer = area->addr;  
  39.     proc->user_buffer_offset = vma->vm_start - (uintptr_t)proc->buffer;  
  40.   
  41. #ifdef CONFIG_CPU_CACHE_VIPT  
  42.     if (cache_is_vipt_aliasing()) {  
  43.         while (CACHE_COLOUR((vma->vm_start ^ (uint32_t)proc->buffer))) {  
  44.             printk(KERN_INFO "binder_mmap: %d %lx-%lx maps %p bad alignment\n", proc->pid, vma->vm_start, vma->vm_end, proc->buffer);  
  45.             vma->vm_start += PAGE_SIZE;  
  46.         }  
  47.     }  
  48. #endif  
  49.     proc->pages = kzalloc(sizeof(proc->pages[0]) * ((vma->vm_end - vma->vm_start) / PAGE_SIZE), GFP_KERNEL);  
  50.     if (proc->pages == NULL) {  
  51.         ret = -ENOMEM;  
  52.         failure_string = "alloc page array";  
  53.         goto err_alloc_pages_failed;  
  54.     }  
  55.     proc->buffer_size = vma->vm_end - vma->vm_start;  
  56.   
  57.     vma->vm_ops = &binder_vm_ops;  
  58.     vma->vm_private_data = proc;  
  59.   
  60.     if (binder_update_page_range(proc, 1, proc->buffer, proc->buffer + PAGE_SIZE, vma)) {  
  61.         ret = -ENOMEM;  
  62.         failure_string = "alloc small buf";  
  63.         goto err_alloc_small_buf_failed;  
  64.     }  
  65.     buffer = proc->buffer;  
  66.     INIT_LIST_HEAD(&proc->buffers);  
  67.     list_add(&buffer->entry, &proc->buffers);  
  68.     buffer->free = 1;  
  69.     binder_insert_free_buffer(proc, buffer);  
  70.     proc->free_async_space = proc->buffer_size / 2;  
  71.     barrier();  
  72.     proc->files = get_files_struct(current);  
  73.     proc->vma = vma;  
  74.   
  75.     /*printk(KERN_INFO "binder_mmap: %d %lx-%lx maps %p\n", proc->pid, vma->vm_start, vma->vm_end, proc->buffer);*/  
  76.     return 0;  
  77.   
  78. err_alloc_small_buf_failed:  
  79.     kfree(proc->pages);  
  80.     proc->pages = NULL;  
  81. err_alloc_pages_failed:  
  82.     vfree(proc->buffer);  
  83.     proc->buffer = NULL;  
  84. err_get_vm_area_failed:  
  85. err_already_mapped:  
  86. err_bad_arg:  
  87.     printk(KERN_ERR "binder_mmap: %d %lx-%lx %s failed %d\n", proc->pid, vma->vm_start, vma->vm_end, failure_string, ret);  
  88.     return ret;  
  89. }  

         函數首先通過filp->private_data得到在打開設備文件/dev/binder時創建的struct binder_proc結構。內存映射信息放在vma參數中，注意，這裏的vma的數據類型是struct vm_area_struct，它表示的是一塊連續的虛擬地址空間區域，在函數變量聲明的地方，我們還看到有一個類似的結構體struct vm_struct，這個數據結構也是表示一塊連續的虛擬地址空間區域，那麼，這兩者的區別是什麼呢？在Linux中，struct vm_area_struct表示的虛擬地址是給進程使用的，而struct vm_struct表示的虛擬地址是給內核使用的，它們對應的物理頁面都可以是不連續的。struct vm_area_struct表示的地址空間範圍是0~3G，而struct vm_struct表示的地址空間範圍是(3G + 896M + 8M) ~ 4G。struct vm_struct表示的地址空間範圍爲什麼不是3G~4G呢？原來，3G ~ (3G + 896M)範圍的地址是用來映射連續的物理頁面的，這個範圍的虛擬地址和對應的實際物理地址有着簡單的對應關係，即對應0~896M的物理地址空間，而(3G + 896M) ~ (3G + 896M + 8M)是安全保護區域（例如，所有指向這8M地址空間的指針都是非法的），因此struct vm_struct使用(3G + 896M + 8M) ~ 4G地址空間來映射非連續的物理頁面。有關Linux的內存管理知識，可以參考Android學習啓動篇一文提到的《Understanding the Linux Kernel》一書中的第8章。

        這裏爲什麼會同時使用進程虛擬地址空間和內核虛擬地址空間來映射同一個物理頁面呢？這就是Binder進程間通信機制的精髓所在了，同一個物理頁面，一方映射到進程虛擬地址空間，一方面映射到內核虛擬地址空間，這樣，進程和內核之間就可以減少一次內存拷貝了，提到了進程間通信效率。舉個例子如，Client要將一塊內存數據傳遞給Server，一般的做法是，Client將這塊數據從它的進程空間拷貝到內核空間中，然後內核再將這個數據從內核空間拷貝到Server的進程空間，這樣，Server就可以訪問這個數據了。但是在這種方法中，執行了兩次內存拷貝操作，而採用我們上面提到的方法，只需要把Client進程空間的數據拷貝一次到內核空間，然後Server與內核共享這個數據就可以了，整個過程只需要執行一次內存拷貝，提高了效率。

        binder_mmap的原理講完了，這個函數的邏輯就好理解了。不過，這裏還是先要解釋一下struct binder_proc結構體的幾個成員變量。buffer成員變量是一個void*指針，它表示要映射的物理內存在內核空間中的起始位置；buffer_size成員變量是一個size_t類型的變量，表示要映射的內存的大小；pages成員變量是一個struct page*類型的數組，struct page是用來描述物理頁面的數據結構；user_buffer_offset成員變量是一個ptrdiff_t類型的變量，它表示的是內核使用的虛擬地址與進程使用的虛擬地址之間的差值，即如果某個物理頁面在內核空間中對應的虛擬地址是addr的話，那麼這個物理頁面在進程空間對應的虛擬地址就爲addr + user_buffer_offset。

        再解釋一下Binder驅動程序管理這個內存映射地址空間的方法，即是如何管理buffer ~ (buffer + buffer_size)這段地址空間的，這個地址空間被劃分爲一段一段來管理，每一段是結構體struct binder_buffer來描述：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. struct binder_buffer {  
  2.     struct list_head entry; /* free and allocated entries by addesss */  
  3.     struct rb_node rb_node; /* free entry by size or allocated entry */  
  4.                 /* by address */  
  5.     unsigned free : 1;  
  6.     unsigned allow_user_free : 1;  
  7.     unsigned async_transaction : 1;  
  8.     unsigned debug_id : 29;  
  9.   
  10.     struct binder_transaction *transaction;  
  11.   
  12.     struct binder_node *target_node;  
  13.     size_t data_size;  
  14.     size_t offsets_size;  
  15.     uint8_t data[0];  
  16. };  
        每一個binder_buffer通過其成員entry按從低址到高地址連入到struct binder_proc中的buffers表示的鏈表中去，同時，每一個binder_buffer又分爲正在使用的和空閒的，通過free成員變量來區分，空閒的binder_buffer通過成員變量rb_node連入到struct binder_proc中的free_buffers表示的紅黑樹中去，正在使用的binder_buffer通過成員變量rb_node連入到struct binder_proc中的allocated_buffers表示的紅黑樹中去。這樣做當然是爲了方便查詢和維護這塊地址空間了，這一點我們可以從其它的代碼中看到，等遇到的時候我們再分析。

        終於可以回到binder_mmap這個函數來了，首先是對參數作一些健康體檢（sanity check），例如，要映射的內存大小不能超過SIZE_4M，即4M，回到service_manager.c中的main 函數，這裏傳進來的值是128 * 1024個字節，即128K，這個檢查沒有問題。通過健康體檢後，調用get_vm_area函數獲得一個空閒的vm_struct區間，並初始化proc結構體的buffer、user_buffer_offset、pages和buffer_size和成員變量，接着調用binder_update_page_range來爲虛擬地址空間proc->buffer ~ proc->buffer + PAGE_SIZE分配一個空閒的物理頁面，同時這段地址空間使用一個binder_buffer來描述，分別插入到proc->buffers鏈表和proc->free_buffers紅黑樹中去，最後，還初始化了proc結構體的free_async_space、files和vma三個成員變量。

        這裏，我們繼續進入到binder_update_page_range函數中去看一下Binder驅動程序是如何實現把一個物理頁面同時映射到內核空間和進程空間去的：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static int binder_update_page_range(struct binder_proc *proc, int allocate,  
  2.     void *start, void *end, struct vm_area_struct *vma)  
  3. {  
  4.     void *page_addr;  
  5.     unsigned long user_page_addr;  
  6.     struct vm_struct tmp_area;  
  7.     struct page **page;  
  8.     struct mm_struct *mm;  
  9.   
  10.     if (binder_debug_mask & BINDER_DEBUG_BUFFER_ALLOC)  
  11.         printk(KERN_INFO "binder: %d: %s pages %p-%p\n",  
  12.                proc->pid, allocate ? "allocate" : "free", start, end);  
  13.   
  14.     if (end <= start)  
  15.         return 0;  
  16.   
  17.     if (vma)  
  18.         mm = NULL;  
  19.     else  
  20.         mm = get_task_mm(proc->tsk);  
  21.   
  22.     if (mm) {  
  23.         down_write(&mm->mmap_sem);  
  24.         vma = proc->vma;  
  25.     }  
  26.   
  27.     if (allocate == 0)  
  28.         goto free_range;  
  29.   
  30.     if (vma == NULL) {  
  31.         printk(KERN_ERR "binder: %d: binder_alloc_buf failed to "  
  32.                "map pages in userspace, no vma\n", proc->pid);  
  33.         goto err_no_vma;  
  34.     }  
  35.   
  36.     for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) {  
  37.         int ret;  
  38.         struct page **page_array_ptr;  
  39.         page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE];  
  40.   
  41.         BUG_ON(*page);  
  42.         *page = alloc_page(GFP_KERNEL | __GFP_ZERO);  
  43.         if (*page == NULL) {  
  44.             printk(KERN_ERR "binder: %d: binder_alloc_buf failed "  
  45.                    "for page at %p\n", proc->pid, page_addr);  
  46.             goto err_alloc_page_failed;  
  47.         }  
  48.         tmp_area.addr = page_addr;  
  49.         tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */;  
  50.         page_array_ptr = page;  
  51.         ret = map_vm_area(&tmp_area, PAGE_KERNEL, &page_array_ptr);  
  52.         if (ret) {  
  53.             printk(KERN_ERR "binder: %d: binder_alloc_buf failed "  
  54.                    "to map page at %p in kernel\n",  
  55.                    proc->pid, page_addr);  
  56.             goto err_map_kernel_failed;  
  57.         }  
  58.         user_page_addr =  
  59.             (uintptr_t)page_addr + proc->user_buffer_offset;  
  60.         ret = vm_insert_page(vma, user_page_addr, page[0]);  
  61.         if (ret) {  
  62.             printk(KERN_ERR "binder: %d: binder_alloc_buf failed "  
  63.                    "to map page at %lx in userspace\n",  
  64.                    proc->pid, user_page_addr);  
  65.             goto err_vm_insert_page_failed;  
  66.         }  
  67.         /* vm_insert_page does not seem to increment the refcount */  
  68.     }  
  69.     if (mm) {  
  70.         up_write(&mm->mmap_sem);  
  71.         mmput(mm);  
  72.     }  
  73.     return 0;  
  74.   
  75. free_range:  
  76.     for (page_addr = end - PAGE_SIZE; page_addr >= start;  
  77.          page_addr -= PAGE_SIZE) {  
  78.         page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE];  
  79.         if (vma)  
  80.             zap_page_range(vma, (uintptr_t)page_addr +  
  81.                 proc->user_buffer_offset, PAGE_SIZE, NULL);  
  82. err_vm_insert_page_failed:  
  83.         unmap_kernel_range((unsigned long)page_addr, PAGE_SIZE);  
  84. err_map_kernel_failed:  
  85.         __free_page(*page);  
  86.         *page = NULL;  
  87. err_alloc_page_failed:  
  88.         ;  
  89.     }  
  90. err_no_vma:  
  91.     if (mm) {  
  92.         up_write(&mm->mmap_sem);  
  93.         mmput(mm);  
  94.     }  
  95.     return -ENOMEM;  
  96. }  
        這個函數既可以分配物理頁面，也可以用來釋放物理頁面，通過allocate參數來區別，這裏我們只關注分配物理頁面的情況。要分配物理頁面的虛擬地址空間範圍爲(start ~ end)，函數前面的一些檢查邏輯就不看了，直接看中間的for循環：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) {  
  2.     int ret;  
  3.     struct page **page_array_ptr;  
  4.     page = &proc->pages[(page_addr - proc->buffer) / PAGE_SIZE];  
  5.   
  6.     BUG_ON(*page);  
  7.     *page = alloc_page(GFP_KERNEL | __GFP_ZERO);  
  8.     if (*page == NULL) {  
  9.         printk(KERN_ERR "binder: %d: binder_alloc_buf failed "  
  10.                "for page at %p\n", proc->pid, page_addr);  
  11.         goto err_alloc_page_failed;  
  12.     }  
  13.     tmp_area.addr = page_addr;  
  14.     tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */;  
  15.     page_array_ptr = page;  
  16.     ret = map_vm_area(&tmp_area, PAGE_KERNEL, &page_array_ptr);  
  17.     if (ret) {  
  18.         printk(KERN_ERR "binder: %d: binder_alloc_buf failed "  
  19.                "to map page at %p in kernel\n",  
  20.                proc->pid, page_addr);  
  21.         goto err_map_kernel_failed;  
  22.     }  
  23.     user_page_addr =  
  24.         (uintptr_t)page_addr + proc->user_buffer_offset;  
  25.     ret = vm_insert_page(vma, user_page_addr, page[0]);  
  26.     if (ret) {  
  27.         printk(KERN_ERR "binder: %d: binder_alloc_buf failed "  
  28.                "to map page at %lx in userspace\n",  
  29.                proc->pid, user_page_addr);  
  30.         goto err_vm_insert_page_failed;  
  31.     }  
  32.     /* vm_insert_page does not seem to increment the refcount */  
  33. }  
        首先是調用alloc_page來分配一個物理頁面，這個函數返回一個struct page物理頁面描述符，根據這個描述的內容初始化好struct vm_struct tmp_area結構體，然後通過map_vm_area將這個物理頁面插入到tmp_area描述的內核空間去，接着通過page_addr + proc->user_buffer_offset獲得進程虛擬空間地址，並通過vm_insert_page函數將這個物理頁面插入到進程地址空間去，參數vma代表了要插入的進程的地址空間。
       這樣，frameworks/base/cmds/servicemanager/binder.c文件中的binder_open函數就描述完了，回到frameworks/base/cmds/servicemanager/service_manager.c文件中的main函數，下一步就是調用binder_become_context_manager來通知Binder驅動程序自己是Binder機制的上下文管理者，即守護進程。binder_become_context_manager函數位於frameworks/base/cmds/servicemanager/binder.c文件中：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. int binder_become_context_manager(struct binder_state *bs)  
  2. {  
  3.     return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);  
  4. }  
       這裏通過調用ioctl文件操作函數來通知Binder驅動程序自己是守護進程，命令號是BINDER_SET_CONTEXT_MGR，沒有參數。BINDER_SET_CONTEXT_MGR定義爲：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. #define BINDER_SET_CONTEXT_MGR      _IOW('b', 7, int)  
       這樣就進入到Binder驅動程序的binder_ioctl函數，我們只關注BINDER_SET_CONTEXT_MGR命令：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)  
  2. {  
  3.     int ret;  
  4.     struct binder_proc *proc = filp->private_data;  
  5.     struct binder_thread *thread;  
  6.     unsigned int size = _IOC_SIZE(cmd);  
  7.     void __user *ubuf = (void __user *)arg;  
  8.   
  9.     /*printk(KERN_INFO "binder_ioctl: %d:%d %x %lx\n", proc->pid, current->pid, cmd, arg);*/  
  10.   
  11.     ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);  
  12.     if (ret)  
  13.         return ret;  
  14.   
  15.     mutex_lock(&binder_lock);  
  16.     thread = binder_get_thread(proc);  
  17.     if (thread == NULL) {  
  18.         ret = -ENOMEM;  
  19.         goto err;  
  20.     }  
  21.   
  22.     switch (cmd) {  
  23.         ......  
  24.     case BINDER_SET_CONTEXT_MGR:  
  25.         if (binder_context_mgr_node != NULL) {  
  26.             printk(KERN_ERR "binder: BINDER_SET_CONTEXT_MGR already set\n");  
  27.             ret = -EBUSY;  
  28.             goto err;  
  29.         }  
  30.         if (binder_context_mgr_uid != -1) {  
  31.             if (binder_context_mgr_uid != current->cred->euid) {  
  32.                 printk(KERN_ERR "binder: BINDER_SET_"  
  33.                     "CONTEXT_MGR bad uid %d != %d\n",  
  34.                     current->cred->euid,  
  35.                     binder_context_mgr_uid);  
  36.                 ret = -EPERM;  
  37.                 goto err;  
  38.             }  
  39.         } else  
  40.             binder_context_mgr_uid = current->cred->euid;  
  41.         binder_context_mgr_node = binder_new_node(proc, NULL, NULL);  
  42.         if (binder_context_mgr_node == NULL) {  
  43.             ret = -ENOMEM;  
  44.             goto err;  
  45.         }  
  46.         binder_context_mgr_node->local_weak_refs++;  
  47.         binder_context_mgr_node->local_strong_refs++;  
  48.         binder_context_mgr_node->has_strong_ref = 1;  
  49.         binder_context_mgr_node->has_weak_ref = 1;  
  50.         break;  
  51.         ......  
  52.     default:  
  53.         ret = -EINVAL;  
  54.         goto err;  
  55.     }  
  56.     ret = 0;  
  57. err:  
  58.     if (thread)  
  59.         thread->looper &= ~BINDER_LOOPER_STATE_NEED_RETURN;  
  60.     mutex_unlock(&binder_lock);  
  61.     wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);  
  62.     if (ret && ret != -ERESTARTSYS)  
  63.         printk(KERN_INFO "binder: %d:%d ioctl %x %lx returned %d\n", proc->pid, current->pid, cmd, arg, ret);  
  64.     return ret;  
  65. }  
        繼續分析這個函數之前，又要解釋兩個數據結構了，一個是struct binder_thread結構體，顧名思久，它表示一個線程，這裏就是執行binder_become_context_manager函數的線程了。

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. struct binder_thread {  
  2.     struct binder_proc *proc;  
  3.     struct rb_node rb_node;  
  4.     int pid;  
  5.     int looper;  
  6.     struct binder_transaction *transaction_stack;  
  7.     struct list_head todo;  
  8.     uint32_t return_error; /* Write failed, return error code in read buf */  
  9.     uint32_t return_error2; /* Write failed, return error code in read */  
  10.         /* buffer. Used when sending a reply to a dead process that */  
  11.         /* we are also waiting on */  
  12.     wait_queue_head_t wait;  
  13.     struct binder_stats stats;  
  14. };  
       proc表示這個線程所屬的進程。struct binder_proc有一個成員變量threads，它的類型是rb_root，它表示一查紅黑樹，把屬於這個進程的所有線程都組織起來，struct binder_thread的成員變量rb_node就是用來鏈入這棵紅黑樹的節點了。looper成員變量表示線程的狀態，它可以取下面這幾個值：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. enum {  
  2.     BINDER_LOOPER_STATE_REGISTERED  = 0x01,  
  3.     BINDER_LOOPER_STATE_ENTERED     = 0x02,  
  4.     BINDER_LOOPER_STATE_EXITED      = 0x04,  
  5.     BINDER_LOOPER_STATE_INVALID     = 0x08,  
  6.     BINDER_LOOPER_STATE_WAITING     = 0x10,  
  7.     BINDER_LOOPER_STATE_NEED_RETURN = 0x20  
  8. };  
        其餘的成員變量，transaction_stack表示線程正在處理的事務，todo表示發往該線程的數據列表，return_error和return_error2表示操作結果返回碼，wait用來阻塞線程等待某個事件的發生，stats用來保存一些統計信息。這些成員變量遇到的時候再分析它們的作用。

        另外一個數據結構是struct binder_node，它表示一個binder實體：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. struct binder_node {  
  2.     int debug_id;  
  3.     struct binder_work work;  
  4.     union {  
  5.         struct rb_node rb_node;  
  6.         struct hlist_node dead_node;  
  7.     };  
  8.     struct binder_proc *proc;  
  9.     struct hlist_head refs;  
  10.     int internal_strong_refs;  
  11.     int local_weak_refs;  
  12.     int local_strong_refs;  
  13.     void __user *ptr;  
  14.     void __user *cookie;  
  15.     unsigned has_strong_ref : 1;  
  16.     unsigned pending_strong_ref : 1;  
  17.     unsigned has_weak_ref : 1;  
  18.     unsigned pending_weak_ref : 1;  
  19.     unsigned has_async_transaction : 1;  
  20.     unsigned accept_fds : 1;  
  21.     int min_priority : 8;  
  22.     struct list_head async_todo;  
  23. };  
        rb_node和dead_node組成一個聯合體。 如果這個Binder實體還在正常使用，則使用rb_node來連入proc->nodes所表示的紅黑樹的節點，這棵紅黑樹用來組織屬於這個進程的所有Binder實體；如果這個Binder實體所屬的進程已經銷燬，而這個Binder實體又被其它進程所引用，則這個Binder實體通過dead_node進入到一個哈希表中去存放。proc成員變量就是表示這個Binder實例所屬於進程了。refs成員變量把所有引用了該Binder實體的Binder引用連接起來構成一個鏈表。internal_strong_refs、local_weak_refs和local_strong_refs表示這個Binder實體的引用計數。ptr和cookie成員變量分別表示這個Binder實體在用戶空間的地址以及附加數據。其餘的成員變量就不描述了，遇到的時候再分析。

        現在回到binder_ioctl函數中，首先是通過filp->private_data獲得proc變量，這裏binder_mmap函數是一樣的。接着通過binder_get_thread函數獲得線程信息，我們來看一下這個函數：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static struct binder_thread *binder_get_thread(struct binder_proc *proc)  
  2. {  
  3.     struct binder_thread *thread = NULL;  
  4.     struct rb_node *parent = NULL;  
  5.     struct rb_node **p = &proc->threads.rb_node;  
  6.   
  7.     while (*p) {  
  8.         parent = *p;  
  9.         thread = rb_entry(parent, struct binder_thread, rb_node);  
  10.   
  11.         if (current->pid < thread->pid)  
  12.             p = &(*p)->rb_left;  
  13.         else if (current->pid > thread->pid)  
  14.             p = &(*p)->rb_right;  
  15.         else  
  16.             break;  
  17.     }  
  18.     if (*p == NULL) {  
  19.         thread = kzalloc(sizeof(*thread), GFP_KERNEL);  
  20.         if (thread == NULL)  
  21.             return NULL;  
  22.         binder_stats.obj_created[BINDER_STAT_THREAD]++;  
  23.         thread->proc = proc;  
  24.         thread->pid = current->pid;  
  25.         init_waitqueue_head(&thread->wait);  
  26.         INIT_LIST_HEAD(&thread->todo);  
  27.         rb_link_node(&thread->rb_node, parent, p);  
  28.         rb_insert_color(&thread->rb_node, &proc->threads);  
  29.         thread->looper |= BINDER_LOOPER_STATE_NEED_RETURN;  
  30.         thread->return_error = BR_OK;  
  31.         thread->return_error2 = BR_OK;  
  32.     }  
  33.     return thread;  
  34. }  
        這裏把當前線程current的pid作爲鍵值，在進程proc->threads表示的紅黑樹中進行查找，看是否已經爲當前線程創建過了binder_thread信息。在這個場景下，由於當前線程是第一次進到這裏，所以肯定找不到，即*p == NULL成立，於是，就爲當前線程創建一個線程上下文信息結構體binder_thread，並初始化相應成員變量，並插入到proc->threads所表示的紅黑樹中去，下次要使用時就可以從proc中找到了。注意，這裏的thread->looper = BINDER_LOOPER_STATE_NEED_RETURN。

        回到binder_ioctl函數，繼續往下面，有兩個全局變量binder_context_mgr_node和binder_context_mgr_uid，它定義如下：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static struct binder_node *binder_context_mgr_node;  
  2. static uid_t binder_context_mgr_uid = -1;  
        binder_context_mgr_node用來表示Service Manager實體，binder_context_mgr_uid表示Service Manager守護進程的uid。在這個場景下，由於當前線程是第一次進到這裏，所以binder_context_mgr_node爲NULL，binder_context_mgr_uid爲-1，於是初始化binder_context_mgr_uid爲current->cred->euid，這樣，當前線程就成爲Binder機制的守護進程了，並且通過binder_new_node爲Service Manager創建Binder實體：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static struct binder_node *  
  2. binder_new_node(struct binder_proc *proc, void __user *ptr, void __user *cookie)  
  3. {  
  4.     struct rb_node **p = &proc->nodes.rb_node;  
  5.     struct rb_node *parent = NULL;  
  6.     struct binder_node *node;  
  7.   
  8.     while (*p) {  
  9.         parent = *p;  
  10.         node = rb_entry(parent, struct binder_node, rb_node);  
  11.   
  12.         if (ptr < node->ptr)  
  13.             p = &(*p)->rb_left;  
  14.         else if (ptr > node->ptr)  
  15.             p = &(*p)->rb_right;  
  16.         else  
  17.             return NULL;  
  18.     }  
  19.   
  20.     node = kzalloc(sizeof(*node), GFP_KERNEL);  
  21.     if (node == NULL)  
  22.         return NULL;  
  23.     binder_stats.obj_created[BINDER_STAT_NODE]++;  
  24.     rb_link_node(&node->rb_node, parent, p);  
  25.     rb_insert_color(&node->rb_node, &proc->nodes);  
  26.     node->debug_id = ++binder_last_id;  
  27.     node->proc = proc;  
  28.     node->ptr = ptr;  
  29.     node->cookie = cookie;  
  30.     node->work.type = BINDER_WORK_NODE;  
  31.     INIT_LIST_HEAD(&node->work.entry);  
  32.     INIT_LIST_HEAD(&node->async_todo);  
  33.     if (binder_debug_mask & BINDER_DEBUG_INTERNAL_REFS)  
  34.         printk(KERN_INFO "binder: %d:%d node %d u%p c%p created\n",  
  35.                proc->pid, current->pid, node->debug_id,  
  36.                node->ptr, node->cookie);  
  37.     return node;  
  38. }  
        注意，這裏傳進來的ptr和cookie均爲NULL。函數首先檢查proc->nodes紅黑樹中是否已經存在以ptr爲鍵值的node，如果已經存在，就返回NULL。在這個場景下，由於當前線程是第一次進入到這裏，所以肯定不存在，於是就新建了一個ptr爲NULL的binder_node，並且初始化其它成員變量，並插入到proc->nodes紅黑樹中去。

        binder_new_node返回到binder_ioctl函數後，就把新建的binder_node指針保存在binder_context_mgr_node中了，緊接着，又初始化了binder_context_mgr_node的引用計數值。

        這樣，BINDER_SET_CONTEXT_MGR命令就執行完畢了，binder_ioctl函數返回之前，執行了下面語句：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. if (thread)  
  2.         thread->looper &= ~BINDER_LOOPER_STATE_NEED_RETURN;  

       回憶上面執行binder_get_thread時，thread->looper = BINDER_LOOPER_STATE_NEED_RETURN，執行了這條語句後，thread->looper = 0。

       回到frameworks/base/cmds/servicemanager/service_manager.c文件中的main函數，下一步就是調用binder_loop函數進入循環，等待Client來請求了。binder_loop函數定義在frameworks/base/cmds/servicemanager/binder.c文件中：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. void binder_loop(struct binder_state *bs, binder_handler func)  
  2. {  
  3.     int res;  
  4.     struct binder_write_read bwr;  
  5.     unsigned readbuf[32];  
  6.   
  7.     bwr.write_size = 0;  
  8.     bwr.write_consumed = 0;  
  9.     bwr.write_buffer = 0;  
  10.       
  11.     readbuf[0] = BC_ENTER_LOOPER;  
  12.     binder_write(bs, readbuf, sizeof(unsigned));  
  13.   
  14.     for (;;) {  
  15.         bwr.read_size = sizeof(readbuf);  
  16.         bwr.read_consumed = 0;  
  17.         bwr.read_buffer = (unsigned) readbuf;  
  18.   
  19.         res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);  
  20.   
  21.         if (res < 0) {  
  22.             LOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));  
  23.             break;  
  24.         }  
  25.   
  26.         res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);  
  27.         if (res == 0) {  
  28.             LOGE("binder_loop: unexpected reply?!\n");  
  29.             break;  
  30.         }  
  31.         if (res < 0) {  
  32.             LOGE("binder_loop: io error %d %s\n", res, strerror(errno));  
  33.             break;  
  34.         }  
  35.     }  
  36. }  
       首先是通過binder_write函數執行BC_ENTER_LOOPER命令告訴Binder驅動程序， Service Manager要進入循環了。

       這裏又要介紹一下設備文件/dev/binder文件操作函數ioctl的操作碼BINDER_WRITE_READ了，首先看定義：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. #define BINDER_WRITE_READ           _IOWR('b', 1, struct binder_write_read)  
       這個io操作碼有一個參數，形式爲struct binder_write_read：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. struct binder_write_read {  
  2.     signed long write_size; /* bytes to write */  
  3.     signed long write_consumed; /* bytes consumed by driver */  
  4.     unsigned long   write_buffer;  
  5.     signed long read_size;  /* bytes to read */  
  6.     signed long read_consumed;  /* bytes consumed by driver */  
  7.     unsigned long   read_buffer;  
  8. };  
      這裏順便說一下，用戶空間程序和Binder驅動程序交互大多數都是通過BINDER_WRITE_READ命令的，write_bufffer和read_buffer所指向的數據結構還指定了具體要執行的操作，write_bufffer和read_buffer所指向的結構體是struct binder_transaction_data：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. struct binder_transaction_data {  
  2.     /* The first two are only used for bcTRANSACTION and brTRANSACTION, 
  3.      * identifying the target and contents of the transaction. 
  4.      */  
  5.     union {  
  6.         size_t  handle; /* target descriptor of command transaction */  
  7.         void    *ptr;   /* target descriptor of return transaction */  
  8.     } target;  
  9.     void        *cookie;    /* target object cookie */  
  10.     unsigned int    code;       /* transaction command */  
  11.   
  12.     /* General information about the transaction. */  
  13.     unsigned int    flags;  
  14.     pid_t       sender_pid;  
  15.     uid_t       sender_euid;  
  16.     size_t      data_size;  /* number of bytes of data */  
  17.     size_t      offsets_size;   /* number of bytes of offsets */  
  18.   
  19.     /* If this transaction is inline, the data immediately 
  20.      * follows here; otherwise, it ends with a pointer to 
  21.      * the data buffer. 
  22.      */  
  23.     union {  
  24.         struct {  
  25.             /* transaction data */  
  26.             const void  *buffer;  
  27.             /* offsets from buffer to flat_binder_object structs */  
  28.             const void  *offsets;  
  29.         } ptr;  
  30.         uint8_t buf[8];  
  31.     } data;  
  32. };  
       有一個聯合體target，當這個BINDER_WRITE_READ命令的目標對象是本地Binder實體時，就使用ptr來表示這個對象在本進程中的地址，否則就使用handle來表示這個Binder實體的引用。只有目標對象是Binder實體時，cookie成員變量纔有意義，表示一些附加數據，由Binder實體來解釋這個個附加數據。code表示要對目標對象請求的命令代碼，有很多請求代碼，這裏就不列舉了，在這個場景中，就是BC_ENTER_LOOPER了，用來告訴Binder驅動程序， Service Manager要進入循環了。其餘的請求命令代碼可以參考kernel/common/drivers/staging/android/binder.h文件中定義的兩個枚舉類型BinderDriverReturnProtocol和BinderDriverCommandProtocol。

       flags成員變量表示事務標誌：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. enum transaction_flags {  
  2.     TF_ONE_WAY  = 0x01, /* this is a one-way call: async, no return */  
  3.     TF_ROOT_OBJECT  = 0x04, /* contents are the component's root object */  
  4.     TF_STATUS_CODE  = 0x08, /* contents are a 32-bit status code */  
  5.     TF_ACCEPT_FDS   = 0x10, /* allow replies with file descriptors */  
  6. };  
      每一個標誌位所表示的意義看註釋就行了，遇到時再具體分析。

      sender_pid和sender_euid表示發送者進程的pid和euid。

      data_size表示data.buffer緩衝區的大小，offsets_size表示data.offsets緩衝區的大小。這裏需要解釋一下data成員變量，命令的真正要傳輸的數據就保存在data.buffer緩衝區中，前面的一成員變量都是一些用來描述數據的特徵的。data.buffer所表示的緩衝區數據分爲兩類，一類是普通數據，Binder驅動程序不關心，一類是Binder實體或者Binder引用，這需要Binder驅動程序介入處理。爲什麼呢？想想，如果一個進程A傳遞了一個Binder實體或Binder引用給進程B，那麼，Binder驅動程序就需要介入維護這個Binder實體或者引用的引用計數，防止B進程還在使用這個Binder實體時，A卻銷燬這個實體，這樣的話，B進程就會crash了。所以在傳輸數據時，如果數據中含有Binder實體和Binder引和，就需要告訴Binder驅動程序它們的具體位置，以便Binder驅動程序能夠去維護它們。data.offsets的作用就在這裏了，它指定在data.buffer緩衝區中，所有Binder實體或者引用的偏移位置。每一個Binder實體或者引用，通過struct flat_binder_object 來表示：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. /* 
  2.  * This is the flattened representation of a Binder object for transfer 
  3.  * between processes.  The 'offsets' supplied as part of a binder transaction 
  4.  * contains offsets into the data where these structures occur.  The Binder 
  5.  * driver takes care of re-writing the structure type and data as it moves 
  6.  * between processes. 
  7.  */  
  8. struct flat_binder_object {  
  9.     /* 8 bytes for large_flat_header. */  
  10.     unsigned long       type;  
  11.     unsigned long       flags;  
  12.   
  13.     /* 8 bytes of data. */  
  14.     union {  
  15.         void        *binder;    /* local object */  
  16.         signed long handle;     /* remote object */  
  17.     };  
  18.   
  19.     /* extra data associated with local object */  
  20.     void            *cookie;  
  21. };  
       type表示Binder對象的類型，它取值如下所示：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. enum {  
  2.     BINDER_TYPE_BINDER  = B_PACK_CHARS('s', 'b', '*', B_TYPE_LARGE),  
  3.     BINDER_TYPE_WEAK_BINDER = B_PACK_CHARS('w', 'b', '*', B_TYPE_LARGE),  
  4.     BINDER_TYPE_HANDLE  = B_PACK_CHARS('s', 'h', '*', B_TYPE_LARGE),  
  5.     BINDER_TYPE_WEAK_HANDLE = B_PACK_CHARS('w', 'h', '*', B_TYPE_LARGE),  
  6.     BINDER_TYPE_FD      = B_PACK_CHARS('f', 'd', '*', B_TYPE_LARGE),  
  7. };  
       flags表示Binder對象的標誌，該域只對第一次傳遞Binder實體時有效，因爲此刻驅動需要在內核中創建相應的實體節點，有些參數需要從該域取出。

       type和flags的具體意義可以參考Android Binder設計與實現一文。

       最後，binder表示這是一個Binder實體，handle表示這是一個Binder引用，當這是一個Binder實體時，cookie纔有意義，表示附加數據，由進程自己解釋。

       數據結構分析完了，回到binder_loop函數中，首先是執行BC_ENTER_LOOPER命令：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. readbuf[0] = BC_ENTER_LOOPER;  
  2. binder_write(bs, readbuf, sizeof(unsigned));  
        進入到binder_write函數中：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. int binder_write(struct binder_state *bs, void *data, unsigned len)  
  2. {  
  3.     struct binder_write_read bwr;  
  4.     int res;  
  5.     bwr.write_size = len;  
  6.     bwr.write_consumed = 0;  
  7.     bwr.write_buffer = (unsigned) data;  
  8.     bwr.read_size = 0;  
  9.     bwr.read_consumed = 0;  
  10.     bwr.read_buffer = 0;  
  11.     res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);  
  12.     if (res < 0) {  
  13.         fprintf(stderr,"binder_write: ioctl failed (%s)\n",  
  14.                 strerror(errno));  
  15.     }  
  16.     return res;  
  17. }  
        注意這裏的binder_write_read變量bwr，write_size大小爲4，表示write_buffer緩衝區大小爲4，它的內容是一個BC_ENTER_LOOPER命令協議號，read_buffer爲空。接着又是調用ioctl函數進入到Binder驅動程序的binder_ioctl函數，這裏我們也只是關注BC_ENTER_LOOPER相關的邏輯：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)  
  2. {  
  3.     int ret;  
  4.     struct binder_proc *proc = filp->private_data;  
  5.     struct binder_thread *thread;  
  6.     unsigned int size = _IOC_SIZE(cmd);  
  7.     void __user *ubuf = (void __user *)arg;  
  8.   
  9.     /*printk(KERN_INFO "binder_ioctl: %d:%d %x %lx\n", proc->pid, current->pid, cmd, arg);*/  
  10.   
  11.     ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);  
  12.     if (ret)  
  13.         return ret;  
  14.   
  15.     mutex_lock(&binder_lock);  
  16.     thread = binder_get_thread(proc);  
  17.     if (thread == NULL) {  
  18.         ret = -ENOMEM;  
  19.         goto err;  
  20.     }  
  21.   
  22.     switch (cmd) {  
  23.     case BINDER_WRITE_READ: {  
  24.         struct binder_write_read bwr;  
  25.         if (size != sizeof(struct binder_write_read)) {  
  26.             ret = -EINVAL;  
  27.             goto err;  
  28.         }  
  29.         if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {  
  30.             ret = -EFAULT;  
  31.             goto err;  
  32.         }  
  33.         if (binder_debug_mask & BINDER_DEBUG_READ_WRITE)  
  34.             printk(KERN_INFO "binder: %d:%d write %ld at %08lx, read %ld at %08lx\n",  
  35.             proc->pid, thread->pid, bwr.write_size, bwr.write_buffer, bwr.read_size, bwr.read_buffer);  
  36.         if (bwr.write_size > 0) {  
  37.             ret = binder_thread_write(proc, thread, (void __user *)bwr.write_buffer, bwr.write_size, &bwr.write_consumed);  
  38.             if (ret < 0) {  
  39.                 bwr.read_consumed = 0;  
  40.                 if (copy_to_user(ubuf, &bwr, sizeof(bwr)))  
  41.                     ret = -EFAULT;  
  42.                 goto err;  
  43.             }  
  44.         }  
  45.         if (bwr.read_size > 0) {  
  46.             ret = binder_thread_read(proc, thread, (void __user *)bwr.read_buffer, bwr.read_size, &bwr.read_consumed, filp->f_flags & O_NONBLOCK);  
  47.             if (!list_empty(&proc->todo))  
  48.                 wake_up_interruptible(&proc->wait);  
  49.             if (ret < 0) {  
  50.                 if (copy_to_user(ubuf, &bwr, sizeof(bwr)))  
  51.                     ret = -EFAULT;  
  52.                 goto err;  
  53.             }  
  54.         }  
  55.         if (binder_debug_mask & BINDER_DEBUG_READ_WRITE)  
  56.             printk(KERN_INFO "binder: %d:%d wrote %ld of %ld, read return %ld of %ld\n",  
  57.             proc->pid, thread->pid, bwr.write_consumed, bwr.write_size, bwr.read_consumed, bwr.read_size);  
  58.         if (copy_to_user(ubuf, &bwr, sizeof(bwr))) {  
  59.             ret = -EFAULT;  
  60.             goto err;  
  61.         }  
  62.         break;  
  63.                             }  
  64.     ......  
  65.     default:  
  66.         ret = -EINVAL;  
  67.         goto err;  
  68.     }  
  69.     ret = 0;  
  70. err:  
  71.     if (thread)  
  72.         thread->looper &= ~BINDER_LOOPER_STATE_NEED_RETURN;  
  73.     mutex_unlock(&binder_lock);  
  74.     wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);  
  75.     if (ret && ret != -ERESTARTSYS)  
  76.         printk(KERN_INFO "binder: %d:%d ioctl %x %lx returned %d\n", proc->pid, current->pid, cmd, arg, ret);  
  77.     return ret;  
  78. }  
       函數前面的代碼就不解釋了，同前面調用binder_become_context_manager是一樣的，只不過這裏調用binder_get_thread函數獲取binder_thread，就能從proc中直接找到了，不需要創建一個新的。

       首先是通過copy_from_user(&bwr, ubuf, sizeof(bwr))語句把用戶傳遞進來的參數轉換成struct binder_write_read結構體，並保存在本地變量bwr中，這裏可以看出bwr.write_size等於4，於是進入binder_thread_write函數，這裏我們只關注BC_ENTER_LOOPER相關的代碼：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. int  
  2. binder_thread_write(struct binder_proc *proc, struct binder_thread *thread,  
  3.                     void __user *buffer, int size, signed long *consumed)  
  4. {  
  5.     uint32_t cmd;  
  6.     void __user *ptr = buffer + *consumed;  
  7.     void __user *end = buffer + size;  
  8.   
  9.     while (ptr < end && thread->return_error == BR_OK) {  
  10.         if (get_user(cmd, (uint32_t __user *)ptr))  
  11.             return -EFAULT;  
  12.         ptr += sizeof(uint32_t);  
  13.         if (_IOC_NR(cmd) < ARRAY_SIZE(binder_stats.bc)) {  
  14.             binder_stats.bc[_IOC_NR(cmd)]++;  
  15.             proc->stats.bc[_IOC_NR(cmd)]++;  
  16.             thread->stats.bc[_IOC_NR(cmd)]++;  
  17.         }  
  18.         switch (cmd) {  
  19.         ......  
  20.         case BC_ENTER_LOOPER:  
  21.             if (binder_debug_mask & BINDER_DEBUG_THREADS)  
  22.                 printk(KERN_INFO "binder: %d:%d BC_ENTER_LOOPER\n",  
  23.                 proc->pid, thread->pid);  
  24.             if (thread->looper & BINDER_LOOPER_STATE_REGISTERED) {  
  25.                 thread->looper |= BINDER_LOOPER_STATE_INVALID;  
  26.                 binder_user_error("binder: %d:%d ERROR:"  
  27.                     " BC_ENTER_LOOPER called after "  
  28.                     "BC_REGISTER_LOOPER\n",  
  29.                     proc->pid, thread->pid);  
  30.             }  
  31.             thread->looper |= BINDER_LOOPER_STATE_ENTERED;  
  32.             break;  
  33.         ......  
  34.         default:  
  35.             printk(KERN_ERR "binder: %d:%d unknown command %d\n", proc->pid, thread->pid, cmd);  
  36.             return -EINVAL;  
  37.         }  
  38.         *consumed = ptr - buffer;  
  39.     }  
  40.     return 0;  
  41. }  
       回憶前面執行binder_become_context_manager到binder_ioctl時，調用binder_get_thread函數創建的thread->looper值爲0，所以這裏執行完BC_ENTER_LOOPER時，thread->looper值就變爲BINDER_LOOPER_STATE_ENTERED了，表明當前線程進入循環狀態了。

       回到binder_ioctl函數，由於bwr.read_size == 0，binder_thread_read函數就不會被執行了，這樣，binder_ioctl的任務就完成了。

       回到binder_loop函數，進入for循環：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. for (;;) {  
  2.     bwr.read_size = sizeof(readbuf);  
  3.     bwr.read_consumed = 0;  
  4.     bwr.read_buffer = (unsigned) readbuf;  
  5.   
  6.     res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);  
  7.   
  8.     if (res < 0) {  
  9.         LOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));  
  10.         break;  
  11.     }  
  12.   
  13.     res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func);  
  14.     if (res == 0) {  
  15.         LOGE("binder_loop: unexpected reply?!\n");  
  16.         break;  
  17.     }  
  18.     if (res < 0) {  
  19.         LOGE("binder_loop: io error %d %s\n", res, strerror(errno));  
  20.         break;  
  21.     }  
  22. }  
        又是執行一個ioctl命令，注意，這裏的bwr參數各個成員的值：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. bwr.write_size = 0;  
  2. bwr.write_consumed = 0;  
  3. bwr.write_buffer = 0;  
  4. readbuf[0] = BC_ENTER_LOOPER;  
  5. bwr.read_size = sizeof(readbuf);  
  6. bwr.read_consumed = 0;  
  7. bwr.read_buffer = (unsigned) readbuf;  
        再次進入到binder_ioctl函數：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)  
  2. {  
  3.     int ret;  
  4.     struct binder_proc *proc = filp->private_data;  
  5.     struct binder_thread *thread;  
  6.     unsigned int size = _IOC_SIZE(cmd);  
  7.     void __user *ubuf = (void __user *)arg;  
  8.   
  9.     /*printk(KERN_INFO "binder_ioctl: %d:%d %x %lx\n", proc->pid, current->pid, cmd, arg);*/  
  10.   
  11.     ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);  
  12.     if (ret)  
  13.         return ret;  
  14.   
  15.     mutex_lock(&binder_lock);  
  16.     thread = binder_get_thread(proc);  
  17.     if (thread == NULL) {  
  18.         ret = -ENOMEM;  
  19.         goto err;  
  20.     }  
  21.   
  22.     switch (cmd) {  
  23.     case BINDER_WRITE_READ: {  
  24.         struct binder_write_read bwr;  
  25.         if (size != sizeof(struct binder_write_read)) {  
  26.             ret = -EINVAL;  
  27.             goto err;  
  28.         }  
  29.         if (copy_from_user(&bwr, ubuf, sizeof(bwr))) {  
  30.             ret = -EFAULT;  
  31.             goto err;  
  32.         }  
  33.         if (binder_debug_mask & BINDER_DEBUG_READ_WRITE)  
  34.             printk(KERN_INFO "binder: %d:%d write %ld at %08lx, read %ld at %08lx\n",  
  35.             proc->pid, thread->pid, bwr.write_size, bwr.write_buffer, bwr.read_size, bwr.read_buffer);  
  36.         if (bwr.write_size > 0) {  
  37.             ret = binder_thread_write(proc, thread, (void __user *)bwr.write_buffer, bwr.write_size, &bwr.write_consumed);  
  38.             if (ret < 0) {  
  39.                 bwr.read_consumed = 0;  
  40.                 if (copy_to_user(ubuf, &bwr, sizeof(bwr)))  
  41.                     ret = -EFAULT;  
  42.                 goto err;  
  43.             }  
  44.         }  
  45.         if (bwr.read_size > 0) {  
  46.             ret = binder_thread_read(proc, thread, (void __user *)bwr.read_buffer, bwr.read_size, &bwr.read_consumed, filp->f_flags & O_NONBLOCK);  
  47.             if (!list_empty(&proc->todo))  
  48.                 wake_up_interruptible(&proc->wait);  
  49.             if (ret < 0) {  
  50.                 if (copy_to_user(ubuf, &bwr, sizeof(bwr)))  
  51.                     ret = -EFAULT;  
  52.                 goto err;  
  53.             }  
  54.         }  
  55.         if (binder_debug_mask & BINDER_DEBUG_READ_WRITE)  
  56.             printk(KERN_INFO "binder: %d:%d wrote %ld of %ld, read return %ld of %ld\n",  
  57.             proc->pid, thread->pid, bwr.write_consumed, bwr.write_size, bwr.read_consumed, bwr.read_size);  
  58.         if (copy_to_user(ubuf, &bwr, sizeof(bwr))) {  
  59.             ret = -EFAULT;  
  60.             goto err;  
  61.         }  
  62.         break;  
  63.                             }  
  64.     ......  
  65.     default:  
  66.         ret = -EINVAL;  
  67.         goto err;  
  68.     }  
  69.     ret = 0;  
  70. err:  
  71.     if (thread)  
  72.         thread->looper &= ~BINDER_LOOPER_STATE_NEED_RETURN;  
  73.     mutex_unlock(&binder_lock);  
  74.     wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);  
  75.     if (ret && ret != -ERESTARTSYS)  
  76.         printk(KERN_INFO "binder: %d:%d ioctl %x %lx returned %d\n", proc->pid, current->pid, cmd, arg, ret);  
  77.     return ret;  
  78. }  
         這次，bwr.write_size等於0，於是不會執行binder_thread_write函數，bwr.read_size等於32，於是進入到binder_thread_read函數：

[cpp] view plain copy
 在CODE上查看代碼片派生到我的代碼片
  1. static int  
  2. binder_thread_read(struct binder_proc *proc, struct binder_thread *thread,  
  3.                    void  __user *buffer, int size, signed long *consumed, int non_block)  
  4. {  
  5.     void __user *ptr = buffer + *consumed;  
  6.     void __user *end = buffer + size;  
  7.   
  8.     int ret = 0;  
  9.     int wait_for_proc_work;  
  10.   
  11.     if (*consumed == 0) {  
  12.         if (put_user(BR_NOOP, (uint32_t __user *)ptr))  
  13.             return -EFAULT;  
  14.         ptr += sizeof(uint32_t);  
  15.     }  
  16.   
  17. retry:  
  18.     wait_for_proc_work = thread->transaction_stack == NULL && list_empty(&thread->todo);  
  19.   
  20.     if (thread->return_error != BR_OK && ptr < end) {  
  21.         if (thread->return_error2 != BR_OK) {  
  22.             if (put_user(thread->return_error2, (uint32_t __user *)ptr))  
  23.                 return -EFAULT;  
  24.             ptr += sizeof(uint32_t);  
  25.             if (ptr == end)  
  26.                 goto done;  
  27.             thread->return_error2 = BR_OK;  
  28.         }  
  29.         if (put_user(thread->return_error, (uint32_t __user *)ptr))  
  30.             return -EFAULT;  
  31.         ptr += sizeof(uint32_t);  
  32.         thread->return_error = BR_OK;  
  33.         goto done;  
  34.     }  
  35.   
  36.   
  37.     thread->looper |= BINDER_LOOPER_STATE_WAITING;  
  38.     if (wait_for_proc_work)  
  39.         proc->ready_threads++;  
  40.     mutex_unlock(&binder_lock);  
  41.     if (wait_for_proc_work) {  
  42.         if (!(thread->looper & (BINDER_LOOPER_STATE_REGISTERED |  
  43.             BINDER_LOOPER_STATE_ENTERED))) {  
  44.                 binder_user_error("binder: %d:%d ERROR: Thread waiting "  
  45.                     "for process work before calling BC_REGISTER_"  
  46.                     "LOOPER or BC_ENTER_LOOPER (state %x)\n",  
  47.                     proc->pid, thread->pid, thread->looper);  
  48.                 wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);  
  49.         }  
  50.         binder_set_nice(proc->default_priority);  
  51.         if (non_block) {  
  52.             if (!binder_has_proc_work(proc, thread))  
  53.                 ret = -EAGAIN;  
  54.         } else  
  55.             ret = wait_event_interruptible_exclusive(proc->wait, binder_has_proc_work(proc, thread));  
  56.     } else {  
  57.         if (non_block) {  
  58.             if (!binder_has_thread_work(thread))  
  59.                 ret = -EAGAIN;  
  60.         } else  
  61.             ret = wait_event_interruptible(thread->wait, binder_has_thread_work(thread));  
  62.     }  
  63.         .......  
  64. }  
         傳入的參數*consumed == 0，於是寫入一個值BR_NOOP到參數ptr指向的緩衝區中去，即用戶傳進來的bwr.read_buffer緩衝區。這時候，thread->transaction_stack == NULL，並且thread->todo列表也是空的，這表示當前線程沒有事務需要處理，於是wait_for_proc_work爲true，表示要去查看proc是否有未處理的事務。當前thread->return_error == BR_OK，這是前面創建binder_thread時初始化設置的。於是繼續往下執行，設置thread的狀態爲BINDER_LOOPER_STATE_WAITING，表示線程處於等待狀態。調用binder_set_nice函數設置當前線程的優先級別爲proc->default_priority，這是因爲thread要去處理屬於proc的事務，因此要將此thread的優先級別設置和proc一樣。在這個場景中，proc也沒有事務處理，即binder_has_proc_work(proc, thread)爲false。如果文件打開模式爲非阻塞模式，即non_block爲true，那麼函數就直接返回-EAGAIN，要求用戶重新執行ioctl；否則的話，就通過當前線程就通過wait_event_interruptible_exclusive函數進入休眠狀態，等待請求到來再喚醒了。

        至此，我們就從源代碼一步一步地分析完Service Manager是如何成爲Android進程間通信（IPC）機制Binder守護進程的了。總結一下，Service Manager是成爲Android進程間通信（IPC）機制Binder守護進程的過程是這樣的：

        1. 打開/dev/binder文件：open("/dev/binder", O_RDWR);

        2. 建立128K內存映射：mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);

        3. 通知Binder驅動程序它是守護進程：binder_become_context_manager(bs);

        4. 進入循環等待請求的到來：binder_loop(bs, svcmgr_handler);

        在這個過程中，在Binder驅動程序中建立了一個struct binder_proc結構、一個struct  binder_thread結構和一個struct binder_node結構，這樣，Service Manager就在Android系統的進程間通信機制Binder擔負起守護進程的職責了。


zzc901205
發佈了18 篇原創文章 · 獲贊 2 · 訪問量 3萬+
私信 關注
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

Android筆記02-真機調式

1、手機打開開發者，並且usb連接電腦 2、打開sdk manager，安裝google usb driver 3、打開設備管理器，更新驅動程序，驅動程序目錄E:\android_sdk\extras\google\usb_driver

原創 2023-10-31 09:11:15

完美解決 Android 滑動衝突！

處理自定義 View 中的滑動衝突 對於大多數 Android 開發來說，處理滑動衝突好像很難，但實戰一下又發現，好像也挺簡單，因爲這個實際上是有套路可循的。基本就兩種方案：外部攔截法 && 內部攔截法。 2.1 外部攔截法 所謂外部攔截法

原創 2023-10-10 02:19:38

Android C++系列：Linux線程（一）概念

{"type":"doc","content":[{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"1. 什麼是線程",

轻口味 2021-12-08 11:33:58

Android無障礙體驗與開發

有着不同無障礙需求的用戶看到或者聽到的Android應用界面也是一種完全不同的交互體驗，使用Google開源的“無障礙體驗”項目來從用戶的視角親身體驗無障礙適配對用戶體驗的影響。在本次專題演講中，你也可以瞭解Google最新發布在Andro

王莹 2021-11-26 09:58:53

Android Studio 的更新

在本次專題演講中，將介紹 Android Studio 的一些新開發工具和功能的最新動態及其演示版，還會示範如何在您的應用開發流程中集成這些工具。 直達 Google 開發者在線課程，收穫 Android 技術乾貨 https://deve

王莹 2021-11-25 10:58:57

拒絕卡頓，揭祕盒馬鮮生 APP Android 短視頻秒播優化方案

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image"

阿里巴巴移动技术 2021-11-24 10:23:56

Android 遊戲開發和結算服務的新特性

Android 遊戲開發工具包 (AGDK) 是一套工具和應用組件，可幫助您開發、優化和發佈優質的 Android 遊戲。 Google Play 結算系統是一項可讓您在 Android 應用中銷售數字產品和內容的服務。 在本次專題演講中，

王莹 2021-11-24 09:58:54

Android TV 與 Google TV 的新特性

在本次專題演講中，我們將向開發者介紹Android TV以及Google TV的新功能和用戶體驗。 直達 Google 開發者在線課程，收穫 Android 技術乾貨 https://developers.google.cn/learn/p

王莹 2021-11-24 09:53:53

Android 12L-針對大屏設備的新特性

Android 大屏設備及摺疊屏設備越來越受到用戶的青睞。在本次專題演講中，我們會向大家介紹 Android 平臺新增的對於大屏應用開發的支持，包括新的 API 和開發庫，以及更新的開發人員指南。 直達 Google 開發者在線課程，收穫

王莹 2021-11-24 09:53:53

Android C++系列：Linux文件IO操作(一)

{"type":"doc","content":[{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"1.1 C標準函數與

轻口味 2021-11-23 18:23:51

Android C++系列：JNI調用時的異常處理

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"typ

轻口味 2021-11-19 10:03:53

2021 Google 開發者大會一覽，同步Android、TensorFlow、Web開發等最新動態

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"typ

罗燕珊 2021-11-16 19:33:53

Jetpack Compose 佈局詳情

Jetpack Compose 提供了全新的佈局模型，可用於構建美觀流暢的界面。在此講座中，我們將深入介紹佈局模型及其功能和底層工作原理；並詳細說明捆綁式佈局和修飾符的構建方式，以及如何輕鬆創建自定義佈局和修飾符。本講座有助於您理解 Com

谷歌 2021-11-16 15:33:49

Google開發者大會

2021 年 Google 開發者大會以“Develop as One”爲主題，共享 Google 前沿產品資訊與技術趨勢洞見，攜手開發者和合作夥伴激活潛能，共創機遇，共謀發展。

王莹 2021-11-16 12:13:51

爲 Android 12 做好準備

Android 12 是今年剛剛發佈的 Android 新系統版本，它對操作系統的各個方面都做出了很多改進，包括用戶體驗、性能、和隱私。而伴隨着這些改進，也必然會在現有 API 或系統界面方面發生一些行爲變更。 在本次專題演講中，我們會介紹

王莹 2021-11-16 12:13:51