历时四年,Google终于修复了一个我发现的Android Framework Bug
2014年在做一个Android终端设备开发过程中,发现了一个Android Framework层的Bug,给Google提交了issue和解决方案,和外界传言一致Google一般不太在意个人开发者提交的issue,直到2017年12月,再次提交了issue,在几轮沟通无果下,忍不住喷了Google几句后,终于该issue被转交给了Android development team处理,又经过快三个月的时间收到了下面的答复:
google issues:https://issuetracker.google.com/issues/70016687
issue背景:
在对我们自己研发的一款Android终端设备进行Camera拍照压力测试时,发现当拍照张数达到数万张时,出现OOM,导致系统崩溃。
issue分析解决过程:
该项目为开发一款Android工业终端设备,采用TI芯片方案,由于芯片方案商支持不够完善(主要TI被高通打的放弃了移动端芯片市场),Camera的HAL层需要我们自己移植适配。
分析思路:
首先看下Android系统架构图中中Camera功能模块的分布情况,从App层->Framework->HAL->Kernel一路下来:
(图片取自https://blog.csdn.net/asd1031/article/details/53699867)
- 首先怀疑测试app自身存在内存问题。
- Android application Framework,libraries层和jni相关模块是经过Google大量验证的模块,出现问题的概率比较小,暂时排除。
- 怀疑HAL层移植问题。
怀疑1:测试app问题
压力测试app由测试同学开发提供的,该app每隔3s触发一次拍照操作,并对拍摄的照片进行清理,以达到拍摄10万张照片的测试目的。基于以上分析,为了排除测试app问题,采用Android原生Camera app进行压力测试,编写monkey测试脚本,触发原生Camera app拍照,进行压力测试。(此处遇到的问题是:如何实现对照片的清理工作,直接触发shell环境下rm操作,并不会清除Android内部文件缓存索引,拍摄几千张照片后仍然会导致存储空间用尽,解决此问题也耗费了点时间,不过不是本文的重点,此处不做展开)
结果:通过原生Camera app进行测试后,仍然出现内存泄漏,此处基本排除测试app的问题。
怀疑2:HAl层
基于之前的分析,我们把怀疑对象聚集在我们自己集成的Android HAL层,在分析之前,简单描述下Android Camera拍照的流程:Linux Kernel提供标准的v4l2接口,供上层(此处即为HAL)获取图像原始数据,HAL层拿到图像数据进行编码(一般为jpeg),回调给Camera service。其中Linux Kernel下Camera驱动和HAL适配层一般由芯片厂商提供,其余部分由Linux Kernel和Android系统官方维护,开发。
这样对HAL的测试分为三步:
- 验证芯片厂商的Camera驱动是否存在问题。
- 验证HAL层图像数据捕获流程是否存在问题。
- 验证图像编码流程是否存在问题。
Camera驱动
Android系统是基于Linux Kernel开发,支持标准的v4l2接口,只需要编写一个简单的基于v4l2的视频捕获程序就可以验证camera驱动的问题,此处测试验证没有内存泄漏,排查驱动问题。
HAL层视频捕获流程
测试思路非常明确,难点在于要把芯片提供商的HAL层源码中进行视频捕获功能的模块剥离出来,单独进行压力测试。(由于原厂提供的HAL层代码,耦合比较严重,在不影响内部流程,结构的情况下,要找到适合的切面mock一些数据接口,才好进行有效的测试。)
经过以上的工作,进行了压力测试,系统未出现内存泄漏,基本排除HAL层捕获流程。
HAL层图像编码流程
继续对图像编码部分剥离,进行压力测试,发现内存泄漏,基本定位大概的泄漏位置,不过由于Android整个编码过程也进行层层的封装,泄漏位置还需要继续细致的定位,这样经过层层的细化,像剥洋葱一样一层层mock输入数据,最终定位在Android系统层的jpeg编码处理中:(frameworks/base/core/jni/android/graphics/YuvToJpegEncoder.cpp)
关于Android的jpeg编码:Android系统jpeg编码支持硬编码和软编码,如果芯片集成了jpeg硬件编码模块,会优先选择硬编码,而如果没有该模块,会采用软件的jpeg编码进行处理。
Android采用的软件编码库是业内知名的libjpeg库,而正是对这个库的使用出了问题:
bool YuvToJpegEncoder::encode(SkWStream* stream, void* inYuv, int width,int height, int* offsets, int jpegQuality) {jpeg_compress_struct cinfo;skjpeg_error_mgr sk_err;skjpeg_destination_mgr sk_wstream(stream);cinfo.err = jpeg_std_error(&sk_err);sk_err.error_exit = skjpeg_error_exit;if (setjmp(sk_err.fJmpBuf)) {return false;}jpeg_create_compress(&cinfo);cinfo.dest = &sk_wstream;setJpegCompressStruct(&cinfo, width, height, jpegQuality);jpeg_start_compress(&cinfo, TRUE);compress(&cinfo, (uint8_t*) inYuv, offsets);jpeg_finish_compress(&cinfo);return true;
}
坑就在上面这个接口函数中:
熟悉libjpeg的同学可能会注意到,上面的接口在调用完jpeg_finish_compress()后,没有调用jpeg_destroy_compress(),这个接口是释放压缩工作过程中所申请的资源,就是代码中的cinfo结构,该结构只占十几个字节的内存, 这样就导致了每拍摄一张照片,就泄漏一个cinfo的内存,当拍照数量达到万级时,才会有所察觉。
对这种数据流的控制,pipeline方式是比较好的方案,因为可以明确输入输出,这样非常方便通过伪造输入数据对各个模块进行单独的压力测试,最难控制的就是“洋葱”式的包裹调用,要像“剥洋葱”一样一层层的剥离,找准切面十分麻烦。
这个bug是否影响到你的Android手机
七成的概率下你的手机应该不会有这个问题,即时有这个问题你也很难发现这个问题,因为上面讲到android系统有两种编码方式选择,优先使用硬件编码模块,如果没有硬件编码模块,才会使用软编码的方式,而目前大部分中高端的芯片方案都集成了硬件模块,只有在少数低端芯片上才会使用软编码的方式,并且即使你的手机没有硬编码模块,用的软编码,也很难遇见这个问题,因为对于普通用户,持续拍摄上万张照片是不太可能的,第一受限于手机的存储空间(一万张照片,至少要30G的空间),第二即使能拍摄上万张照片,但要保持手机一直工作不重启也还是比较苦难的(总会死个机啥的)。
哈哈,这么一说发现这个bug其实是一个不会发生的bug了!!!不过我们之前的产品,定位于工业级别,对图像采集有比较高的要求,所以制定了10万张照片的测试标准,也就让我发现了这个不会影响到大部分人的bug。
最后再吐槽下Google
改bug我在2014年就已经提交了issue,不过没持续关注,过了几个月被莫名其妙的关闭了,当时没有在意,不过当Android 6.0,7.0版本出来时,我都看了下这个bug,一直存在,所以在去年(2017年)12月份又提了一个issue,Google方面的处理人仍然各种推诿扯皮,最后我没忍住喷了几句,这次Google方面回复会转给开发团队处理,终于在今年(2018年)给出了fixed的结论。