Android平台智能终端开机定屏问题研究与分析

王余雷 童向杰

（中兴通讯股份有限公司 江苏省南京市 210012）

1 引言

随着智能终端和移动互联网络的技术发展,智能终端得到越来越广泛的使用，且其功能变得越来越复杂。对于智能终端开发人员来说，智能终端的稳定性是衡量产品质量的一个重要指标:在产品开发、测试和生产等过程中，开发人员需要进行单元测试、MTBF、老化测试、模糊测试、系统测试、模拟用户测试等；在产品售后维修等过程中，开发人员需要进行客退故障样机进行剖析和质量回溯，并且将相应的成果及时地应用到后续产品的版本演进和流程优化等。基于此，本文提出了从软件和硬件(含部件)两大维度进行稳定性问题分析的策略，侧重于以Android平台智能终端的开机定屏问题为对象进行了深入地研究和剖析，以及进行了方案验证，从而给开发人员呈现一个较为全面的参考。

2 研究方案

Android平台智能终端的稳定性问题有多种多样，比如:无法开机、开机黑屏、开机定屏、反复重启，等等。本文提出了从软件和硬件(含部件)两大维度进行稳定性问题分析的策略，并且此策略可能不局限于Android 平台；本文侧重于以Android平台智能终端的开机定屏问题为对象进行了深入地研究和剖析，对某项目的小概率开机定屏问题和某项目的PMIC 受损问题进行实例分析和验证，从而给开发人员呈现一个较为全面的参考。

一般来说，开发人员分析解决智能终端稳定性问题，可从软件和硬件两个维度进行分析和方案检验（参见图1）。

从软件方面进行着手分析，首先，尽可能地第一时间获取到发生故障时更为全面的日志信息，如Android 系统和内核打印信息，ramdump，coredump，串口打印信息，发生段错误时backtrace 信息，等等；在获取日志信息后，根据时间戳或关键字符串可能会快速定位到故障现场，再结合异常打印信息和模块设计逻辑进行分析和推测等，这就是所谓的日志分析法。通常来讲，大部分问题都能从日志信息中发现蛛丝马迹，尤其是软件原因所导致的问题。若开发人员可从日志文件中分析出指向性的结论，则接下来就可对相应模块的程序设计进行原因分析与方案求证。其次，若开发人员较难地从日志文件中得出指向性的结论，则尽可能地获取到故障样机，然后进行现场诊断：为了快速定位问题，通常开发人员会在版本中集成一些的工具，如:应用镜像文件完整性检查、刷机版本有效性检查、内存模型测试、部件功能自检等；还可考虑从故障样机中导出userdata 镜像文件后再烧录至另外一台样机，检查是否可再现故障；还可考虑插入USB 数据线或按键，观察故障现象是否有变化，等等。这就是所谓的现场诊断法。接着，开发人员需要厘清一下该故障是单机问题还是多台样机共性问题，尝试去探索出故障复现规律或评估粗略的复现概率。对于可复现的故障，开发人员可考虑恢复至默认的出厂版本，观察故障现象是否存在；或者烧录不同版本进行对比分析与回溯，观察故障现象是否存在。这就是所谓的版本对比法；为了提升复现概率，开发人员可考虑进行MTBF、Monkey、常温环境下eMMC 和DDR 压力测试、高温低压环境下eMMC 和DDR测试、定制化的自动化测试等，观察在哪些场景下或哪条操作路径下可更高概率地复现故障。这就是所谓的压力测试法；为了求证所推测的异常点，开发人员还可考虑在源代码中增加打印语句或统计信息进行打点分析。这就是所谓的打点分析法。而对于推测求证法，通常是凭借开发人员的经验进行大胆推测，然后进行逻辑严谨的求证，其分析方法贯穿于问题分析的核心过程。最后，开发人员可考虑组织关联的领域专家进行集中讨论和诊断，再针对每项可能的原因或举措进行求证。这就是所谓的专家会诊法。

图1

若从软件方面较难地得出具有指向性的结论，开发人员则可考虑从硬件方面进行着手分析，首先，通过假电池连接安捷伦直流电源进行开机过程中不同阶段的电流测量，分析其电流值是否异常，若存在明显的异常，则可能存在硬件受损而导致漏电等问题。这就是所谓的电流分析法。接着，对于可复现的故障，开发人员可分两个阶段进行硬件最小系统的构建：第一阶段，拆除部件外设和拔掉SIM 卡、SD 卡等，观察故障现象是否存在；第二阶段，针对某一块故障单板进行在板器件的拆除，仅仅保留CPU、内存和PMIC 等硬件最小系统，再观察故障现象是否存在。这就是所谓的最小系统法。再者，开发人员可对发生故障时单板的器件或部件的管脚进行信号测量与记录，同时对正常工作时单板的器件或部件的管脚进行信号测量与记录，两者进行对比分析；为了求证最小系统的eMMC 和DDR 功能性，开发人员可采用烧录版本至故障样机，确认其下载或开机等功能是否正常；为了求证最小系统的可见的器件焊接等问题，开发人员可使用风枪进行短暂加热，观察故障现象是否存在；为了求证最小系统的供电问题，开发人员可考虑采用外供电源的方法，观察故障现象是否存在；等等。然后，若硬件最小系统仍然存在相应的故障现象，则需要产线人员参与分析是否与主板或最小系统的CPU/eMMC+DDR/PMIC 等有关，可考虑采用交叉验证法、X-Ray 检查法、切片分析法、红墨水实验法等。最后，开发人员可考虑联络平台厂家或者eMMC+DDR 的原厂，对于可能与eMMC+DDR 有关的问题，则可考虑让原厂安排技术人员现场支持，并且安排故障样机的单体功能测试和单板的DDR 夹具测试，确认单体功能是否正常和DDR 的时序及眼图等是否正常。

