Android稳定性 63篇

linux/android稳定性文章

[Android稳定性] 第012篇 [原理篇] blackbox的原理介绍 11月前查看 7 条
[Android稳定性] 第012篇 [原理篇] blackbox的原理介绍

Blackbox 是一种日志管理方案，旨在解决当前日志分析和自动化解析的痛点，如日志分散、时间标准不统一、关键事件记录丢失、RAS 实现自动化分析困难等。Blackbox 将大部分系统日志集中在特定分区，具有时间线的流式日志，可读性更强。它还根据已有经验在系统运行的关键节点打点，提升上市后稳定性问题的定位效率。针对不同的日志，有不同的日志老化删除节奏，从而更多保存异常日志。Blackbox 还提高了 RAS 自动化分析的能力，并可在设备卡死时通过 9008 方式将日志分区 dump 出来并解析，辅助问题分析。

[Android稳定性] 第011篇 [原理篇] minidump的原理介绍补充 11月前查看 评论
[Android稳定性] 第011篇 [原理篇] minidump的原理介绍补充

这篇文章主要介绍了Android系统中的minidump机制，这是一种用于保存系统崩溃信息的技术。文章首先解释了minidump的概念，即各个子系统在内存映射表中注册，当系统崩溃时，boot subsystem会加密并保存注册过的内存信息到RAM EMMC分区。 接着，文章详细描述了minidump的流程图和代码流程，包括HLOS侧和NON-HLOS侧的流程。在HLOS侧，文章重点介绍了defconfig配置、相关代码以及msm_minidump_add_region函数。在NON-HLOS侧，文章重点介绍了add_minidump_regions函数和boot_ram_dump_to_raw_parition函数。 文章还介绍了小米项目在minidump中增加的regions，包括md_kmsg、md_pmsg和tz_log，并解释了它们的设计原理。最后，文章介绍了如何验证minidump，包括设置minidump到emmc、触发dump以及从设备中拉取minidump。 此外，文章还介绍了minidump.gz的解析方法，包括解压minidump.gz和拆分minidump。

[Android稳定性] 第010篇 [问题篇] 数组越界导致的内核panic 11月前查看 评论
[Android稳定性] 第010篇 [问题篇] 数组越界导致的内核panic

**摘要总结：** 服务器打包的daily版本在刷机后出现900E口死机问题。通过分析dmesg日志，发现程序在`fts_set_cur_value`函数处异常终止。进一步使用trace32工具恢复现场，确认是由于`touch_mode`数组越界导致的内存访问错误。该数组最大值被定义为15，但实际使用时传入了100，导致严重异常。

[Android稳定性] 第009篇 [问题篇] 数组越界导致的内核panic 11月前查看 评论
[Android稳定性] 第009篇 [问题篇] 数组越界导致的内核panic

**问题现象**： 部分机器插着 USB 后出现死机。 **问题分析**： 通过 `dmesg` 和 `trace32` 分析，发现死机原因是 `power_operation_mode_show` 函数中 `typec_port` 结构体的 `pwr_opmode` 成员值错误（为负数），导致数组越界。 **解决方案**： 更新 charger 模块，修复对 `pwr_opmode` 的误判，确保其值为正数，避免数组越界。 **总结**： 本次问题是由 `typec_port` 结构体的 `pwr_opmode` 成员值错误导致，通过分析定位问题，并更新 charger 模块修复了问题。

[Android稳定性] 第008篇 [原理篇] 动态设置kernel cmdline 11月前查看 评论
[Android稳定性] 第008篇 [原理篇] 动态设置kernel cmdline

本文介绍了一种在fastboot模式下动态修改内核参数的方法，无需重新打包。首先，通过扩展fastboot oem指令，接收输入的内核参数并写入到devinfo分区中。然后，在更新kernel cmdline时，将保存的内核参数添加到cmdline中。实验测试显示，该方案可以成功修改内核参数，并永久生效。代码更新后，支持设置、追加和清除模式，方便用户根据需求进行操作。

[Android稳定性] 第006篇 [问题篇] hungtask causing panic-死锁 11月前查看 评论
[Android稳定性] 第006篇 [问题篇] hungtask causing panic-死锁

本文讨论了一个系统问题现象，通过分析日志文件发现一个进程因等待锁而被阻塞120秒。通过使用`tace32`工具跟踪调用栈，发现存在一个三方的死锁情况，涉及进程`2848_9`、`crtc_commit:160`、`vendor.qti.came`和`kworker/u16:7`。文章详细展示了锁的持有者和调用栈信息，但未提供具体的解决方法。

[Android稳定性] 第003篇 [原理篇] mtdoops的原理介绍 11月前查看 评论
[Android稳定性] 第003篇 [原理篇] mtdoops的原理介绍

**mtdoops简介与原理总结** mtdoops是一种将系统崩溃时的日志信息保存到MTD（Memory Technology Device）设备中的机制，用于在系统panic时捕获关键信息。它利用MTD子系统，将崩溃日志转存到非易失存储器中，便于后续问题分析。mtdoops与其他捕获panic的方式（如ramoops和kdump）相比，具有特定优势，但需依赖MTD设备和相关配置。 **核心内容摘要：** - mtdoops通过在内核中注册捕获panic或oops，将日志信息保存到MTD设备。 - 需要在内核defconfig中启用相关配置，并在设备树中预留存储空间。 - 通过cmdline动态更新，确保在系统启动时正确配置mtdoops。 - 功能验证包括开机初始化log检查、cmdline确认及重启测试抓取log。 - offline_log机制可触发mtdoops日志抓取，便于问题诊断。

[Android稳定性] 第005篇 [问题篇] 原子状态调度引起死机 11月前查看 评论
[Android稳定性] 第005篇 [问题篇] 原子状态调度引起死机

本文讨论了在多核系统中因锁使用不当导致的死机异常问题。作者通过两个案例说明了当在原子状态下执行调度命令时会出现BUG，并分析了原因，指出使用全局变量来控制加解锁操作是多此一举且易出错的。文章强调应正确使用锁来保护临界区，避免使用全局变量来控制锁状态，以防止并发执行时的问题。

[Android稳定性] 第004篇 [原理篇] minidump的原理介绍 11月前查看 评论
[Android稳定性] 第004篇 [原理篇] minidump的原理介绍

**minidump** 是一种用于保存系统崩溃信息的机制。当系统发生崩溃时，boot subsystem 会加密并保存注册过的 memory 信息到 RAM EMMC 分区。 **流程**： 1. 开机时，内存中会为 minidump 保留一部分空间，用于存储 kernel log、logcat 和 tz_log。 2. 如果手机触发 dump，在第二次开机时，boot subsystem 会读取 TCSR 寄存器中的 minidump 模式标志。 3. 如果启用 minidump，boot subsystem 会读取 kmsg 和 logcat log，并将其写入 minidump 分区。 4. 开机后，可以使用 dd 指令导出 minidump 分区，并使用 ultraedit 查看 log。 **验证方法**： 1. 将 minidump 设置为 emmc 模式。 2. 触发 dump。 3. 导出 minidump 分区并查看 log。 **总结**： minidump 是一种有效的系统崩溃信息保存机制，可以帮助开发者快速定位问题。