PeaceMaker

20:12 Wednesday, April 20, 2022 (GMT+8) Time in Guangdong Province, China 简介 跟不上旋律节奏的VSYNC 严重异常耗时的dequeueBuffer 参考 简介某次调图形性能的时候（启动后台录屏，下(或)称case）发现Android SurfaceFlinger Vsync机制并没有以前想的这么简单粗糙，特别是这次调图形性能发现一些跟Vsync有关联，因此做个总结详解。 跟不上旋律节奏的VSYNC一份追踪报告，发现Vsync信号非常不规律，于是从这里入手分析、总结Vsync。 如下图，As we can see，VSYNC-sf出现严重的漂移（见图，第二行的VSYNC-sf残次不齐、跟不上规律、难看且混乱），这导致了丢帧。（但VSYNC-sf的失控仅表示与丢帧的相关性，并不直接表明因果性。） 从VSYNC信号看，后台录屏RUNNING的情况下，带来的额外工作负载直接压垮了SurfaceFlinger，导致其提交屏幕刷新的VSYNC-sf都出现了严重缺失、错位、延期等——总之是非常不正常的工况。 ...

11:42 amWednesday, 6 April 2022 (GMT+8)Time in Guangzhou, Guangdong Province, China 简介 读取负载 实现 其他 获取型号 读取当前频率 读取CPU负载 名词解释 参考 简介本文介绍Android平台（Android Q，MTK(CPU)，Mali(GPU)）通过kernel misc节点读取GPU负载的方法。介绍了通过watch、awk自动周期性间隔打印GPU利用率的命令。 读取负载 读取GPU负载；输出三列数据分别为Loading、Block、Idlecat /sys/kernel/debug/ged/hal/gpu_utilization 其中Loading、Blocking、Idle可以分别从独立的节点中单独读取 12345cat /sys/module/ged/parameters/gpu_loadingcat /sys/module/ged/parameters/gpu_blockcat /sys/module/ged/parameters/gpu_idle sys节点下ke ...

