支持一下!

如果说 app 是 android 前端，那 Framework 就是后端，主要就是开发各种服务给 APP 用。方向可以考虑优化和稳定性或者单一的某项服务，比如 AMS,PMS,图像系统,BT,WIFI,RIL 等。
职业发展肯定就是朝着系统架构师或者单一方向的专家。
上面说去 android 化，我不觉得国内能从头开发一套不一样的系统，基本上还是基于 Android 的各种深度魔改。
另外即使要开发新系统，招的不还是原来做 Android 系统的这些人吗。

最近在用，用着还不错。有个关于左侧目录的问题，能限定某个目录范围吗？比如我只想展示当前用户下的目录文件，而不是根目录下的文件。没有看到相关说明，或者会考虑该功能吗？

@beisilu
我可以给你点参考，华为内部不清楚，我们这维护系统自带应用的都是新人和就喜欢做这个的老人。
因为维护原生系统应用没有发展空间，真有问题都要往底层服务去查，慢慢的就转向底层去了，这种出来转行做 app 也不会太差。
或者有的团队会重写或魔改应用（尤其是面向用户的系统应用），这种都是按照主流技术栈来的，做 APP 没问题。

当然留不留还是要看你们找人的定位，比如招个初级工，能干活就能打杂就行了。

让我想到 system 组一些负责 setting app 的同事。平时就是一些读写系统属性，数据库和本地化的工作。即不往底层发展，也不更随市场 app 的主流技术学习，出来的话应该就是你说的样子。

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 把每个进程的日志发送过去，由日志进程汇总打印。

广播是基于异步 binder 的，异步 binder 存在以下小问题：
1.能够传递的数据量是同步 binder 的一半（ 0.5M-4K ）.
2.异步 binder 的消息传递优先级不高，可能会出现广播接收延迟问题，这种现象在 binder 流量大的老机器更明显。
3.你不知道异步 binder 传递是否成功了，碰到过通信失败而引发的 ANR 问题。
广播自身也有些小问题，比如广播要先发送给 AMS 再由 AMS 进行分发，跨了两次进程,广播是透明的等。

少量使用动态广播，可以减少开发量。
大量使用异步通信的话，还是建议使用 Looper-Handler 、开源库或者造轮子

源码里本来就有 ServiceManager 这个类，你调用的是源码里的类和方法吧。你自己的修改应该没有成功吧。
至于 getService 方法会返回 BinderProxy 是因为：
1.getService 方法中会调用 Parcel 的 readStrongBinder 方法。
2.readStrongBinder 会在通过 jni 调用 Parcel(c++)的 readStrongBinder 获取对应 service 的 BpBinder
3.接着构造 javaObject(BinderProxy)。
4.将 BpBinder 的地址存 BinderProxy 的变量中后将 BinderProxy 返回给 readStrongBinder,最后返回给 getService。

@gramyang 你的 run()是在 ConnectThread 类里直接重写的吗？
我见过有人这么写的：
t = new Thread(()->{
synchronized (this){...}
});
synchronized (t){...}
上面这种情况就把对象混淆了。
如果不是我猜的这种情况，你多加点 log 看看，要不试试第 3 条。