进展:
z18 mini 的mokee 移植任务于2019年9月30号交付, 截止10月中旬测试, 主要修复了诱发过程不上数的问题, 长短信诱发问题. windows下usb识别的问题, 目前系统满足诱发功能使用, 可视为趋于稳定, 该系统目前仍存在问题, 摄像机录像功能暂不可使用(拍照功能正常).
由于前几周, 数传终端和主被结合项目的维护工作优先级更高, 期间断断续续整理了此次移植过程中的笔记, 资料, 至本月附上总结一并分享.
结果:
本次rom移植已带来的可见好处:
1. 短信诱发效率更快, 可护展性更高, 更新PDU已解耦在上层可控, 若PDU方案有更新需求, 可以做到只升级pda即可, 而不必去升级rom.
2. 源码可控, 可以应对更复杂的需求, pdu方案更新解耦应用是如此, 电话拨打诱发挂断的问题解决也是如此, 挂断功能甚至可以做到安全挂断, 而不用去多次试验校准挂断时间. 同时可控性强也不用局限于xposed方案的更新速度.
3. 可兼容性, 同一个rom 也可以与xposed兼容, 当作xposed方案的备选rom.
4. 可以与公司产品融合度更高, 无论是技术保障, 品牌文化, 还是产品体验上都有更多的可能待发现.
存在的蔽端:
1. 工程复杂, 涉及到的知识多, 学习周期长, 导致移植周期较长, 这个问题可随着技术的积累, 逐渐有所改善
感想:
本次z18 mini 的移植, 极大地增强了对 rom移植 方案的信心, 后续的rom 移植, 虽说工期长, 但是随着技术的积累, 风险相对来说降低了.
在android 9.0 后续的版本上, 谷歌对 aosp 系统升级方案 有了较大的调整, ROM 的移植工作可以减少对于vendor方的驱动库适配, 因为treble project 技术将厂商的升级与系统的升级解耦了. 后续的移植工作主要精力放在kernel 适配, 驱动配置编译, device 资源覆盖, 启动脚本配置上, 同时也可以减少shim层的适配的工作.
本次移植的整个rom 适配的流程: 找到合适的内核编译 -> 验证编译出的内核可用性 -> 编写 device 编译信息与资源覆盖脚本 -> 编写vendor下的资源覆盖脚本 -> 编译工程 -> 刷机验证rom -> 测试每个功能, 修复问题.
涉及到的关键技术点: kernel 的编译, kernel项目的构成, 针对手机硬件, 驱动配置与启动脚本的编写, 整个mokee/aosp项目的结构, 各模块功能, 编译系统及脚本语言, 通过编译命令入手, 搞懂适配的工作流程, selinux, avb 校验, 刷机原理, android 引导及启动流程, kernel 打补丁, vndk 框架, trebl project 技术, 等等, 大部分技术点知道怎么回事即可, 方便于编译脚本的调试, 遇到问题, 找到解决方向.
此次移植过程, 在recovery上也吃过不少亏, 像z18mini 官方rom v224 以后的版本, 通过第三方的recvoery 就不能直接刷机, 必须通过官方的recvoery刷机, 但是官方的recovery除了升级自身的rom, 没有其他作用, 这增加了刷机的流程, 因此也尝试去简单适配了下twrp 的recvoery移植, 有了rom 适配的经验, revoery工程的跑通就容易的多, 目前已经twrp的工程正常可用, 但是功能较少, 缺少root功能, 缺少汉化, 缺少其他高级功能. 后续可以按需再移植recovery而不必局限于第三方rom.
bootloader 与 fastboot, 刷机的基本工具也很重要, bootloader 是引导程序, 由手机soc刷入, 角色类似于uboot, grub, mbr, 目前还没有找到合适的途径去刷bootloader, fastboot是aosp工程中自带的与bootloader通信的工具, 本次刷机中, 也遇到fastboot 不可用的情况: 在ubuntu 16.04 lts 系统上 fastboot对于小米8, 小米6x, 努比亚z18 mini不可用. 而用第三方recvoery制作者提供的fastboot 就可以用, 此问题也暂未解决, 目前每次刷机还是将编译好的recovery.img移到windows上刷机, 影响了rom验证的效率. 初步定位应该是手机厂商对 bootloader 做了修改, 应该需要对fastboot做出相应的调整, 后续研究fastboot源码, 以期解决.
内核知识的学习, android 的内核是基于linux的内核做了一些修改, 而ROM移植工作出现在的问题主要集中在三个部分: 基于适配机型的整个工程的编译, 编译出的ROM刷机点亮, 点亮后的系统正常工作. 后两部分遇到问题的突破点大都是与内核相关, 因此整体学习一下linux内核的工程架构, 也是很有必要. 本次的解决办法就比较投机, 是基于同型号的已移植的内核, 通过工具对比打出差异补丁, 反复编译内核, 试验解决问题的, 这种做法虽然投机, 但是很被动, 若是没有参考的同型号已移植内核源码, 就无从下手, 最根本的解决办法还是攻克内核的配置与编译.
没有学不会的技术, 是本次ROM移植过程中比较深的感触, 个人的精力是有限的, 这是客观事实, 但是不能因此成为畏惧未知的理由. 有些知识, 没有精力去深研, 但是得了解个大概是非常有必要的, 见得多了至少会在遇到问题的时候提供更广的方向, 思路去解决问题, 同样也可以为团队协作减少技术的沟通成本. 技术学到最后, 孤立的知识点都会以某种形式连成面, 这种形式或是视觉形式的产品, 或是思维形式的流派, 或是项目工程的架构.
后续计划:
继续维护后续系统可能出现的问题, 关注下一款机型的选型, 待命ROM移植, 将整个 rom 的移植流程逐渐规范化, 建设rom 相关的技术积累.