前言
做了这么多年的应用层和架构的工作，突然转到系统层还是有些不习惯的。最让人难受的就是不能用AS直接构建运行系统层的app，每次在AS上写完代码，都要同步到系统源码中去，然后配置好mk等文件，从系统层上去执行编译，最后再把编译好的apk push到system中去。既繁琐，又容易出错。后来我就琢磨着，是不是有一种方法可以让AS直接构建并且运行系统层的app呢，答案是可行的。
准备工作
要想让AS构建运行系统层app，首先得让当前的系统app已经可以在源码中编译过才行。否则都是免谈。
1.framework.jar
当我们成功编译过一次源码后，先找到未压缩过的framework.jar。
framework.jar的位置：out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar
注意：一定是common下的目录，不是product下的，别找错了
这个classes.jar就是我们要的，复制一份到AS的lib里，改名为framework.jar。并在build.gradle里配置引用方式为：compileOnly
2.Android.mk引用处理
系统层app还是用的跟以前eclipse的构建目录一样，Android.mk或者Android.bp的方式，会引入一系列的组件，包括静态库：Androidx相关，和一些jar包或者aar。其中jar包和aar比较好处理，直接迁移到AS的lib下就行，但是一些静态库怎么办？总不能也迁移到AS下，然后创建个module吧？
实际上module还真得创建，但里面也只是放一些res资源罢了
那java代码又该怎么处理呢？
有两种方式，分代处理和集中处理
所谓集中处理，是忽略掉app内引入的lib，以成品app为目标分析，引入对应资源
res处理
以Launcher为例：
首先找到Launcherapp的mk，查看res资源引入情况：
发现是分别引入了car-media-common和car-apps-common两个静态库的资源，那我们首先要做的就是先把这两个库的资源引入。
以下图的 car-media-common 为例：
首先AS里创建一个module：
然后找到源码中
car-media-common 的位置：
将标红的res全部复制到到创建的module中，然后app引入即可。
PS：系统lib一般不会存在资源相互引用的情况，大家尽量去检查下lib下的Android.mk文件，看看有没有引入其他res的，如果有，步骤同上。此处仅是资源，非java代码
重复上面操作，直到所有的资源全部引入为止。
java代码处理
接下来处理Android.mk中引入的库java代码，找到已经编译好的Launcher目录：
复制一个这个
classes.jar，以压缩包的形式打开：
除了标红的部分，其余的全部删除，一个不留。
再然后，把com里的关于Launcher的编译后的代码全部删掉，删完后引入到AS里，此处需要注意，使用implementation 引入
PS1：如果有aidl生成的class文件，建议保留，否则AS可能因为部分引用问题无法生成
PS2：如果AS的lib里引入了一些jar，而这些jar也是从源码里复制过来的，那么记得删掉classes.jar里相关的类，否则会报重复引用的异常
上述步骤很繁琐，稍不加注意可能就多删或者少删了，记得多备份。
3.编译
当你执行build命名后，不再报包引入重复的错误后，就可以进行到第三步--编译过程了。编译过程中，也会有很多问题，比如2步骤里操作不当，多删了某些类或者少删了，就要重复2步骤。
当我们点进去后看到
实际上这个类是在我们引入的framework.jar里面
那怎么才能让AS编译优先使用我们自己framework.jar里的类呢？
答案是：BootStrap class扩展方案
Java 命令行提供了如何扩展bootStrap 级别class的简单方法.
-Xbootclasspath: 完全取代基本核心的Java class 搜索路径，不常用，否则要重新写所有Java 核心class
-Xbootclasspath/a: 后缀在核心class搜索路径后面，常用
-Xbootclasspath/p: 前缀在核心class搜索路径前面。不常用，避免引起不必要的冲突。
-Xbootclasspath/p看描述可以解决我们的问题，让framework.jar的文件优先于SDK的文件编译，尝试一下。编写一个task：
gradle.projectsEvaluated {
tasks.withType(JavaCompile){
options.compilerArgs.add("-Xbootclasspath/p:libs/frameworks.jar")
}
}
添加到app下的build.gradle后，再编译
完美，通过编译。
回头再次查看刚刚报错的代码：
PlayPauseButton发现依然爆红，但却不影响编译。只是对于一个有编译癖好的人来说，这点红都接收不了，再写个task吧。
task pushDownJdkDependency {
def imlFile = file(".idea\\modules\\app\\Launch.app.iml") // 注意，要替换成自己项目中生成的iml目录
println 'Change OPSafe.iml order'
try {
def parsedXml = (new XmlParser()).parse(imlFile)
def jdkNode = parsedXml.component[1].orderEntry.find { it.'@type' == 'jdk' }
parsedXml.component[1].remove(jdkNode)
new Node(parsedXml.component[1], 'orderEntry', ['type': 'jdk', 'jdkName': "Android API 30 Platform", 'jdkType': 'Android SDK'])
def writer = new StringWriter()
new XmlNodePrinter(new PrintWriter(writer)).print(parsedXml)
imlFile.text = writer.toString()
} catch (FileNotFoundException e) {
// nop, iml not found
}
}
将此task放到工程下的build.gradle中就可以了，不需要执行，每次编译会自动走这个task一次，再次执行一次build：
已经不再爆红了，完美。
4.运行
虽然已经可以编译通过了，但别高兴那么早，此时的apk是无法直接安装到系统上的。我们先运行一次看看：
意思是说我们的版本太低了，无法覆盖安装。那简单，随便升下版本：
改成100，再跑一遍：
简而言之就是签名问题，也比较好理解，毕竟我们这是系统层app，使用的是系统签名，而用AS编译运行的是默认的debug签名，肯定是不行的。
解决办法也简单：就是用系统签名替换我们的签名，就可以了。
首先，先生成一个我们自己的签名，AS创建一个就行，我们命名为
launch.jks
其次，找到系统的签名
把这俩复制出来，再然后，使用keytool-importkeypair工具将我们生成的签名用系统签名重新签一次，因为走的shell，建议直接在ubuntu虚拟机里搞，我试过在win上签名，会失败的。
./keytool-importkeypair -k launch.jks -p 111111 -pk8 platform.pk8 -cert platform.x509.pem -alias launch
-p 后面的是密码
搞定，签完后给Launcher项目设置下签名再运行一次：
安装成功，
结语
总的来说，问题不是很难，就是过程比较复杂，中间各种各样的小问题频繁的冒出来，需要耐心和探索研究精神。这下终于可以愉快的写代码了。