开机定屏，是指智能终端在开机的过程中，出现长时间停在一个界面上而无法正常进行操作的问题现象。一般来说，在开启日志打印情况下，开发人员可获取智能终端开机过程的日志信息，就可定位开机启动至哪个阶段发生故障现象。开机过程可粗略地划分为四个阶段：

（1）BootROM 启动至Bootloader；

（2）Bootloader 启动至Kernel；

（3）Kernel 加载文件系统和system_server 主服务等；

（4）system_server 等服务加载运行各个应用等。

当开机启动至Bootloader 阶段，具有开发经验的人员可推测与硬件相关性更大些；当开机启动至system_server 主服务阶段，表明外设驱动基本功能正常，从而可推测与关键文件损坏或版本烧录异常导致版本不完整等，或者与硬件受损导致漏电有关。

3 实践分析

MTK 平台某款智能手机发生小概率的开机定屏问题，其分析思路是: 首先，从软件维度来看，获取到故障样机，采用现场诊断法进行常规的诊断，通过组合按键进入Recovery 模式，执行应用镜像文件完整性检查、Root 检查等，其测试结果正常；通过特定的操作进入工程模式，执行memtester 内存模型测试等，其测试结果正常；然后开启日志打印功能。再次重启开机，该故障仍然存在，抓取从开机启动至定屏整个过程完整的日志信息。根据日志信息初步分析的结论是: Kernel 启动正常，而在系统服务启动时发现如下的异常打印信息:

从上述的异常日志信息和JAVA Stack 来看，表明系统服务PackageManager 解析xml 文件时发生严重的错误。因而，将故障样机中所解析的packages.xml 或packages-backup.xml 文件导出，通过查看和比对相应文件的内容，确认是packages.xml 文件损坏导致xml 解析错误，进而导致Android 平台的系统主进程system_server无法正常启动，从而表现为开机定屏的问题现象。至此，基本上即可得出了指向性的结论，进而可大胆地推测与eMMC 和DDR 或者文件系统有关。其次，为了排查是否与eMMC 和DDR 电气特性有关，进行了ETT 高温低压等场景下的压力测试，使用了FlashTool工具的Memory Test 功能测试等；同时组织硬件领域专家进行会诊和走查原理图、布线等，其结论是测试等正常，暂未发现设计问题。接着，为了提升分析效率和快速验证方案有效性，需要尝试增加复现概率或找出复现规律，协调测试人员参与安排该项目的MTBF测试、CTS 测试、Monkey 测试和模拟用户测试等，通过压力测试发现了发生同类型的故障的样机，由此，表明该故障是可复现的。同时开发人员对packages.xml 文件生成原理进行了研究:该文件是由PackageManagerService.java 生成，其文件内容记录了Android 系统中所安装的APK 应用程序的所有属性、权限等信息，当Android系统安装、卸载、更新APK 应用程序时，packages.xml 文件都会被更改。从而，开发人员发现了一个非常有价值的突破口:通过自动化脚本实现反复安装和卸载APK 应用程序，以达到packages.xml文件被反复更改的目的，进而可能达成增加复现概率。其方案是:利用Android 平台monkeyrunner 测试框架和Python 语言编写自动化测试脚本，实现安装APK 应用程序后重启智能手机，并且将启动路径下不同阶段的packages.xml 导出至电脑端；然后选取三部故障样机进行了压力测试。其结果是以约2%概率复现了该故障。再者，考虑采用推测求证法，根据以往的故障经验进行大胆地推测和小心地求证，推测是否可能与内存数据未能完整地同步至eMMC 有关，为此，优化自动化测试脚本在特定阶段通过Python 脚本调用sync操作，求证故障现象是否存在；其结果是测试10000 次，未复现故障，至此，问题根因有了更为明确的指向性，其原因大概率的是与软件（含固件）配置有关。最后，开发人员采用版本对比法进行了不同的版本和不同eMMC+DDR 厂家的对比测试，开发人员求证了某两个时期版本故障现象存在差异，进一步地了解到MTK 平台近期文件系统增加了discard 属性配置，研究了JEDEC 规范中discard 属性，其要点是执行discard 时要防止意外的数据丢失；同时还求证了采用三星厂家的芯片不存在此问题，开发人员和Hynix 原厂技术支持进行沟通，了解到该款芯片的某固件版本存在设计缺陷，未能正确地处理discard 属性配置。至此，问题的根因是与Hynix 芯片的某固件版本未能正确地处理discard 属性有关。考虑升级eMMC 芯片固件的成本，开发人员提出了最终的解决方案是MTK 平台去掉文件系统的discard 属性配置，针对此解决方案，进行了累计60000次的自动化测试，未复现故障。

4 结束语

本文提出了从软件和硬件(含部件)两大维度进行稳定性问题分析的策略，并且此策略可能不局限于Android 平台；本文侧重于以Android平台智能终端的开机定屏问题为对象进行了深入地研究和剖析，以及进行了方案验证，从而给开发人员呈现一个较为全面的参考。