高通ais over hab高概率导致安卓系统起不来原因分析及解决方案

一）ais概述

1. 高通8155的摄像头驱动在hostOS qnx上，guestOS 安卓要使用摄像头，就需要就需要通过hab机制与qnx通信。?
2. Ais框架如下

? ? ??

二）ais的控制通道与数据通道

???????? a)控制通道即，front end需要将start/stop摄像头的控制命令发送给back end。数据通道即，back end将摄像头数据存放的地方，这个地方同样需要俩端可以访问。控制通道的共享内存是在固定的一块内存上面（hab的physical channel）。但是数据通道却不是。

???????? b)ais的数据通道的建立。安卓端会从ion申请dma_buf（一个buf存放一帧数据）,然后会将dma_buf的物理页帧号告知qnx,然后qnx端就可以将摄像头数据放到这块内存上，再通过控制道通通知安卓端。数据通道建立源码如下：

???

调用到了驱动代码

-----------------------

上图exp是在physical channel共享内存上的一个结构体struct export_desc。定义如下图：

habmem_compress_pfns函数会将dma_buf的物理pfn写到exp上，然后走控制通道通知到qnx端。

三）那么ais client进程异常crash为什么会导致安卓系统起不来。

????????原因在于ais的数据通道内存是安卓分配， client进程crash后，释放流程很大概率会先释放数据通道，再释放控制通道。如果数据通道释放后，这块内存又被分配给内核其他模块使用，但此时控制通道还没有释放，即qnx不知道数据通道释放了，他还往上面填充摄像头数据，导致安卓kernel panic。然后安卓重启后，qnx又不断再写数据通道，而数据通道的内存在安卓重启后又可能被分配给内核使用。导致安卓系统一直起不来。

1. 解决方案
   1. 修改内核代码，先释放控制通道，再释放数据通道，比较复杂
   2. 搞一个稳定的ais client hal服务进程。再暴露接口给app使用。
2. 安卓端硬解码hal服务，也是走hab机制使用qnx提供的硬编解码服务，为什么它不会导致安卓系统crash?

原因是它的数据通道内存是由qnx分配。如下图代码截图：

? ? ? ? 3.数据通道建立的俩个重要应用层接口注释如下：