• java 系统的一些基础知识


    一、系统目录

    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

    • 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:androidsdk中核心代码。

    • 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包。

    二、系统分区

    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是别名。

    四、系统的关键服务

    由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层。

  • 相关阅读:
    SpringMVC使用AOP监听方法推送数据
    使用极狐GitLab的VS Code插件 GitLab Workflow 来进行项目的DevOps管理,助力研发效能
    天宇优配|研判明年下半年投资机会或更大 险资看好“安全”与“发展”
    Higg FEM的隐藏技能包:碳排放数据
    高等教育心理学:教师职业心理(完) 不是特别重要
    福布斯 AI 50 榜单中唯一开源向量数据库:Weaviate
    【C++】“最强查找“哈希表的底层实现
    Java#15(集合)
    SpringBoot +WebSocket应用
    go-micro教程 — 第一章 快速入门
  • 原文地址:https://blog.csdn.net/jx232515/article/details/126374875