android 系统源码介绍

最新推荐文章于 2024-05-15 16:51:57 发布

清风lsq

最新推荐文章于 2024-05-15 16:51:57 发布

阅读量2.7k

点赞数 1

分类专栏：操作系统 Java 文章标签： android java junit

本文链接：https://blog.csdn.net/jx232515/article/details/127622094

版权

操作系统同时被 2 个专栏收录

15 篇文章 1 订阅

订阅专栏

Java

8 篇文章 0 订阅

订阅专栏

一、系统目录

1.1 系统目录含义

1.2 系统jar作用

Android系统源码目录 system/framework 下各个jar包的用途

am.jar：终端下执行am命令时所需的java库。源码目录：framework/base/cmds/am

android.policy.jar：锁屏界面需要用到的jar包，该包引用了android.test.runner.jar，源码目录：framework/base/policy

android.test.runner.jar：测试应用所需的jar包，该包引用了core.jar,core-junit.ajr以及framework.jar，源码目录：framework/base/test-runner

bmgr.jar：adb shell命令下对Android Device所有package备份和恢复的操作时所需的java库。官方文档：http://developer.android.com/guide/developing/tools/bmgr.html。不过这个android服务默认是Disabled，而且要backup的应用必须实现BackupAgent，在AndroidManifest.xml的application标签中加入android：backupAgent属性。源码目录：framework/base/cmds/bmgr

bouncycastle.jar： java三方的密匙库，网上资料说用来apk签名、https链接之类，官网：The Legion of the Bouncy Castle Java Cryptography APIs

com.android.future.usb.accessory.jar：用于管理USB的上层java库，在系统编译时hardware层会调用到。源码目录：frameworks/base/libs/usb

com.android.location.provider.jar：

com.android.nfc_extras.jar：NFC外部库。android/nfc/NfcAdapter.java会调用到包中的NfcAdapterExtras.java。源码目录：frameworks/base/nfc-extras

core-junit.jar ：junit核心库，在运行*Test.apk时被调用。

core-junitrunner.jar：未知，公司话机上有。

core-tests*.jar：framework下的一系列测试jar包，不做测试时可删除。

core.jar：核心库，启动桌面时首先加载这个。源码目录：

ext.jar：android外部三方扩展包，源码主要是external/nist-sip（java下的sip三方库）、external/apache-http（apache的java三方库）、external/tagsoup（符合SAX标准的HTML解析器）。其实这个jar包可以添加外部扩展jar包，只需在framework/base/Android.mk中的ext-dir添加src目录即可。

framework-res.apk：android系统资源库。

framework.jar：android的sdk中核心代码。

ime.jar：ime命令所需jar包，用于查看当前话机输入法列表、设置输入法。源码目录：framework/base/cmds/ime

input.jar：input命令所需的jar包，用于模拟按键输入。源码目录：framework/baes/cmds/input

javax.obex.jar：java蓝牙API，用于对象交换协议。源码目录：framework/base/obex

monkey.jar：执行monkey命令所需jar包。源码目录：framework/base/cmds/monkey

pm.jar：执行pm命令所需的jar包，pm详情见adb shell pm，源码目录：framework/base/cmds/pm

services.jar：话机框架层服务端的编译后jar包，配合libandroid_servers.so在话机启动时通过SystemServer以循环闭合管理的方式将各个service添加到ServiceManager中。源码目录：framework/base/service

sqlite-jdbc.jar： sqlite的Java DataBase Connextivity jar包。

svc.jar：svc命令所需jar包，可硬用来管理wifi,power和data。源码目录：framework/base/cmds/svc，详情见：http://madgoat.cn/2011/02/android_svc/

二、系统分区

Android 通常有以下分区：

System分区: 就是我们刷ROM的分区

Data分区: 分区就是我们装APK的分区

Cache分区：是缓存分区

SDCard分区：就是挂载的SD卡。

2.1 data分区目录

data分区常用目录：app , system , data ,local，misc 其中system，local可以进入并使用ls等命令。data，app可以进入，但不能用ls命令。

data/data目录：存放的是所有APK程序数据的目录，每个APK对就一个自己的Data目录，就是在data/data/目录下，会产生一个跟 Package一样的目录。如有一个APK,它的包名叫com.test.hello，则在data/data/目录下会有一个 com.test.hello的目录，这个APK只能操作此目录,不能操作其它APK的目录.这个在LINUX下叫做用户进程只能操作自己的进程目录.

data/app目录：用户安装的APK放在这里。我们如果把APK放入这个文件夹下面的话，就算安装好了。这就叫静默安装。不用管APK文件里面的lib目录下的库文件，系统会自动帮我们放入调用库的。

data/system目录下面有packages.xml ,packages.list,appwidgets.xml, 等等一些记录手机安装的软件，Widget等信息。

