返回介绍

了解一下 Android 10 中的 APEX

发布于 2022-03-27 22:42:47 字数 12935 浏览 1179 评论 0 收藏 0

缘起

Android碎片化的问题除了好多厂商加了更符合国人土豪味的特性之外,其实还有一个更基础性的问题就是升级太慢。为啥子?

不记得之前讲过没有(好像讲过),现在再讲一遍:

  • 谷歌是AOSP代码的亲爹。但是有个问题,它老人家把代码搞出来后呢,还不能给厂商使用。因为谷老大没有硬件—给其他玩家用的硬件。

  • 在这个生态链里,谷老大之后是华为,高通,MTK这样的芯片厂商。这些芯片厂商有芯片(SOC啊,全套都有,就好像拎包入住的精装修的房子——为毛码农可以拿房产做比喻,潘石屹不能学Python?),再加上自己偏底层,偏硬件的代码,配合谷老大的上层,组合一下卖给下游厂商。

  • 接下来是华米OV魅,他们肯定是基于芯片厂商的代码来再做自己的工作。

虽然谷歌用了很多办法来提高新系统的适配速度(有技术上的,有厂商合作方面的),但这个长长的链条摆在这,新系统普及率比ios差得不是一星半点。痛定思痛,谷歌终于发现瓶颈在哪了,其实还是技术上的:

  • 刚开始以为是驱动更新不及时,所以谷歌搞了Treble。从Android O开始。通过Treble,OS升级中和硬件相关的地方就尽可能摘出来,老的驱动也能跑在新的OS上。不知道用Treble后,OS升级率提高到多少,但显然还没让人满意。

  • Android Q,谷老大搞了一个mainline计划,这个计划中文名可以称作霸王硬上弓——霸王是谷歌,硬上弓也指这活很需要技术含量,不是谁都能搞。支撑mainline计划的核心就是本篇要讲的APEX。这么霸王的名字居然是Android Pony EXpress的简称(Android小马快线?)。

APEX和APK类似,它把Framework层中那些关键的东西搞成一个个的模块,然后可以单独升级这些模块。这些模块和就和一个一个的APK类似,就是一个压缩包,后缀名叫.apex。来看官方文档中对.apex文件格式的描述:

apex和apk类似,实际上也是一个压缩文件。只不过apk和apex的目标不一样。请大家谨记

  • apk是应用程序的载体,对应用开发者而言,可以apk方式对应用功能进行升级。

  • apex是系统功能的载体,对系统开发者(目前看主要是谷歌)而言,可以apex方式对系统功能进行升级。这些apex包将来就发布在谷歌的playstore上供我们下载。简直不能太棒!

apex相当于对系统功能进行了更细粒度的划分,可以独立升级这些功能。而从另外某个意义上来说,这种做法也更加限制了设备厂商的魔改行为——这就是谷歌mainline计划的目的。

现在,我们可以把apex看成是一个一个的系统升级包,接下来我们看看系统中有哪些模块被划归到apex里了。

了解一下,有哪些apex包?

我们以模拟器+x86_64不带谷歌服务的镜像为例,启动模拟器看一下。

/system目录下多了一个apex目录。这里存的就是可以通过apex方式升级的系统功能。现在先不谈怎么个升级法。先看看哪些功能被封装到不同的apex里了。我们看几个主要的。

com.android.runtime.debug

其核心是com.android.runtime。什么是runtime呢?就是ART虚拟机相关的东西。下面是这个apex包的成员:

图中,每一个apex包(或者是目录)都包含:

  • apex_manifest.json:这个是apex包的清单文件,类似apk中的AndroidManifest.xml。apex_manifest.json功能比AndroidManifest.xml要复杂,里边还包含该apex安装前和安装后要执行的命令。

  • apex_pubkey:apex包的签名信息。和apk一样,我们对apex包也需要校验

  • 剩下的目录就是此apex包的实际内容。显然,什么so,可执行程序,系统级jar包都可以包含在apex包中