命令简写含义listl列出 10 行代码breakb设置断点break ifb if设置条件断点delete [break id]d删除断点 047 (按照 break id) 删除，没有 break id, 删除所有段 6disable禁用断点enable允许断点infoi显示程序状态. info b (列出断点), info regs (列出寄存器) 等run [args]r开始运行程序，可带参数displaydisp跟踪查看那某个变量，每次停下来都显示其值printp打印内部变量值watch监视变量值新旧的变化steps执行下一条语句，如果该语句为函数调用，则进入函数执行第一条语句nextn执行下一条语句，如果该语句为函数调用，不会进入函数内部执行 (即不会一步步地调试函数内部语句）continuec继续程序的运行，直到遇到下一个断点finish如果进入了某个函数，返回到调用调用它的函数，jump outset var name = v设置变量的值backtracebt查看函数调用信息（堆栈）startst开始执行程序，在 main 函数中的第一条语句前停下framef查看栈帧， ...

简介本文分析MTK平台对LED（指示灯）驱动节点部分的创建、处理流程。MTK Android平台遵循Linux的规范惯例，和常规的Linux一样，将发光的二极管等设备抽象为一个sysfs class（驱动里面的一种类），诸如指示灯、LED灯、背光等都属于这一类，因此都在同一个class（/sys/class/leds）下管理。MTK平台在该目录下提供了对LED进行操作的驱动节点。 其中，和常规的Linux一样，也是通过trigger节点来控制LED灯的触发。 android:/ # ls /sys/class/leds/* /sys/class/leds/blue: brightness device max_brightness power subsystem trigger uevent /sys/class/leds/green: brightness device max_brightness power subsystem trigger uevent /sys/class/leds/lcd-backlight: brightness d ...

简介介绍在Mac上通过Android官方Emulator启动自己编译的AOSP模拟器镜像,实现自定义AOSP在Mac Android模拟器上的调试. Emulator准备直接下载官方的Emulator,这个模拟器用于启动AOSP编译出来的模拟器镜像 下载地址: https://github.com/google/android-emulator-m1-preview/releases 镜像准备完成AOSP的编译,得到模拟器镜像.可以参考: 在Apple Mac M1上编译AOSP ARM Android模拟器和拉取并编译AOSP Android 14模拟器 打包镜像,可以参考:aosp_image_pack 启动 将打包好的镜像解压放入Mac Android Emulator目录/Applications/Android Emulator.app/Contents/MacOS/ 假设镜像解压到目录/Applications/Android Emulator.app/Contents/MacOS/api30-gphone-arm6 ...

简介旨在让你能在Mac上运行可自行定制的模拟器和Android系统. 分两个部分,分别编译模拟器emulator和AOSP模拟器镜像, 其中以Android 14为例. 准备DepotTools12git clone https://chromium.googlesource.com/chromium/tools/depot_tools.gitexport PATH=/path/to/depot_tools:$PATH 显然你必须将/path/to/depot_tools正确替换为实际路径 其中,export命令最好加到.bashrc中,让你的所有终端都能生效 拉取qemu源码并编译用于将编译得到的镜像运行起来 注意:这一步可以跳过,因为AOSP源码自带一个emulator.如果你想研究emulator的实现才需要自行编译 123456mkdir emucd emurepo init -u https://android.googlesource.com/platform/external/qemu --depth=1repo sync -qcj ...

拉取12repo init -u https://android.googlesource.com/platform/manifest -b android-14.0.0_r20repo sync 编译123source ./build/envsetup.shlunch sdk_phone_x86_64make 当想要编译平板镜像时 1lunch sdk_tablet_x86_64 运行1emulator

背景业界对Android的性能监控、hook、系统分析、抓包、逆向等领域的关注和投入在不断提升，作为Linux Kernel中新兴的优美的一套技术框架，bpf逐渐在Android中被用于监控、分析、优化和逆向，产出了众多的工具。此外，Google原生系统的上层服务（如网络流量统计、网络黑白名单）也转向使用ebpf来实现。 bpf可以理解成Kernel的虚拟机字节码，它借助C语言编译成特定的ELF，通过专用的系统调用注册到Kernel，挂载到指定的tracepoint，进行代码流程的hook，与App的插桩、性能优化的检查点非常类似。 本文以Android源码AOSP为基础，讲解一个bpf程序应该如何被编译、集成到系统、在系统中启动/运行，并使用C语言编写了一个可以实际运行的bpf程序（https://github.com/NasdaqGodzilla/cpuprobe）。 编译常规的C语言bpf程序需要编译为Kernel BPF子系统能够识别的专用字节码，Android采用了一套独特的编译系统（Android.bp）来包装包含bpf程序在内的编译流程。 一个最简单的bpf编译 ...

简介BatteryStatsService和BatterStatsImpl是系统中用于估算电流消耗的关键对象，能够估算并存储软件功耗和硬件功耗。其中主要流程分为事件回调时记录耗电信息、触发读取时计算并统计耗电信息两大流程。本文介绍耗电信息的读取和统计过程。 BatteryStatsService和BatteryStatsImplBatteryStatsService提供App和硬件的功耗，是通过BatteryStatsImpl的接口getUidStats()方法取得的，在分析该方法的流程前先简单介绍一些关键成员。 BatteryStatsHelper关键成员： BatterySipper：按照Uid和drain type来过滤存储的功耗记录，从BatteryStatsImpl中提取。可以理解为从系统记录的全部功耗信息中，按照Uid和Drain type提取出来。其中Drain type是耗电类型，如屏幕耗电、Wi-Fi耗电、App耗电等 mUsageList：以BatterySipper的形式记录各Uid的功耗 mWifiSippers、mBluetoothSippers：Wi-Fi ...

简介众所周知，Android平台的管理机制下，App进入后台后，为了提供持续的及时服务（如推送、音乐），或进行驻留获取收益（跟踪、信息收集、广告）等，会利用一些方法来让自身保持活跃，躲过被Android系统或用户发觉、清理，实现后台驻留。 其中，后台驻留的广义概念，除了保持在后台运行外，被其他组件拉起也属于驻留（唤醒）。 由于驻留会对系统的性能、响应延迟、续航、发热等带来负面影响，令系统的资源管理效果降低，属于违背用户意愿和知情的恶劣行为，因此将这些App称为顽固（Diehard）应用，其利用的方法称为顽固方法。 除了App利用的一些黑科技（甚至是在违法边缘的擦边手段）以外，Android系统本身自带的机制也可以实现保活和拉起。这些保活、拉起机制，粗略划分为两类： 保持活跃，在后台运行不被清理、回收 被其他组件唤醒，包括被其他App唤醒、被系统提供的功能唤醒 本文总结上述这两类会被顽固App利用的机制。 进程和Task管理首先简单梳理一下Android Framework层基本的进程管理。 Android平台基于Linux，除了基于Linux的“进程”维度来进行管理外，还按照Tas ...