专业开发者的博客，一个从事Android WiFi和蓝牙的工程师

原创 低内存 kernel DMA32/Normal信息

这段，DMA32 的free已经低于low水位了，free_cma:0kB,inactive_file比较大。Normal free已经低于mini水位了，free_cma只剩2M,DMA32里面全是High memory,其它的都是0个page。Normal里的都是CMA的，其它全0。

原创 /proc/meminfo memory状态解读

有些老设备只能访问低端内存，比如16M以下的内存，当应用程序发出一个I/O 请求，DMA的目的地址却是高端内存时（比如在16M以上），内核将在低端内存中分配一个临时buffer作为跳转，把位于高端内存的缓存数据复制到此处。如available = free+filepage +slab_reclaimable -(lowmem_reserve +high_wmark_pages) -min(filepage/2,wmark_low) - min(slab_reclaimable/2,wmark_low)

原创 开关机测试过程中zygote卡死导致应用无法启动_图床

原创 AOSP Android log基础

当多个应用 build 类型（例如开发 build 与发布 build）的底层代码预计相同、但所允许的日志级别不同时，这对于处理这些 build 类型将非常有用。在具有多个堆栈级组件的系统开发中，请按照图 1 确定每个组件要使用的标准。中合并使用了多个标准，Android 中的日志记录较为复杂。作为安全和隐私审核的一部分，必须在发布之前对日志政策和可接受的详细信息进行处理。：标准 Java 日志记录与 Android 日志记录的错误级别对比。在这类情况下，请使用单独标准来确定要应用的级别。

原创 slab kmalloc-128异常

发生了内核恐慌（Kernel Panic），原因是内存耗尽（Out of Memory, OOM），且没有可杀死的进程（"Out of memory and no killable processes..."），最终导致系统死锁（"System is deadlocked on memory"）。以下是对日志的详细分析，找出 OOM 的具体原因以及系统卡死的原因。解决需要从内存配置、Slab 管理、驱动优化入手。的 GPU 内存分配失败触发 OOM，结合碎片化、CMA 限制、Slab 占用高（尤其是。

原创 Kernel Memory Leak Detector

【代码】Kernel Memory Leak Detector。

原创 [FAQ21615] [Memory]如何查询内核所有 page 的使用情况 (by page owner)

adb shell "/data/page_owner_sort /data/page_owner.txt /data/sorted_page_owner.txt" //计数并排序。adb shell "cat /sys/kernel/debug/page_owner > /data/page_owner_full.txt" //此为raw 数据。adb pull /sys/kernel/debug/page_owner_slim 并检查。page owner用于跟踪每个页面的分配者。

原创 [FAQ21613] [Memory] 如何分析slab占用内存细节以及slab leak

注意kmalloc-4096 以上为page单位，backtrace讯息需要透过page owner debug方式查看。(参考 FAQ21615 [Memory]如何查询内存所有 page 的使用情况 (by page owner))如果发现meminfo 里slab 占用内存过高， 如何细化分析哪些模块占用slab内存高，有没有存在leak。如果需要查看4k, 8k 大小的slab 的backtrace 需要额外开启以下选项。CONFIG_SLUB_DEBUG_ON=y (eng版本默认开启)

原创 [FAQ20884] 如何用kmemleak来debug 内核内存泄漏转至元数据结尾

然后 cat sys/kernel/debug/kmemleak // 会得到很多backtrace，但是这其中有些是误抓的（kmemleak存在误报情况）修改内核配置后adb shell，看是否存在sys/kernel/debug/kmemleak这个节点，如果存在表明已经开启kmemleak。第二次scan：echo scan > sys/kernel/debug/kmemleak //开始扫描。echo scan > sys/kernel/debug/kmemleak // 开始扫描。

原创 虚拟内存写爆问题分析总结

