大家好，关于主题源码分享免费下载网站很多朋友都还不太明白，今天小编就来为大家分享关于找主题源码的知识，希望对各位有所帮助！
时代在进步，第三套少儿广播体操！不好意思，搞错频道了，重来！时代在进步，Android的版本也是快速的进行着迭代着，从我们以前最常见的Android4.4一直发展到了今天的Android11版本(即AndroidK到AndroidR)，Android版本的快速迭代对于消费者来说是一件普天同庆的大好事情，但是对于我们开发者来说各种适配各种改造有时候吃翔的心情都有了。而对于Android版本的适配和各种改造的第一步就是从编译Android源码开始，可是不幸的是随着Android版本的迭代连编译Android源码的相关流程都发生了翻天覆地的变化，正所谓工欲利其事必先利器，所以我们今天的这篇博客将带领读者一起来到Android各个版本的源码编译发展和编译具体操作步骤！
这里我们需要注意一下Android各个版本的对应关系如下:
Android5.x(Lollipop)简称AndroidL版本Android6.0(MarshMallow)简称AndroidM版本Android7.x(Nougat)简称AndroidN版本Android8.x(Oreo)简称AndroidO版本Android9.0(Pie)简称AndroidP版本Android10.0(Q)简称AndroidQ版本Android11.0（R)简称AndroidR版本
并且这里还有一点需要特别注意，本文演示的AndroidR版本是以高通平台为基准进行的。
一.Android编译环境的构建以及常见命令
??俗话说天时地利人和缺一不可，而这其中的地利翻译过来说的就是环境因素了，人的成长离不开环境因素，而我们的Android编译也离不开编译环境的构建！虽然我们本篇博客的主题是Android源码编译指南，但是我们还是有必要抽出一个章节来简单说明下Android编译环境的构建和初始化过程，以及初始化完毕后常见的命令。
1.1Android编译环境的构建
本章节重点偏向的是Android编译环境的构建，而不是编译环境构建的原理分析(如果是原理分析，那内容就多了,关于Android编译墙裂推荐一篇博客来自IBM社区理解AndroidBuild系统，你值得拥有！)。
虽然Android的版本一直在迭代着，但是Android编译环境的构建步骤还是比较良心的依然没有多大的变化(注意这里的措辞，只是步骤)，对于有过Android源码开发经验的读者来说是再为熟悉不过的了，通常是如下二部曲:
$sourcebuild/envsetup.sh\n$lunchaosp-eng\n12
虽然各位对上述的命令应该已经烂熟于心了，但是这里我还是简单说明一下:
第一行命令”sourcebuild/envsetup.sh”引入了build/envsetup.sh脚本。该脚本的作用是初始化编译环境，并引入一些辅助的Shell函数，这其中就包括第二步使用lunch函数第二行命令”lunchaosp-eng”是调用lunch函数，并指定参数为”aosp-eng”。lunch函数的参数用来指定此次编译的目标设备以及编译类型。在这里，这两个值分别是”aosp”和”eng”。”aosp”是Android源码中已经定义好的一种产品，是为模拟器而设置的。而编译类型会影响最终系统中包含的模块。如果在调用lunch函数的时候没有指定参数，那么该函数将输出列表以供选择，列表内容不同Android版本，不同厂家的基线源码会有所不同，如下:
这里补充一点对Android的源码编译类型简单说明一下，它可以分为如下三种功能，每种类型的特点如下:
1.2Android编译各种常见命令
在编译环境初始化完成后，我们就可以使用各种各种编译环境提供的指令和make编译命令族来开启Android的构建之旅了，这里我简单的总结了下，我们在Android编译中可能会用到的编译环境提供的指令和make编译命令族，如下:
1.2.1常见的Android命令指令
指令说明??croot??切到Android源码树的根目录(当你深入Android源码树的子目录，想回到根目录的时候此命令就非常实用了)m相当于在源码树的根目录执行make，并且该命令不一定要在根目录下执行mm编译当前目录路径下的所有模块(包括include进来的，但是不包括存在依赖关系模块)mma编译当前目录路径下的所有模块(包括include进来的，且包括存在依赖关系模块)mmm[module_path]编译指定目录路径下的所有模块(包括include进来的，但是不包括存在存在依赖关系模块)mmma[module_path]编译指定目录路径下的所有模块(包括include进来的，包括存在存在依赖关系模块)cgrep对C/C++文件执行grep(即grep的时候只搜寻C/C++文件类型，注意这里也包括.h文件类型)jgrep对Java文件执行grep(即grep的时候只搜寻Java文件类型)resgrep在所有res/.xml文件上执行grep即grep的时候只搜寻res/.xml文件类型)printconfig显示当前Android编译的相关配置信息add_lunch_combo在lunch命令的的菜单中添加一个条目
这里我们对上述表格中的&34;简单解释一下:1.依赖关系模块这个要怎么说呢，这里我们举个例子！譬如模块A的编译需要依赖模块B，此时的B是一个so库。2.假如我们通过mm或者mmm编译模块A的时候，此时B模块还没有编译那么此时就会报错3.假如我们使用的是mma或者mmma编译模块A，假如依赖的模块B还没有编译，那么会先将模块B编译OK，然后编译模块A(当然这里只是举栗子，可能A还依赖C,D同理也会先编译)
1.2.2make编译命令族
Android的Build编译系统处理常见的make单命令之外，还提供了其它的一系列make命令族，这里我们简单过下:
指令说明makeupdate-api更新API文件，在frameworkAPI改动之后，需要首先执行该命令来更新API，公开的API记录在frameworks/base/api目录下makeAndroid默认系统编译指令，会编译出整个系统的所有镜像(其实质最终执行的是makedroid)makedroid同上makesdk编译出Android的SDK开发套件makeclean-sdk清理SDK的编译产物makedist执行整个编译，并将MAKECMDGOALS变量定义的输出文件拷贝到/out/dist目录下，这个命令在实际中用的比较少makeall编译所有内容，不管当前产品的定义中是否会包含,官方解释如下:buildseverythingmakedroiddoes,pluseverythingwhoseLOCAL_MODULE_TAGSdonotincludethe“droid”tag.ThebuildserverrunsthistomakesurethateverythingthatisinthetreeandhasanAndroid.mkbuilds.makehelp帮助信息命令，显示当前Android版本主要支持的make命令makesnod从已经编译出的包快速构建系统镜像(譬如你重新单独编译了某个模块，然后想快速进行打包到system.img，可以使用此命令加快速度)makeclean-$(LOCAL_MODULE)Letyouselectivelycleanonetarget.Forexample,youcantypemakeclean-libutilsandtwilldeletelibutils.soandalloftheintermediatefiles.即清理掉一个指定模块的编译结果和中间产物makeclean-$(LOCAL_PACKAGE_NAME)Letyouselectivelycleanonetarget.Forexample,youcantypemakeclean-HomeanditwillcleanjusttheHomeapp…即清理掉一个指定模块的编译结果和中间产物makecleandeletesalloftheoutputandintermediatefilesforthisconfiguration.Thisisthesameasrm-rfout/<configuration>/通常删除的是整个Android源码工程的out/*目录makeclobberdeletesalloftheoutputandintermediatefilesforallconfigurations.Thisisthesameasrm-rfout/.这个命令在实际中，应用得比较少makedatacleandeletescontentsofthedatadirectoryinsidethecurrentcombodirectory.Thisisespeciallyusefulonthesimulatorandemulator,wherethepersistentdataremainspresentbetweenbuilds.这个命令在实际中应用得也比价少makeinstallclean当我们在执行切换编译目标时可以执行makeinstallclean，用以清除之前编译生成的文件，但是又不会将整个out目录清空，这样可以加快编译目标的构建速度makeLOCAL_MODULE编译一个指定的模块，LOCAL_MODULE为模块的名称，这种编译方法通常运用在整个Android工程没有构建，但是想快速编译一个模块时可以使用，可以加快单个模块构建速度maketargetswillprintalistofalloftheLOCAL_MODULEnamesyoucanmake.makelibandroid_runtime编译所有JNIframework内容。makeframework编译所有Javaframework内容(做Androidframework开发的小伙们对这条命令应该是再熟悉不过的了)。makeservices编译系统服务和相关内容makebootimage编译生成boot.imgmakerecoveryimage编译生成recovey.imgmakecacheimage编译生成cache.imgmakesystemimage编译生成system.imgmakevendorimage编译生成vendor.imgmakesuperimage编译生成superi.img
对上述的make命令有几点需要注意:1.可能在不同的Android版本有不同表现，且有的可能已经不支持了2.读者最好对于每个make编译命令，自行使用一番，然后慢慢品尝
二.Android编译的发展史简介
??有过一定Android开发经验的读者应该知道Android最初是用Android.mk配置来编译源码的(这里的Android.mk本质上有点类似Makefile文件)。但是随着Android版本的迭代，源码工程文件越来越大，包含的模块越来越多，而以Android.mk组织的项目编译花费的时间越来越多。面对这个严峻的问题，Android的妈咪谷歌终于在在Android7.0开始引入了ninja编译系统。相对于make来说ninja在大的项目管理中速度和并行方面有突出的优势，因此Google采用了ninja来取代之前使用的make。由于Android.mk的数量巨大且复杂，不可能把所有的Android.mk改写成ninja的构建规则，因此Google搞了个kati工具，用于将Androd.mk转换成ninja的构建规则文件build.ninja，再使用ninja来进行构建工作。
??Android编译的发展依然没有停止进化，果不其然Android8.0开始，Google引入了Android.bp文件来替代之前的Android.mk文件，Android.bp只是纯粹的配置文件，不包括分支、循环等流程控制，本质上就是一个json配置文件。同时还引入Soong这个工具，用于将Android.bp转换为ninja的构建规则文件build.ninja，再使用ninja来进行构建工作。但之前的模块全部是用Android.mk来定义的，google不可能一下子把所有模块都修改成Android.bp，只能逐步替换。无论是Android.mk还是Android.bp最后都是转化成ninja的构建规则，再进行编译的。
如果你对上述的概述，还是觉得太啰嗦了，没有关系。这里我们用更加简单的文字来整体来概括一下Androidbuild系统随着Android版本相应的发展演变过程:
Android7.0引入ninja和katiAndroid8.0使用Android.bp来替换Android.mk，引入SoongAndroid9.0强制使用Android.bp
2.1Soong、Blueprint、Kati、Ninja关系
通过前面的章节，我们简单介绍了Android编译系统的发展史！读者会发现，其中突然一下子冒出了许多的概念，这里我们先暂且不对其中涉及的概念深入了解，我们先说说上述几个概念Soong、Blueprint、Kati、Ninja之间的关系，它们之间的关系图如下:
上图是一个静态的整体的关系图，但是在Android源码工程构建过程中的它们之间可以使用如下的转换关系图来表示:
关系图已经给各位看官摆出来了，那么它们之间的转换关系是怎么来的呢，这里我们来说说:
首先通过Kati将Android.mk转换成ninja格式的文件通过androidmk将将Android.mk转换成Android.bp，但是只针对没有分支、循环等流程控制的Android.mk才有效，如果对于有控制流的就必须手动了具体可以想见博客Android.bp正确姿势添加宏控制编译指南通过Blueprint+Soong将Android.bp转换成ninja格式的文件
不容易啊，这里我们对涉及到Ninja,kati,Soong,bp关系搞清楚了(各种三角恋)！那么关于它们的概念，接下来我们也得简单介绍介绍，安排上才行！
2.2Kati简介
Kati是专为Android开发的一个基于Golang和C++的工具，主要功能是把Android中的Android.mk文件转换成Ninja文件。代码路径是build/kati，编译后的产物是ckati。
Kati代码是开源的，可以把它clone下来，如果感兴趣可以查看下其实现原理
这里我们构建一个通过Android.mk配置的LOCAL_MODULE模块，然后通过top命令就可以查看在编译的过程中执行了ckati的命令。
2.3Ninja简介
ninja是一个编译框架，会根据相应的ninja格式的配置文件进行编译，但是ninja文件一般不会手动修改，而是通过将Android.bp文件转换成ninja格文件来编译。
2.4Android.bp简介
Android.bp的出现就是为了替换Android.mk文件。而bp跟mk文件不同，它是纯粹的配置，没有分支、循环等流程控制，不能做算数逻辑运算。如果需要控制逻辑，那么只能通过Go语言编写。Android的妈咪谷歌为了让开发者能更加的快速掌握Android.bp特意提供了androidmk命令(关于它的详细介绍可以参见博客Android.bp入门指南之Android.mk转换成Android.bp，这里就不过多的戏说了)用于Android.mk转换成Android.bp使用，如下转换命令:
$androidmkAndroid.mk>Android.bp\n1
2.5Blueprint和Soong构建编译系统
2,5.1Soong简介
Soong类似于之前的Makefile编译系统的核心，负责提供Android.bp语义解析，并将之转换成Ninja文件。Soong还会编译生成一个androidmk命令，用于将Android.mk文件转换为Android.bp文件，不过这个转换功能仅限于没有分支、循环等流程控制的Android.mk才有效。
2.5.2Blueprint简介
Blueprint是生成、解析Android.bp的工具，是Soong的一部分。Soong负责Android编译而设计的工具，而Blueprint只是解析文件格式，Soong解析内容的具体含义。Blueprint和Soong都是由Golang写的项目，从Android7.0，prebuilts/go/目录下新增Golang所需的运行环境，在编译时使用。并且因为Soong和Blueprint是Google谷歌为Android.bp特别定制的工具，所以不需要要摘出来单独来操作。
三.高版本P/Q/R源码编译
??通过前面的章节我们了解了Android编译环境的构建和编译的发展史(前面的章节都是为了后面章节服务做的整体铺垫)，那么从本章节开始就要契合本篇博客的主题了将重点分析AndroidO之后高阶版本的编译的不同之处了。在本篇的博客开始就有说到过是以高通版本的AndroidR为基线来进行分析的。所以在开始本章节的博客前，有两个知识点需要提前介绍下，一个是AndroidQ以及之后的动态分区概念，另外一个就是高通Q之后引入的QSSI(或者qssi)的概念！
3.1Android动态分区
动态分区是Android的用户空间分区系统。使用此分区系统，您可以在无线下载(OTA)更新期间创建、销毁分区或者调整分区大小。借助动态分区，供应商无需担心各个分区（例如system、vendor和product）的大小。取而代之的是，设备分配一个super分区，其中的子分区可动态地调整大小。单个分区映像不再需要为将来的OTA预留空间。相反，super中剩余的可用空间还可用于所有动态分区(关于动态分区详见谷歌官方Android实现动态分区)。
3.2什么是QSSI
QSSI是QualcommSingleSystemImage的缩写，并且高通平台从AndroidQ开始支持。高通的官方文档对此的解释是引入QSSI的概念是为了解决Android碎片化问题，把system.img和vendor.img进一步拆分。
并且其编译也和Android原生编译有差别，其差别如下:
3.4高版本Android非QSSI特性的整体编译流程
高版本Android非QSSI特性的编译流程,依然和以前的版本Android编译变化不大，通常是如下的步骤(这个也是读者最为熟悉的了):
sourcebuild/envsetup.sh\nlunchxx-userdebug\nmake\n123
这里需要注意的的是通用版本的Android还是可以直接通过make相关的分区进行直接编译的，譬如makesuperimage或者直接执行make编译
3.4具有QSSI特性Android高版本整体编译流程
通过前面看到QSSI特性的固件编译流程也和通用版本的有一定的区别，这里的编译分为两种模式，第一种Android的标准编译模式，另外一种就是高通提供的编译脚本。
3.4.1通过Android内置make命令编译
初始化编译环境
sourcebuild/envsetup.sh\n1
编译system.img
lunchqssi-userdebug\nmaketarget-files-package\n12
编译除system.img外的其他img
lunchxx-userdebug\nmaketarget-files-package\n12
3.4.2高通提供的build.sh脚本进行编译
编译所有img，包括system和其它img
sourcebuild/envsetup.sh\nlunchXX-userdebug\n./build.shdist-j32\n123
编译system.img，产物在qssi目录下
sourcebuild/envsetup.sh\nlunchxx-userdebug\n./build.shdistqssi_only-j32\n123
编译super.img
sourcebuild/envsetup.sh\nlunchxx-userdebug\n./build.shdistmerge_only-j32\n123
编译其它img，例如vendorimage，如果不指定会编译其它所有img，产物在XX目录下
sourcebuild/envsetup.sh\nlunchxx-userdebug\n./build.shvendorimagedisttarget_only-j32\n\n1234
3.5动态分区刷机的方法
由于AndroidQ版本以及以上将system和vendor分区合并为super分区，无法通过adbrebootbootloader模式单独刷动态分区里面的img，例如system,vendor,product,odm等镜像，只能刷super.img和其他的分区，但是super.img分区动辄几个G的大小，每次刷机几乎都要等上个好大几分钟，这个酸爽你懂的。
这里有一点需要注意并不是说真的在bootloader模式下不能刷入system分区镜像，可以看到下面的截图是可以刷入的，但是只是镜像没有真的烧录生效，所以读者在实际开发中一定不要做无用功，否则一直烧录，会发现咋咋我修改的东西没有生效呢！
那有没有方法单刷呢，当然有了，不然我也不会多提一句不是。我们可以在fastboot模式下可以单独刷动态分区里面的img，其方法如下:
fastbootd是用户空间的代码，因为动态的逻辑分区只能在应用空间识别\n12345678910
1.如果是在linux下fastboot刷机出现权限问题，需要将fastboot的所有者属性改成rootsudochownroot:rootfastbootsudochmod+sfastboot2.如果是在windows环境下使用fastboot，很大概率可能不识别fastboot，此时推荐下载360的手机助手借助它安装对应的驱动，这样就能进行相关的识别了，此处是个人经验3.并且我们在实际操作中需要，注意fastboot是否处于锁定模式，否则会报一下错误(我调试的终端，已经强制锁定了,所以那怕我强制执行了解锁也一直报remote:'Commandnotavailableonlockeddevices’的异常)4.我们来使用一个可以动态解锁的fastboot，大功告成！
3.6Framework编译
对于从事Android偏向现Framework开发的读者来说，编译Android的Framework层是再常见不过的操作了，在AndroidR之上的Framework的编译已经和之前有所不同，具体参见下面解释:
AndroidR之前单独编译framework和service命令为:
make-j8framework\nmake-j8services\n12
AndroidR之后编译services的命令还有效果，但是对于framework就有点力不从心了(因为编译规则已经改变了)，如下
make-j8framework-minus-apex\nmake-j8services\n12
四.解决Android高版本编译ssd固态硬盘空间不够的问题
??对于Android开发者来说，当然希望自己在服务器上分配到的资源越多越好，特别是固态硬盘的容量，但是公司当开发者过多的时候，公司就会尽量压缩ssd固态硬盘的盘符空间，只给分配了250G的固态硬盘容量，如果是同时开发编译几个Android低版本的源码，那肯定是够了，但是切到AndroidR之后，250G肯定是远远不够的，这里我们通过du命令查看一下AndroidR编译出来之后的情况，如下:
ityuan@pd:~/ssd$du-sh*\n\n260G\tqcm2290\nityuan@pd:~/ssd$\nityuan@pd:~/ssd$ls\nqcm2290\nityuan@pd:~/ssd$cdqcm2290/\nityuan@pd:~/ssd/qcm2290$du-sh*\n8.0K\tabout.html\n0\tAndroid.bp\n85M\tart\n64M\tbionic\n218M\tbootable\n0\tbootstrap.bash\n24M\tbuild\n0\tbuild.sh\n3.4M\tcompatibility\n1.7G\tcts\n26M\tdalvik\n222M\tdevelopers\n150M\tdevelopment\n635M\tdevice\n4.0K\tdisregard\n7.1G\texternal\n1.9G\tframeworks\n81M\thardware\n1.4G\tkernel\n87M\tlibcore\n420K\tlibnativehelper\n4.0K\tMakefile\n186G\tout\n1.1G\tpackages\n3.4G\txxxdroid\n896K\tpdk\n16M\tplatform_testing\n32G\tprebuilts\n12K\tproduct\n4.0K\treadme.md\n232K\tresources.arsc\n30M\tsdk\n444K\tshortcut-fe\n8.0K\tsync.sh\n704M\tsystem\n408M\ttest\n16K\tTEST_BP\n9.7M\ttoolchain\n704M\ttools\n6.9G\tvendor\n\n12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849
这里可以看到一个AndroidR的源码工程就将整个的ssd硬盘空间占满了，那么有什么办法精简呢。当然有了，我们可以对Android的out目录进行软连接，链接到其它的分区之中。说干就干！下面我来记录一下具体的步骤:
建立软链接目录，这里我建立在我的根目录下，如下:
ityuan@pd:~$mkdirout\nityuan@pd:~$lsout/\nityuan@pd:~$\n123
建立软链接(对于建立软链接还有不是很熟悉的读者，可以参见博客Linux下创建软链接）
ityuan@pd:~$ln-s/home/tangkw/out/home/tangkw/ssd/qcm2290/out\nityuan@pd:~$cdssd/qcm2290/\nityuan@pd:~/ssd/qcm2290$llout\nlrwxrwxrwx1tangkwpd16Jan516:54out->/home/tangkw/out/\nityuan@pd:~/ssd/qcm2290$\n12345
并且在创建软链接中强烈建议使用绝对路径，否则会提示Toomanylevelsofsymboliclinks的错误
查看成果，查看我们创建的out软链接目录，是否成功，如下:
ityuan@pd:~$cdout/\nityuan@pd:~/out$ls-l\ntotal12684\n-rw-r–r–1ityuanpd0Jan516:56Android.mk\n-rw-r–r–1ityuanpd160Jan516:59build-bengal-cleanspec.ninja\n-rwxr-xr-x1ityuanpd10Jan516:56build_date.txt\n-rw-r–r–1ityuanpd10Jan516:56build.trace.gz\n-rwxr-xr-x1ityuanpd1Jan516:56casecheck.txt\n-rwxr-xr-x1ityuanpd1Jan516:56CaseCheck.txt\n-rw-r–r–1ityuanpd0Jan516:56CleanSpec.mk\ndrwxr-xr-x2ityuanpd4096Jan516:59empty\n-rw-r–r–1ityuanpd39Jan516:59env-bengal-cleanspec.sh\n-rw-r–r–1ityuanpd0Jan516:56error.log\ndrwxr-xr-x3ityuanpd4096Jan517:00host\n-rwxr-xr-x1ityuanpd4309565Jan516:56microfactory_Linux\n-rwxr-xr-x1ityuanpd121Jan516:59ninja-bengal-cleanspec.sh\n-rw-r–r–1ityuanpd0Jan516:56ninja_build\ndrwxr-xr-x6ityuanpd4096Jan516:59soong\n-rw-r–r–1ityuanpd19743Jan517:00soong.log\n-rwxr-xr-x1ityuanpd8580360Jan516:56soong_ui\ndrwxr-xr-x3ityuanpd4096Jan516:59target\n-rw-r–r–1ityuanpd24970Jan517:00verbose.log.gz\nityuan@pd:~/out$\n1234567891011121314151617181920212223
接着查看下我们ssd目录占用空间大小，如下(可以看到out目录的大小已经为0了):
ityuan@pd:~/ssd$du-sh*\n75G\tqcm2290\nityuan@pd:~/ssd$cdqcm2290/\nityuan@pd:~/ssd/qcm2290$\nityuan@pd:~/ssd/qcm2290$\nityuan@pd:~/ssd/qcm2290$du-sh*\n8.0K\tabout.html\n0\tAndroid.bp\n85M\tart\n64M\tbionic\n218M\tbootable\n0\tbootstrap.bash\n24M\tbuild\n0\tbuild.sh\n3.4M\tcompatibility\n1.7G\tcts\n26M\tdalvik\n222M\tdevelopers\n150M\tdevelopment\n635M\tdevice\n4.0K\tdisregard\n7.1G\texternal\n1.9G\tframeworks\n81M\thardware\n1.4G\tkernel\n87M\tlibcore\n420K\tlibnativehelper\n4.0K\tMakefile\n0\tout\n1.1G\tpackages\n3.4G\txxxdroid\n896K\tpdk\n16M\tplatform_testing\n32G\tprebuilts\n12K\tproduct\n4.0K\treadme.md\n232K\tresources.arsc\n30M\tsdk\n444K\tshortcut-fe\n8.0K\tsync.sh\n704M\tsystem\n408M\ttest\n16K\tTEST_BP\n9.7M\ttoolchain\n704M\ttools\n6.9G\tvendor\nityuan@pd:~/ssd/qcm2290$\n1234567891011121314151617181920212223242526272829303132333435363738394041424344454647
大功告成，当然如果读者是土豪公司，那这个就可以跳过不看了。
五.Android为啥要引入动态分区
??在前面我们简单说了下动态分区的概念，即在AndroidQ以及以后得编译包中，我们找不到了对应的system,vendor等img文件，但是多了一个super.img，system，vendor，product，ODM合并为super分区，这个就是动态分区了。简单来说就是为了在ota的时候能够灵活创建分区和修改分区大小，将system,vendor,odm,product合并成super分区，并在super分区上预留出一定量的freespace，这样就可以动态调整这些分区的大小，解决了ota的时候分区不足，以及调整分区的风险.。
当OTA升级之后，需要重新调整分区大小：
码字不易，觉得对你有帮助的话记得收藏顺便小编点个赞哦^_^
好了，文章到这里就结束啦，如果本次分享的主题源码分享免费下载网站和找主题源码问题对您有所帮助，还望关注下本站哦！