引用系统隐藏接口的另一种方式
因为干了车载项目，app中常常用到系统隐藏接口，现公司中的项目
要么放在系统源码中编译，要么通过gradle脚本的方式引用framework.jar。
这两种方式都用很大的缺点，我找到了一个更好的方式。
目前的两种方式的缺点
源码中编译
通过app代码放在系统源码中，配置Android.bp的方式集成在系统中的缺点
- 在源码中编译想要使用第三方库是比较麻烦的，远不如在Android studio中方便。
- 在源码中编译的app使用IDE也比较麻烦，VS需要装插件，Android studio需要配置gradle，依赖库得同时维护两套编译方式。
- 最重要的是由于车载项目大多数时候系统版本落后，这就导致的app的编译版本落后，很多依赖库只能使用很老的版本，甚至一些库根本用不了。
gradle脚本
通过配置gradle脚本，修改项目中.iml中依赖节点的顺序来实现引用framework.jar的缺点
- 随着gradle和Android studio的版本更新，旧的脚本会失效，需要不断维护。
- 最新版本的gradle和Android studio已经没有.iml文件了，使用这种方式只能用旧版本的IDE和gradle
- 多个应用模块结构不同，需要多套脚本代码。
framework 打jar包给app
fw可以把需要的隐藏接口包装一层打成jar包给app使用
- 麻烦，一般这类工作都是fw人员去做，app和fw通常是不同的team，app需要哪些接口随着项目推进可能会不断增加，沟通成本高。
- 及时性，app要求增加隐藏接口调用时需要依赖fw人员，fw组有自己的工作，未必能及时提供。
- 有些项目fw是由其它公司负责，一般只提供framework.jar。
ps：没见过公司项目这么用过，估计是前两种方法都能实现，这个还需要额外工作，大家都不爱干。
使用自己的sdk
要解决以上问题，并且要尽量减少其带来的不便，我觉得目前最好的方式应该是使用自己的sdk。
fw组提供framework.jar，或者app有源码权限自行通过make framework命令生成framework.jar。
通过解压覆盖方式与sdk中对应版本的的android.jar合并，然后通过jar cvf命令重新打包android.jar。
ps：在源码中可以通过make sdk命令可以生成自己的sdk，但是我在项目中编译的时候报错了，可能是跟qnx或者骁龙平台相关的东西，我fw知识有限，没有解决。
这样新的替换的android.jar中就包含了framework中的修改和隐藏接口，如果同时应对多个项目的话，必要时创建多个sdk，通过项目中指定sdk路径。
那么最后一个问题就是之前提到的最重要的，由于车载系统版本通常比较落后，如何在落后的版本中既使用到隐藏接口又可以使用最新的依赖库呢。
版本兼容性的问题
以项目版本Android 12，API版本号32为例。可以单独创建一个共享的模块，指定共享模块的编译版本为32。那么在这个模块中就可以访问到系统的隐藏接口。
主模块和其它的模块中，编译版本可以指定为最新的，最低版本指定为32，需要使用隐藏接口时便依赖共享模块，由共享模块中对外提供包装后的隐藏接口。
包装代码风格参考Google的appcompat库，整个项目共用同一个共享库即可。
虽然增加了额外的共享库包装的工作，但是第一，这个工作一劳永逸，仅包装一层没什么逻辑，不需要反复修改。
第二，项目不会用到全部的隐藏接口，大多数app用到的接口都差不多，用到的时候添加，工作量不大。
引用系统隐藏接口的另一种方式