dalvik.vm.heapsize 是应用在AndroidMainfest.xml设置了android:lagreHeap=“true”将会变成应用的设置，大应用的虚拟内存是dalvik.vm.heapsize的2倍，常规应用虚拟内存是dalvik.vm.heapgrowthlimit的2倍。我们没有修改heapsize，所以后面在测一些极限场景如。可寻址范围2^32(4G)，高16的空间为内核空间，低3G的空间为用户空间): 64bt 的设备一般就不会出现这种问题，虚拟地址空间充裕得很。

原创 Binder通信时进程pid找不到导致system_server crash

因此怀疑是这几个进程共享uid，导致的其中一个包被移除的时候其它进程被杀。显示通过shell pm uninstall。会触发相关uid的进程被杀掉。

原创 Crash工具加载dump文件

kaslr值保存在OCIMEM.BIN中，使用下面的命令可以从OCIMEM.BIN中快速提取出kaslr，直接关注4ead dead这一行,后面的0000 cdc0 0014 0000即为kaslr，需要注意的是由于arm采用little-endian，因此需要倒序读取，拼接后kaslr为：0x00000014cdc00000。Kdump在转储文件时，会把物理内存中的所有内容保存为对应的二进制文件，在通过crash加载dump文件时，需要告诉crash某个bin文件对应的物理内存是在哪里。

原创 在Watchdog和ANR发生时，记录Binder trace

将binderStateRead方法里面的/sys/kernel/debug/binder/state路径改为/dev/binderfs/binder_logs/state。在watchdog中，是有相关功能的，在debug版本上，如果出现watchdog，会去记录binder state，路径就在 data/anr 下面。在ANR以后也会生成对应的binder trace，当前的修改都是在debug版本上面生效，如果有需要也可以考虑全部版本都生效。，如果没有添加权限，是不能直接访问的，会有以下报错。

原创 systrace里的binder通信日志转至元数据结尾

android.vending-28966 (28966) [003] .... 1836367.744999: binder_transaction: transaction=501310882 dest_node=9535 dest_proc=1358 dest_thread=0 reply=0 flags=0x12 code=0x2android.vending-28966 (28966) [003] .... 1836367.745040: sched_wakeup: comm=Binder:13

原创 native服务日志控制

NDEBUGcflags: [],},},NDEBUGLOG_NDEBUG0log_system.h中的处理流程30 #ifdefNDEBUGLOG_NDEBUG132 #else34 #endif35 #endif55 #else57 #endif58 #endif199 #ifLOG_NDEBUG207 #else。

原创 6851 Hang_detect问题总结_图床

原创 dumpsys meminfo分解

描述：可以了解系统详细的memory使用的情况，通过dumpsys meminfo 可以得到系统中各个process占用的内存情况，各种adj情况下的process的内存分布，总体的memory的使用统计等信息。区别于/proc/meminfo提供的内存数据，dumpsys meminfo更加偏向于andorid系统对于系统中memory使用情况的理解，因此我们在实际的memory的debug的过程中，在android系统会倾向使用dumpsys meminfo。

原创 [FAQ25047] Android Q/R user/userdebug版本如何开启aee dump机制

默认情况下，customer eng load的AEE mode是3，user/userdebug load的AEE mode是4，也就意味着AEE mode=3的时候可以抓取fatal/normal exception DB，AEE mode=4的时候只能抓取fatal exception DB。如何去切换AEE mode，让当前的load可以capture不同的exception：使用AEE提供的cmd，aee -m 1/2/3/4。这一条能够让AEE强制抓取ANR不论AEE的mode是什么。

原创 ZZ_INTERNAL信息解读

定义在：alps/kernel-xxx/drivers/misc/mediatek/include/mt-plat/aee.h。所有类型都定义在：alps/kernel-xxx/drivers/misc/mediatek/include/mt-plat/aee.h。如果是NE，则这个栏位是signal名称，比如：SIGSEGV，KE则为空，SWT则为：system_server_watchdog，等等。：固定是/data/core/ or data/vendor/core。包含10列，每1列用。

原创 如何使用addr2line命令解析native backtrace