data/misc目录：保存WIFI帐号，VPN设置信息等。如保存了一个WIFI连接帐号，则此目录下的WIFI目录下面可以查看到。

2.2 system分区目录

system分区常用目录： app , lib, xbin, bin , media，framework.

system/app目录：存放系统自带的APK。没有测试过是否将APK放入到System/app目录下，也是静默安装APK。？

system/lib目录：存放APK程序用到的库文件。

system/bin目录和system/xbin目录：存放的是shell命令,可执行文件。

system/framework目录：启用Android系统所用到框架，如一些jar文件。

2.3 MISC分区

这个分区包括了一些杂项内容：比如一些系统设置和系统功能启用禁用设置。这些设置包括CID(运营商或区域识别码）、USB设置和一些硬件设置等等。这是一个很重要的分区，如果此分区损坏或者部分数据丢失，手机的一些特定功能可能不能正常工作。

2.4 recovery分区

recovery 分区即恢复分区，在正常分区被破坏后，仍可以进入这一分区进行备份和恢复.我的理解是这个分区保存一个简单的OS或底层软件，在Android的内核被破坏后可以用bootloader从这个分区引导进行操作。

这个分区可以认为是一个boot分区的替代品，可以是你的手机进入Recovery程序，进行高级恢复或安卓系统维护工作。

boot 分区

一般的嵌入式Linux的设备中.bootloader,内核，根文件系统被分为三个不同分区。在Android做得比较复杂，从这个手机分区和来看，这里boot分区是把内核和ramdisk file的根文件系统打包在一起了，是编译生成boot.img来烧录的。

如果没有这个分区，手机通常无法启动到安卓系统。只有必要的时候，才去通过Recovery软件擦除（format）这个分区，一旦擦除，设备只有再重新安装一个新的boot分区，可以通过安装一个包含boot分区的ROM来实现，否则无法启动安卓系统。

2.5 userdata 分区

它将挂载到 /data 目录下, 它是由编译出来的userdata.img来烧入。

android 新增分区以及挂载方法

这个分区也叫用户数据区，包含了用户的数据：联系人、短信、设置、用户安装的程序。擦除这个分区，本质上等同于手机恢复出厂设置，也就是手机系统第一次启动时的状态，或者是最后一次安装官方或第三方ROM后的状态。在Recovery程序中进行的“data/factory reset ”操作就是在擦除这个分区

2.6 cache 分区

它将挂载到 /cache 目录下。这个分区是安卓系统缓存区，保存系统最常访问的数据和应用程序。擦除这个分区，不会影响个人数据，只是删除了这个分区中已经保存的缓存内容，缓存内容会在后续手机使用过程中重新自动生成。

2.7 其他分区

Radio分区

保存是基带芯片的固件代码，Linux不认识其格式，在手机启动时装入特定内存中用于驱动芯片。所有与电信网络交互就是靠它了，一般往往用专用开发环境来开发。手机无线信号、蓝牙、wifi等无线管理。

splash分区这里是启动画面。

SD卡分区

一般默认的是挂载在/sdcard目录。

这个分区不是设备系统存储空间，是SD卡空间。从使用上讲，这个是你自己的存储空间，可以随便你任意存放相片、视频、文档、ROM安装包等。擦除这个分区是完全安全的，只要你把分区中你需要的数据都备份到了你的电脑中。

对应的分区列表

主要分区列表 Modem分区 bootloader分区 boot分区 recoverty分区 system分区 data分区 cache分区 misc分区

2.8 编译后生成的img

在编译android 之后，会生成几个image 文件，这些文件是：

1.、ramdisk.img : 一个分区镜像文件，它会在kernel 启动的时候，以只读的方式被 mount ，这个文件中只是包含了 /init 以及一些配置文件，这个ramdisk 被用来调用init，以及把真正的root file system mount 起来。

2、system.img：是包含了整个系统，android 的framework，application 等等，会被挂接到 “/” 上，包含了系统中所有的二进制文件

3、userdata.img：将会被挂接到 /data 下，包含了所有应用相关的配置文件，以及用户相关的数据。

4、boot.img：包括 boot header，kernel， ramdisk boot镜像不是普通意义上的文件系统，而是一种特殊的Android定制格式，由文件头信息boot header，压缩的内核，文件系统数据ramdisk以及second stage loader（可选）组成，它们之间非页面对齐部分用0填充。

5、update.img：将所有的img文件，通过指定打包工具，制作update.img，批量生产中常用到此镜像文件

1、 Android系统的移植过程与移植linux很像先移植bootloader，再移植linux内核，最后烧写文件系统，只是最后烧写文件系统的时候用system.img就行了。流程： bootloader.img -> boot.img -> system.img (将android 系统烧录到手机硬件上，进行合适的文件分区)

img格式文件是镜像文件的一种。linux（android）系统加电后进入bios，随后读取硬盘的主引导记录(MBR)(bootloader),然后调用另一个引导程序（grub或lilo）(boot)来加载内核和镜像文件。加载内核后系统会把文件系统存放到ram中，然后系统运行。

JAR文件是Java Archive File-java档案文件的简称，是与平台无关的文件格式，基于zip文件格式将许多文件合成一个压缩文件.jar，区别是比zip多了一个包含了一个 META-INF/MANIFEST.MF 文件，这个文件是在生成 JAR 文件的时候自动创建的。

3.作用

JAR 文件不仅用于压缩和发布，而且还用于部署和封装库、组件和插件程序，并可被像编译器和 JVM 这样的工具直接使用。在 JAR 中包含特殊的文件，如 manifests 和部署描述符，用来指示工具如何处理特定的 JAR。

三、系统变更

3.1 Treble 计划

该计划的核心主旨是让系统与硬件相关的解耦，加快系统升级速度， Treble 始于 Android O，到 Android P 又得以进一步完善。

在Android O以及以后的版本当中，Android 更新了新的框架设计在新的框架设计当中，引入了一套叫HIDL的语言来定义Freamework与HAL之间的接口，新的架构如下图：

跟以往的Android 版本相比较，Android O里使用HIDL来解耦Android Framework 与Vendor HAL Implemetation之间的关系，从而简化降低Android系统升级的影响与难度。并且目前看起来，Android Framework与Vendor HAL Implemetation会存放在不同的分区当中，Android Framework会在system分区当中，而Vendor HAL Implemetation会在一个新定义的分区(Vendor.img)当中，这样刷新的system.img 才不会影响到Vendor HAL Implemetation

随着android-Q的到来，google对android framework中某些模块进行了独立解耦，不在运行在systemserver中,同时禁止各个odm/oem厂商修改这部分代码,仅仅提供了代码实现和一个单独的apk供厂商集成。

这一举措提高了google对android系统的管控力。如果说之前treble计划是促进了厂商的适配效率，那么mainlane就是强制厂商提升自身软件建设能力来提升升级效率的方案。Android-S开始mainlane计划强制厂商从AOSP解耦，保证AOSP代码的纯净。google会逐渐将aosp的主要代码进行分离，形成独立的apk由自己进行升级，不再依赖厂商的OTA。

在android-O以前，所有厂商自身的客制化主要是通过修改systemserver实现的。修改的代码和AOSP交叉在一起，虽然得到了便利，但在每次版本升级都不断的引入CTS问题和兼容性问题。

插桩的方法简单直接，对AOSP实现的复用性比较高，如果各个厂商能够克制的修改是一个非常便捷的方法。但是事与愿违，各个厂商对AOSP代码的修改十分激进，甚至大量的修改google的原生逻辑，通过各种手段规避CTS问题进而引入系统兼容性问题、稳定性问题、内存碎片化和系统体积激增。google也意识到了这个问题，所以treble+mainlane计划随之产生。

3.2 解耦思路一:各行其是

模仿google的实现方案，例如:google封闭了networkstack，那么厂商的团队可以单独实现一个APK组件包含自己针对网络需求客制化的实现。

sdk和vendor feature分离的好处:

1.保证AOSP代码稳定性，减少兼容性问题

2.厂商组件fatal，不会导致上层重启

3.系统主体运行更加顺畅

3.3 Native的进程执行

通常，native进程是由shell或者init启动，启动的过程如下：

Shell接收到命令，启动一个程序，此时shell首先会fork一个新的进程

新fork的进程，通过execve系统调用，陷入到内核中，内核检查和加载需要执行的二进制映像文件，检验其合法性及权限。通常用户态进程要启动一个新的程序(如shell)，fork后，execve要紧跟着执行，这样会有更好的效率(由于使用COW技术，这样可以避免页表复制，而execve后，之前进程中的所有内容都是无用的，若execve紧跟fork后，可以避免COW引起的拷贝);

通常二进制文件都会要依赖一些系统动态库，此时kernel会启动加载器/system/bin/linker，执行linker的__linker_init()

Linker的linker_init()，会分析二进制的elf文件，加载依赖的动态库文件，然后转入二进制映像的入口函数__start中执行

__start会调用C库的初始化函数__libc_init()

__libc_init()会调用映像的main函数，这个main函数也就是用户app的入口函数

main() 函数执行完毕后，通过exit()退出进程执行

需要注意的是，android bionic提供的加载器是/system/bin/linker，而普通linux系统用的glibc是/lib/ld-linux-xx.so.2。这也是为何其他linux平台同指令架构的二进制文件，不能在android上运行的原因之一：启动用户进程的加载器这个程序运行的第一步就出错了。

zygote实际上是/system/bin/app_process, zygot是别名。