pecuyu

通常，在开发过程中，需要push一些修改到系统分区，之后需要重启系统使修改生效。不过，执行stop、start命令需要root权限，这点需要注意。接下来分析这两个命令的执行流程。执行start/stop程序，它的本体实际上是toolbox。执行命令可以指定特定服务，表示要启动、停止对应服务start/stop通过设置控制属性 ctl.start、ctl.stop 来启动、停止服务init 处理 ctl.start、ctl.stop属性事件，执行启动、停止服务的操作。

在shell通过命令am，可以输出该命令的帮助信息，常用的命令如下几大组件相关的命令，通过名字大概知道用途还有其他比较有用的命令：在命令行执行am命令am使用示例以dumpheap命令为例，其可以指定进程的名字或pid：执行命令：当adb shell 进入后直接执行 am dumpheap system_server, 会抛出上面一个异常，说找不到这个进程，不过换成 system 就可以。从错误的调用栈可以知道，这个命令是通过 Binder#shellCommand 来实现的，am具体的实现在Ac

在分析一些Android问题，比如ANR或Watchdog冻屏时，需要拿到相关进程的Java trace，然后分析是哪出了问题。但是这个Java trace是怎么生成的呢？在Android中的Java进程一般都是运行在art虚拟机之上的，而要拿到相关进程的Java trace，则需要它来完成相关dump操作。根据代码实现也能说明这一点，在art里面运行了一个 SignalCatcher 线程，专门用来处理这个逻辑。SignalCatcher 线程启动后，会循环等待 SIGQUIT (信号3)的发生,当收到S

在Android中，crash大致可以做如下分类：本篇主要是看 Native crash 抓log流程。实现机制主要是基于信号机制和ptrace机制，如下：流程大致如下图所示：接下来，从 linker 的入口_start开始看起。如何分析入口可见参考。__linker_init__linker_init_post_relocationlinker的一些初始化，主要看linker_main函数linker_mainlinker_debuggerd_initdebuggerd_initd

android 应用 java crash 目前为止，Android应用进程是通过zygote进程fork出来的子进程，然后执行一些应用相关的初始化，最后进入应用入口—ActivityThread的main方法。应用在main方法中调用attachApplication通知系统应用启动完成，同时注册IApplicationThread对象到系统进程（通过linkToDeath监听其死亡），最后应用进入主消息循环后就正常运行起来了。通过以上分析，可以总结出应用Javacrash机制处理的三个阶段。.....

文章托管在gitee上 Android Notes , 同步csdn本文基于Android12 分析关机流程Android上层触发关机的入口很多，但最终几乎都是调用ShutdownThread.shutdown来实现。如下是一些常见的调用关机的点：StatusBarManagerService#shutdown, 这个主要是对接SystemUIWindowManagerService#shutdown， 以WindowManagerFuncs接口提供给系统其他模块使用，诸如GlobalAct.

Watchdog 介绍Watchdog的功能实际上是一个监控程序，用于监测系统进程运行状态，以确保系统处于正常运转状态。当系统关键线程出现卡住或其他一些异常情况发生时，一些系统关键服务可能无法正常工作，当卡住过长时间时，Watchdog会重启系统(框架层面)，以确保用户能够正常使用设备。Watchdog的功能大致如下：监听系统关键Handler是否能及时处理消息，实际上是判断其关联的线程是否卡住监听系统Binder线程是否异常，是否处于starve状态监听系统关键服务是否出现了死锁超时或者执行调

文章托管在gitee上 Android Notes , 同步csdn在InputDispatcher的工作流程中,分析过过ANR相关的部分内容,这一篇来详细分析ANR的产生与显示流程ANR 的检查在InputDispatcher的dispatchOnce方法中,会在执行完事件派发与Commands后,通过processAnrsLocked方法处理ANR./// @frameworks/native/services/inputflinger/dispatcher/InputDispatcher..

文章托管在gitee上 Android Notes , 同步csdn这一篇看一些系统模块的monitor实现。接下来看3个比较典型的场景：ActivityManagerService的monitor实现InputManagerService的monitor实现，涉及native检查Binder线程的monitor实现Watchdog.Monitor定义如下,实现该接口的类，可以注册到Watchdog作为一个被监听的对象：public interface Monitor { voi.

文章托管在gitee上 Android Notes , 同步csdn通常判断是否是发送Watchdog，可以通过以下log：查看 /data/anr 目录下是否生成 Watchdog trace 文件events log中查看 watchdog event. 在Watchdog#run的方法中打印event事件 // If we got here, that means that the system is most likely hung. // First collect .

文章托管在gitee上 Android Notes , 同步csdnTrace生成流程从第2篇可知，Watchdog的Trace生成过程如下：当等待时间 >Max/2 , 即评估状态为 WAITED_HALF，则会输出第一次Trace当等待时间 >Max, 即评估状态为 OVERDUE，则会输出第二次Trace，以及一些其他的信息(kernel log,binder相关信息,dropbox等)最终，会将两次生成的Trace合二为一，生成一个最终的Trace。下面看判断条件}.

文章托管在gitee上 Android Notes , 同步csdnWatchdog 工作流程概述如上篇所述，当调用Watchdog#start方法时，启动其内部工作线程，之后它的run方法会被调用，Watchdog在此线程中执行监控逻辑。Watchdog的工作概述如下：CHECK_INTERVAL周期遍历HandlerChecker列表的所以元素，调用HandlerChecker#scheduleCheckLocked方法来执行检测操作，具体实现是向对应HandlerChecker的Hand.