我的进阶曲线之五

来源：互联网发布：手机上编程软件编辑：程序博客网时间：2024/06/06 03:02

andriod watchdog 需要各个应用自身去注册监听

adb shell dumpsys activity services > a-s.txt 或者 adb shell service list

framework即时编译部署

分两大步骤，

A eclipse编译class

B 把class打包生成新的jar

2 因为要创建java工程，用eclipse，不要用android studio。

4 你首先要解决的是，编译java工程的问题，

相关代码到底要依赖哪些jar包，要问人或者一个个试错。

jre的system包也要勾选，文档里面不让勾选是坑爹呢。

5 jre版本要选正确，java complier也要选正确，都在build path配置里面。

6 操作系统的 java 环境变量配置正确，不光JAVA_HOME，path里面要配置java bin的路径。

7 生成新的class文件后，就要准备打包环境了。

dx.jar强烈建议用最新的，android sdk包里面有呢。

8 在 service-classes.txt 中，包名一定要写对啊。如 com.android.server.am.ActivityManagerService。

9 多怀疑java版本的问题。脚本执行报错，直接编辑脚本看看。

perl update-jar-dex.pl -r “D:\Workspace\android-framework\bin” -c class_list.txt -j framework -o framework.jar

定制符合项目需求的安全策略

http://blog.csdn.net/modianwutong/article/details/43114883

SELinux的安全检查覆盖了所有重要的系统资源，每次MAC访问失败都会记录在内核中，如下：

<6>[82.950769] type=1400 audit(1882976.149:5): avc: denied { write } for pid=3194 comm="BluetoothAdapte" name="aplog" dev="mmcblk0p22" ino=88 scontext=u:r:bluetooth:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir

上面的log记录了一条违反安全策略的访问信息，即BluetoothAdapte进程试图在data分区写目录失败。

scontext表示进程的SContext，u:r:bluetooth:s0，属于bluetooth域；

tcontext表示目标的SContext，u:r:system_data_file:s0，属于system_data_file类型;

tclass表示进程要操作的ObjectClass，dir表示目录；

mmcblk0p22是userdata分区，write表示写操作。

连起来就是bluetooth域的进程（BluetoothAdapte），对system_data_file类型的dir执行write操作失败。明确了失败原因，我们就可以在安全策略配置文件中定制我们自己的策略了：

[external/sepolicy/bluetooth.te]

allow bluetooth system_data_file:dir w_dir_perms;

w_dir_perms是一个宏，其定义在global_macros中，包含了write相关操作：

[external/sepolicy/global_macros]

define(`w_dir_perms', `{ open search write add_name remove_name }')

如何导出 /DATA 分区，就这么办！

/dev/block/platform/7824900.sdhci/by-name

mount | grep data

/dev/block/bootdevice/by-name/userdata /data

userdata -> /dev/block/mmcblk0p42

input keyevent KEYCODE_HOME

adb shell reboot -p

MTK-FTRACE

当您拿到ftrace_all_in_one_latest.zip之后，请在user mode下按照如下步骤进行：
一般情况下只需要0xE即可
需要使用如下命令：
adb shell setprop debug.atrace.tags.enableflags 0xE
adb shell "setprop debug.egl.traceGpuCompletion 1"
adb shell stop
adb shell start

2 .双击打开ftrace_all_in_one里面的01-catch.bat，按照提示按任意键开始，然后开始模拟你认为卡顿的操作，但卡顿发生之后，按照提示按任意键结束，待01-catch.bat运行完后自动会退出。

3.双击打开02-parse.bat，结束后会自动生成trace.html

4.上传trace.html 给我们分析(请告诉我们卡顿发生几秒后停止录Ftrace的，便于我们找到相关时间点)

systrace 分析 tips：

和正常流畅的surfaceflinger信息进行对比。

关注cpu/gpu频率，状态。

关注surfaceflinger是否和vsync同步，不同步（16ms时间内未能交给GPU）就容易造成掉帧。

不同步，

很可能是因为MDP合成时间太长（此时在surfaceflinger这一行应该出现eglSwapBuffers）

或者是因为GPU处理时间太长，迟迟不能释放FB。

postFramebuffer执行之后，表明此时交给了GPU去执行，surfaceflinger这一行应该有空白时间间隔才正常。

surfaceflinger分析时候，也要看看最顶部的进程状态条颜色，如果是棕色，表明surfaceflinger进程处于sleep状态。

最后，

要特别关注上一次 eglswapbuffer 结束到下一次 eglswapbuffer 结束的时长（不管是surfaceflinger 还是具体应用，严重超过16ms都会有问题）。

https://www.projecth.us/sources

如何使用 showstack ？

1 看看文件目录结构，symbols 里面放编译版本时候的带符号表的elf文件。crashes里面放墓碑文件。

* symbols里面目录结构务必保持编译生成的结构

2 点击bat，到output里面去看输出结果。

高通平台如何抓取Ftrace？方案在此

查询所有可跟踪的event：

adb shell cat /sys/kernel/debug/tracing/available_events

根据查询结果，选取你所感兴趣的event（如这里的mdss）来配置ftrace event：

adb shell "echo mdss:* >> /sys/kernel/debug/tracing/set_event".

操作手机的同时，按如下方式抓取ftrace信息：

adb shell cat /sys/kernel/debug/tracing/trace

在构造HWComposer对象时，选择了VSync信号产生方式：1.硬件产生；2.软件模拟产生；假如当前系统可以成功加载HWC_HARDWARE_MODULE_ID=hwcomposer，并且通过这个库能顺利打开设备(hwc_composer_device_t)，并且其版本号又大于HWC_DEVICE_API_VERSION_0_3的话，我们就采用硬件方式产生VSync，否则需要创建一个新的VSync线程来模拟产生信号。

在我们手机里面通过 adb shell cat /proc/vmallocinfo 可以看到，

通过binder_mmap映射的虚拟内存正好是这么大：（1020K）

fastboot.exe flash boot boot.img

echo c > /proc/sysrq-trigger

73、Android如何生成成coredump文件？
(1)修改init.rc增加如下(相关于执行ulimit -c unlimited)
setrlimit 4 -1 -1
write /proc/sys/kernel/core_pattern "/local/log/core-%e-%p-%t"
(2)也需要增加如下脚本：
echo "1" > /proc/sys/kernel/core_uses_pid //允许文件名后加pid
echo "/local/log/core-%e-%p" > /proc/sys/kernel/core_pattern
echo 1 > /proc/sys/fs/suid_dumpable

0 0