若是64位lib库，将带symbols信息的lib库拷贝到任意一份Android L及以上版本的代码路径下：platform(alps)/prebuilts/gcc/linux-x86/aarch64/cit-aarch64-linux-android-4.9/bin/注意：带symbols信息的lib库必须是与复现问题的手机bin档同一次build出来的才可以，必须是位于out/target/product/{ProjectName}/symbols/system/lib/这个目录下的lib库才可以，

原创 native crash SIGTRAP-＞TRAP_BRKPT

在上面的代码中，我们使用了汇编指令`__asm__("int3");`int3`是一个专门为调试用途设计的中断指令，它会中断程序运行并将控制权交给调试器，以便进行调试。在运行`run`命令之后，程序会在`int3`指令处停止执行，并等待调试器的指示。在Linux系统中，可以使用`gdb`调试器来运行上面的程序并设置断点。需要注意的是，这份日志只提供了部分信息，如果要进一步了解异常发生的原因，需要查看更完整的日志信息和程序代码。因此，这份日志可能是由于。"的信号被触发，信号代码为"这份日志显示了一个名为"

原创 存储空间满引起的SQLiteCantOpenDatabaseException转至元数据结尾

从堆栈上看db提示文件不存在，创建如果需要已经设置，因此考虑是存储空间不足。查看db中SYS_FILE_SYSTEMS data分区的空间情况。显示data分区用完。

原创 SystemServer设置属性失败JE

CPs sys.skyroam.vsim[38790.227] 这行日志是在HandlePropertySet时checkPermission前打的日志。main_log_15__2024_0607_093118中可以看到相关设置属性失败的日志，swt的dbg中没有保存到相关日志。main_log_15__2024_0607_093118中可以看到相关设置属性失败的日志，swt的dbg中没有保存到相关日志。发现有很多上层的进程rss在100M左右的rss占用，列表里的数据是内存页个数，每个内存页4K。

原创 startActivity时Context不是Activity需要FLAG_ACTIVITY_NEW_TASK

这个问题应该是应用自己调用startActivity的时候需要适配修改下。at g9.e.onClick(Unknown Source:4)在调用。，intent里需要设置。

原创 Gdb和addr2line解析地址（栈帧）不匹配的处理办法

KASLR简单描述就是在每次开机都会给kernel生成一个offset，所有VA都是经过offset计算的。gdb加载coredump 和vmlinux命令如下，加载offset关键步骤在第3和第4步。2.1 从解析的DB中，打开SYS_REBOOT_REASON文件，Kernel Offset的值即是。2.2若Kernel Offset未打印出，则利用ram_console_buffer 地址来计算。但在Android O版本之后，gdb解析不出栈帧，addr2line找不到对应地址行号的问题，

原创 Kernel log中内存分布解析

kernel log。

原创 [Hang Detect] SYS_HANG_DETECT_RAW中的task info

Hang问题的分析重点即是查潜在的task是否卡住，而判断是否卡住需要依据，SYS_HANG_DETECT_RAW会dump两次系统进程信息（间隔约30s），其中根据调用栈及task info信息可以推断相关task是否卡住。

原创 Hang 打印内存信息解析

show_migration_types 这个函数打印的是buddy system中一类大小的内存块包含的内存类型，如“Normal: 374*4kB (UMCH)”表示Normal 内存中4K大小的内存块有374个，这些内存块包含。不可移动、可移动、CMA、迁移类型。这个打印可以帮助定位申请某类内存失败的问题。//打印各zoom vm_stat信息。

原创 解析kernel module（KO）行号

通过地址和symbol 解析kernel module的行号。1.所需工具：addr2line，objdump。Step2： 利用objdump获取函数符号入口。Step4: 用addr2line 获取行号。2.解析如下kernel log。Step1：找到模块对应的ko文件。Step3：获取对应函数的执行地址。

原创 GKI 2.0 user版本的vmlinux

如果客户需要单独针对不同的项目进行kconfig 客制化，则强烈推荐使用kernel config overlay 的方式操作，这样能以比较优雅的方式解决各个项目的冲突。(1). 创建*.config文件，放在kernel-5.10/kernel/configs/ 或者 kernel-5.10/arch/arm64/configs/中。另外，需要特别注意kernel kconfig 使用的是UNIX 格式，即跳行只有 LF，没有CR，不然kernel 可能会识别出错。

原创 MTK平台aee dbg拷贝

MTK平台在手机出现异常的情况下，aee会抓取log，dump信息等，压缩加密为dbg文件，使用MTK工具解析。dbg文件保存在/data/aee_exp文件夹下，google项目解耦后，多出来一个/data/vendor/aee_exp，对应kernel panic，hw reboot，hang_detect之类的底层异常。

原创 SurfaceFlinger AutoBackendTexture GPU

46行，判断mBackendTexture无效，或者desc.width、desc.height为0就会触发 LOG_ALWAYS_FATAL，引起NE abort。是GPU相关的，提case给MTK,平台根据上面的log，直接给出了相关的patch。

原创 system_server_native_crash global reference table overflow

705] 24131 of com.android.server.wm.ActivityRecord$Token (24131 unique instances)---------->ActivityRecord有24131个不同的实例。.PendingIntentRecord (24171 unique instances) --------->PendingIntentRecord有24171个不同的实例。) { ------> pendIntent超过2000打印日志。

原创 system_server_native_crash Thread suspension timed out WifiHandlerThread

APLog_2023_0317_105851__2/main_log_2023_0317_105851.curf 28700行显示system_server的binder线程耗尽了。Kernel log对齐时间后，问题点前10秒的系统负载信息，snapuserd的线程473和kswapd0的cpu占用都比较高。显示 binder:1587_线程32个，31个处于futex_wait_queue_me，1个处于pipe_read里。里看 system_server应该是没有可用的binder线程处理请求了。

原创 dvm_lock_sample的开关

dalvik.vm.lockprof.threshold 属性设置的情况下disable_lock_profiling无效，

原创 需要Perfetto分析的anr

anr类的问题，经常会有系统cpu，内存负载不高，iowait也不高，主线程状正常的，这类问题通过常规的日志无法分析，需要抓取Perfetto来分析应用的情况。event log中也没有异常。

原创 系统负载高内存紧张 Setting anr

main_log_2023_0321_110202.curf，中显示系统内存压力突破low water mark，swap可用小于设定阈值，271440kB < 310100kB，后面内存压力继续升级进入critical状态(device is not respondin),系统进行查杀后依旧低内存。anrmanager统计的系统负载信息显示从2023-03-21 11:05:33.589到2023-03-21 11:06:09.675，36秒内系统负载较高，整体cpu使用率达到97%，内存压力较大，

原创 焦点切换 anr

从anrmanager里打出来的系统负载信息看，settings在7.9s内只占用了0.8的cpu，surfaceflinger和graphics.composer，android.hardware.media.c2，cpu占用前3,03-15 09:23:05的时候input_focus报焦点请求recents_animation_input_consumer，离开com.android.settings。但是系统整体的cpu,内存压力，iowait都不高。

原创 性能监控工具 | ANRdaemon

然后一段时间后（比如 20 秒后），当 CPU 使用率变高并且守护进程再次打开跟踪时，sched 记录的 /d/tracing/trace 中的第一个条目正在从守护进程切换到某个其他进程。由于这个机制，当 systrace.py 解析原始跟踪文件时，守护进程显示为运行了整个 20 秒（因为从 systrace 的角度来看，关于守护进程的两个间隔 20 秒的 sched 跟踪条目表示守护进程 连续运行所有 20 秒）。使用见 readme 就好了，就是运行个监控程序，CPU 超过设定值他就抓 trace。

原创 应用绘制状态

/** This is set when there is no Surface */ static final int NO_SURFACE = 0; /** This is set after the Surface has been created but before the window has been drawn. During * this time the surface is hidden. */ static final int DRAW_PENDIN