那么,com.android.runtime apex包都有哪些内容呢?

以上是runtime apex的主要内容。可看出,它包含的大部分是ART虚拟机相关的so和可执行程序。另外,bionic C库的libc.so,libdl.so,libm.so也在其中。

另外,位于/system/lib下的libc.so等也变成了链接,指向位于apex包中的这些so。来看图:

注意上图中的/apex/com.android.runtime目录,这个和apex包的处理逻辑有关,我们稍后介绍。

com.android.media

com.android.media是多媒体相关的apex包,直接看它的内容:

media apex包还包含了libbinder.so,libc++.so等非常关键的so。但要指出的是,/system/lib下的libc++.so却不是链接到media下的libc++.so。也就是说,系统里存在多份libc++.so。一个是/system/lib下的libc++.so,另外一个是media apex下的libc++.so(实际上,另外一个apex包,com.android.media.swcodec下还有一个libc++.so)。

除了libc++.so外,其他好几个so也存在同样的情况。对这件事,我第一感觉是有点奇怪。为了加载到正确的so,可能需要链接器linker程序做对应的修改。此问题我没有继续查下去了,欢迎有知道的童鞋指教。

了解一下,apex的安装

apex的安装(包括更新,回退)是一个比较复杂的过程。

为此,谷歌不惜对init做了重大改动。这里,我不打算对init做更详细的分析,先浮光掠影带大家看一下。有需要的话可自己看看。

总体来说,init大体上还是我八年前在《深入理解Android 卷1》里分析的那个init的样子。比如都是解析init.rc文件,然后执行对应的动作。但我感觉现在的init对初学者非常的不友好。因为代码逻辑比较复杂,而且用上了C++(应该在Android 10之前就用上C++了)。

对于Android这样的复杂系统,我感觉从老版本开始学习其实是一个合适的方法。因为老版本的思想,目的可能更单纯,更容易掌握。这有点像Linux Kernel方面的书籍,绝大部分都停留在2.x时代。这也是我为什么不愿意给深入理解系列书籍升级版本的原因。深入理解系列,宁愿开垦一个之前从未写过的方向,也不要做老版本升级。有些知识,还真不是越新越好。以我个人经验看,7.0的时候我为了做一个Framework培训,大概花了1个月左右的时间就对自己的知识进行了全面升级。现在10.0的话,我感觉在3个月内可以完成知识升级工作。

整体来说,10.0中的init将分为三个阶段执行。这三个阶段挺有意思,都是执行init,但传的参数不一样。

