BrokenVns

native 程序和 java 层程序是可以通过 servicemanager 进行 binder 连接的。
但是 apk 的 binder 一般是匿名 binder ，被 AMS 管理着，要通过 AMS 的接口才能找到对应的 binder 节点并获取。
直接搞个 Bpbinder 调对应接口的话，要实现的东西太多了，还要通过 AMS 的各种参数，进程检查，感觉很难。
我记得有 native app ，这块不了解，不知道能不能在进程了起个 native app 去实现相关操作。

补充下，zip 跨平台导致各个平台的 zip 工具在实现是有差别的，比如对软链接文件的支持和实现都是不同的。
你用工具 A 压缩的软链接文件用工具 B 可能会解压失败。
原因是 A 的实现方式是把链接地址作为内容存储在数据域，而 B 的的实现方式是把软链接地址存储在额外数据域里。

你应该先找本 Android 的书了解下 Android 系统。
Native 层的程序在 system/vendor 目录下，启动方式符合你的认知，但是操作这些可执行文件需要权限。
Java 层的程序就不一样了。笼统的说这些 App 程序都是通过系统中某个进程 fork 出来的，fork 出的子进程会去加载 App 的依赖库 /资源。这些 App 的资源压缩打包在一起就是 Apk 。安装在 /data/data/目录下，没有权限也是无法访问这个目录的。
如果是想自动化安装删除 App,应该用 adb install/uninstall 命令，启动的话通过 Adb shell am start 命令.

抱歉各位，已经满了。

MessageQueue 并不是只轮询了 eventfd,MessageQueue 的 Native 实现还能额外监听 16 （没记错的话）个 FD，而且这 16 个事件 FD 的处理优先级比消息队列里的消息更高。要我说原本就是设计了一个多路复用的事件处理器，并使用其中一路实现了消息队列功能。这种设计在很多开源库里都能看到。既然 Native 已经实现了一个好用的组件，那么 Java 层的 MessageQueue 通过 JNI 复用这些功能也是合情合理的。MessageQueue 整个组件的功能并不止应用开发者用到的那点，系统服务比如 surfaceflinger 就需要监听额外的事件。

能申请经费的话，2000-3000 买块 Android 推荐的开发版（ https://source.android.google.cn/setup/build/devices ）或者弄台 M1(最快的 Android 模拟器)。源码编译的话我觉得可以考虑使用 cuttlefish 替代 QEMU,我自己的体验来说 cuttlefish 版比 qemu 版快一些。https://source.android.google.cn/setup/create/cuttlefish

查你用的 JSON 库的文档，看看有没有提供泛型相关的支持。比如 Gson 会提供 TypeToken 。也可以去参考类似 GSON 等库的实现。

1.Google 不是厂家的直接上游，厂商的代码是从高通 /MTK 拉取的，有问题有需求给高通 /MTK 提 Case,高通 /MTK 提供 Patch 后，厂家 merge 。
2.老项目的大版本更新是很烦的，对于上层开发（驱动以上）来说，基本上就是新项目了。
3.国内型号太多了，人员是有限的，主力都是投入到新的旗舰项目上。没几个人愿意维护各种型号的老项目，更何况非旗舰型号的多半是外包出去的。
以上不一定正确，基于个人认知。

再启动一个日志进程，通过 socket 把每个进程的日志发送过去，由日志进程汇总打印。