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卡。
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目录下面可以查看到。
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文件。
这个分区包括了一些杂项内容:比如一些系统设置和系统功能启用禁用设置。这些设置包括CID(运营商或区域识别码)、USB设置和一些硬件设置等等。这是一个很重要的分区,如果此分区损坏或者部分数据丢失,手机的一些特定功能可能不能正常工作。
recovery 分区即恢复分区,在正常分区被破坏后,仍可以进入这一分区进行备份和恢复.我的理解是这个分区保存一个简单的OS或底层软件,在Android的内核被破坏后可以用bootloader从这个分区引导进行操作。
这个分区可以认为是一个boot分区的替代品,可以是你的手机进入Recovery程序,进行高级恢复或安卓系统维护工作。
boot 分区
一般的嵌入式Linux的设备中.bootloader,内核,根文件系统被分为三个不同分区。在Android做得比较复杂,从这个手机分区和来看,这里boot分区是把内核和ramdisk file的根文件系统打包在一起了,是编译生成boot.img来烧录的。
如果没有这个分区,手机通常无法启动到安卓系统。只有必要的时候,才去通过Recovery软件擦除(format)这个分区,一旦擦除,设备只有再重新安装一个新的boot分区,可以通过安装一个包含boot分区的ROM来实现,否则无法启动安卓系统。
它将挂载到 /data 目录下, 它是由编译出来的userdata.img来烧入。
android 新增分区以及挂载方法
这个分区也叫用户数据区,包含了用户的数据:联系人、短信、设置、用户安装的程序。擦除这个分区,本质上等同于手机恢复出厂设置,也就是手机系统第一次启动时的状态,或者是最后一次安装官方或第三方ROM后的状态。在Recovery程序中进行的“data/factory reset ”操作就是在擦除这个分区
它将挂载到 /cache 目录下。这个分区是安卓系统缓存区,保存系统最常访问的数据和应用程序。擦除这个分区,不会影响个人数据,只是删除了这个分区中已经保存的缓存内容,缓存内容会在后续手机使用过程中重新自动生成。
Radio分区
保存是基带芯片的固件代码,Linux不认识其格式,在手机启动时装入特定内存中用于驱动芯片。所有与电信网络交互就是靠它了,一般往往用专用开发环境来开发。手机无线信号、蓝牙、wifi等无线管理。
splash分区 这里是启动画面。
SD卡分区
一般默认的是挂载在/sdcard目录。
这个分区不是设备系统存储空间,是SD卡空间。从使用上讲,这个是你自己的存储空间,可以随便你任意存放相片、视频、文档、ROM安装包等。擦除这个分区是完全安全的,只要你把分区中你需要的数据都备份到了你的电脑中。
对应的分区列表
主要分区列表 Modem分区 bootloader分区 boot分区 recoverty分区 system分区 data分区 cache分区 misc分区
在编译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。
该计划的核心主旨是让系统与硬件相关的解耦,加快系统升级速度, 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计划随之产生。
模仿google的实现方案,例如:google封闭了networkstack,那么厂商的团队可以单独实现一个APK组件包含自己针对网络需求客制化的实现。
sdk和vendor feature分离的好处:
1.保证AOSP代码稳定性,减少兼容性问题
2.厂商组件fatal,不会导致上层重启
3.系统主体运行更加顺畅
通常,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是别名。
由SystemServer进程加载,SystemServer 是虚拟机启动后运行的第一个java进程,SystemServer 代码位置 :frameworks/base/services/java/com/android/server/SystemServer.java
大部分服务都启动一个java线程在后台运转,运行在系统systemSerer中,framework 基本只有一个systemServer 系统进程。其他的代码则需要看代码运行在哪里,被哪些模块调用。
android framework层添加自己服务方式:
根据需要有几种方式,
1. 如果服务不依赖底层库,可以直接在java层添加。
2. 如果依赖外部c/c++库,则需要提供jni,在 android/frameworks/base/services/jni下对应添加jni层服务。
3. 如果依赖硬件,则需要添加硬件抽象层接口和jni层,最终添加java层。