上图是init的main函数,稍微介绍下:

  • 首先是kernel启动后执行不带参数的init进程,这就进到上图中的①,FirstStageMain。FirstStageMain里边将做android verified boot,也就是把上篇文章(了解一下,Android 10中镜像文件的制作)里的分区挂载上来。第一阶段的代码中有大量和分区,avb有关的内容。是一个比较好的了解相关知识的地方

  • FirstStageMain最后会

    execv("/system/bin/init","selinux_setup")再次执行init(参数为"selinux_setup")。这将进入图中的②。SetupSelinux阶段。这个阶段也就是selinux相关处理。selinux是一个完备的知识体系,感兴趣的童鞋可阅读我在2014年2月CSDN上发的三篇selinux系列文章

    (https://blog.csdn.net/Innost/article/details/19299937)。这几篇文章秉承我们深入理解抄底式的学习风格,当年我拿它在SONY移动做内部培训用。唯一的小遗憾是没太讲selinux的programming。因为我当初理解它selinux更多是配置的事情。现在看也不完全对。

  • SetupSelinux最后

    execv("/system/bin/init","second_stage"),此后将转入图中的③。SecondStageMain就是我们早期init功能的处理之处。这块功能基本上用C++语言全部重写了(对比我在深入理解Android 卷1里2.3版本的init)。我个人感觉是init不美了。以前基于C结构体的OOP我觉得看着挺舒服....

apex作为一个系统功能安装包,肯定有一个对应的服务进行管理。在Android 10中,这个服务就是apexd。代码位于/system/apex下。init通过apexd.rc启动apex相关服务。看一下这个apexd.rc文件

apexd.rc有两个服务,一个是apexd-boostrap,一个是apexd。其实对应执行的程序都是/system/bin/apexd,只不过bootstrap带了一个参数“--bootstrap”。上面两个服务中,先启动apexd-bootstrap,然后再启动apexd。下面是apexd的入口代码:

apexd-bootstrap是主要处理apex包的地方。包括校验签名 ,apex 版本比较等。然后,它会将 apex 包(例如 /system/apex/com.android.runtime.debug 等)挂载到/apex目录下。使用的方法是mount的MS_BIND标志。

我们看下apexd-bootstrap执行后,apex包mount的情况,

以上两个图中,最上面的是mount命令的结果。注意,apex包的mount和kernel的dm设备有比较密切的关系。Android 10大量使用了这个dm,以后有机会我们了解下。

下面的图是/apex/目录的内容。注意,有些目录名后面带一个@和数字,比如com.android.conscrypt@290000000。这个290000000是com.android.conscrypt apex包中apex_manifest.json里的version字段。比如:

/apex是系统内部其他模块引用apex包的地方,这样就不需要使用/system/apex了。比如,我们上面的com.android.runtime.debug实际bind mount到/apex后将通过com.android.runtime来引用。

bind mount其实就是可以把一个目录挂载到多个目录。看起来效果和link一样。大家可在ubunutu上mount --bind试一下。

了解一下,apex的preinstall/postinstall

如果仅仅是挂载apex包,那我们还是太小瞧apex了。com.android.runtime的apex_manifest.json是这样的:

apex_manifest.json里还有preIntallHook和postInstallHook两个小东西。这两个东西指向apex包中bin/目录下的两个shell脚本。我们看一下postInstallHook的脚本(bin/art_postinstall_hook)。

这个脚本干了什么具体的事情我们先不细说,但是一个apex包升级居然还要涉及到脚本来执行,这还是第一次在Android上看到。所以,这里的复杂度比较高,很容易出错。我个人猜测未来可能会优化。

了解一下,apexservice

apexd服务将注册一个名为“apexservice”的服务到系统服务里,dumpsys apexservice打印的结果如下:

apexservice还有一些服务,如下:

到此,我们对apex的了解就告一段落。对一般开发者而言,只要知道apex包是被谷老大用来更新系统级功能的就行。另外,代码中有一个GSI(Generic System Image),这个GSI镜像可能包含的就是这些谷歌希望由自己来控制更新的apex包。通过这种方式,厂商能改的地方将大大受限,而能访问谷歌playstore的人们也可以第一时间享受谷歌的系统更新(但是谷歌经常也挖坑,搞出好多系统bug

后续的安排

AOSP 10源码撸了大概五天,发现其中有一些需要了解的知识,比如APEX、ART等。接下来会对这些东西做一系列的“了解”。在此也欢迎大家提供一些目标,好让我们的"了解Android 10”系列飞得更远一点。

最后的最后

  • 我期望的结果不是朋友们从我的书、文章、博客后学会了什么知识,干成了什么,而应该是说,神农,我可是踩在你的肩膀上的喔。

  • 关于学习方面的问题,我已经讨论完了。后面这个公众号将对一些基础的技术,新技术做一些学习和分享。也欢迎你的投稿。不过,正如我在公众号“联系方式”里说的那样——郑渊洁在童话大王《智齿》里有一句话令我印象深刻,大意是“我有权保持沉默,但你说的每一句话都可能成为我灵感的源泉”。所以,影响不是单向的,很可能我从你那学到的东西更多。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文