从通话日志分析android 4.4.2 phone的拨号流程

网上关于拨号流程的文章有很多,大多讲逻辑,本文从logcat输出的日志入手。分析通话流程,还原系统应用真实的调试场景。

adb logcat -b main -b radio -v time >> call.log

用如上adb命令将拨号至接通电话的日志输出。

1-01 08:02:07.458 V/OutgoingCallBroadcaster(  786):  - Broadcasting intent: Intent { act=android.intent.action.NEW_OUTGOING_CALL flg=0x10000000 (has extras) }.

OutgoingCallBroadcaster类发出拨号请求。

01-01 08:02:07.467 D/CallController(  786): placeCall()...  intent = Intent { act=android.intent.action.CALL dat=tel:xxxxxxxxxxx (has extras) }

01-01 08:02:07.467 D/CallController(  786):                 extras = Bundle[{android.phone.extra.ACTUAL_NUMBER_TO_DIAL=01058928914, com.android.phone.extra.video=false, com.android.phone.extra.slot=1}]

PhoneGlobals.getInstance().callController.placeCall(intent);调用CallController类的placeCall方法。log也输出了信息。

01-01 08:02:07.467 D/PhoneUtils(  786): getInitialNumber(): Intent { act=android.intent.action.CALL dat=tel:xxxxxxxxxxx (has extras) }

01-01 08:02:07.467 D/PhoneUtils(  786): ==> got EXTRA_ACTUAL_NUMBER_TO_DIAL; returning ‘01058928914‘

01-01 08:02:07.467 D/CallController(  786): - action: android.intent.action.CALL

01-01 08:02:07.468 D/CallController(  786): - uri: tel:01058928914
01-01 08:02:07.482 D/CallController(  786): placeCallInternal()...  intent = Intent { act=android.intent.action.CALL dat=tel:xxxxxxxxxxx (has extras) }

CallController会调用placeCall() placeCallInternal() 并启动画面。

PhoneUtils辅助类会对号码进行许多判断(如是否是紧急号码等)

01-01 08:02:07.489 D/PhoneUtils(  786): placeCall ‘01058928914‘ GW:‘null‘

从CallController的placeCallInternal()函数调用PhoneUtils的placeCall()方法

01-01 08:02:07.503 D/CallManager(  786):  dial(Handler (com.android.internal.telephony.gsm.GSMPhone) {42522050}, 01058928914)

PhoneUtils的placeCall()方法中走到了CallManager的dial方法,但此时号码并没有真正拨出。继续看log。

01-01 08:02:07.503 D/CallManager(  786): - Ringing: IDLE from Handler (com.android.internal.telephony.gsm.GSMPhone) {424b3d50}

01-01 08:02:07.503 D/CallManager(  786): Phone: Handler (com.android.internal.telephony.gsm.GSMPhone) {424b3d50}, name = GSM, state = IDLE

01-01 08:02:07.503 D/CallManager(  786): - Foreground: IDLE Background: IDLE Ringing: IDLE

从日志中也可以看出此时拨号的状态,三个GsmCall对象还都是IDLE的状态

01-01 08:02:07.504 D/GSM     (  786): GSMPhone(2) :[CC][GsmPhone][SIM2] dial:01058928914

01-01 08:02:07.504 D/GSM     (  786): newDial:01058928914

走到GSMPhone的dial() 方法,此时从应用层进入了framework层了。

01-01 08:02:07.532 D/RILJ    (  786):  RIL(2) :[0643]> DIAL

RIL层 向下发出dial指令 > 指的是向下层发送命令

01-01 08:02:07.535 D/AT      (  559): AT> ATD01058928914;

发送AT命令给modem层 指示要拨出的号码

01-01 08:02:07.539 D/CallManager(  786): End dial(Handler (com.android.internal.telephony.gsm.GSMPhone) {42522050}, 01058928914)

拨号命令发送结束

01-01 08:02:07.540 D/CallManager(  786): Phone: Handler (com.android.internal.telephony.gsm.GSMPhone) {42522050}, name = GSM, state = OFFHOOK

01-01 08:02:07.540 D/CallManager(  786): - Foreground: DIALING Background: IDLE Ringing: IDLE

正在拨号。。。

01-01 08:02:07.560 D/PhoneGlobals(  786): displayCallScreen()...
01-01 08:02:07.562 D/AT      (  559): AT< OK

返回OK命令。

01-01 08:02:07.569 D/RILJ    (  786):  RIL(2) :[0643]< DIAL 

返回正在拨号的状态

从通话日志分析android 4.4.2 phone的拨号流程,布布扣,bubuko.com

时间: 2024-12-31 03:38:17

从通话日志分析android 4.4.2 phone的拨号流程的相关文章

python 分析android日志获取activit加载时间

最近有个需求,需要对比前后两个版本单个activity加载的时间 在android日志中我们可以看到类似INFO/ActivityManager(2486): Displayed activity com.teleca/.ContextMenuActivity: 240 ms (total 41289 ms)的日志,即为Activity的加载时间 首先通过adb logcat > xx.txt获取日志,然后用如下代码分析日志: #-*-coding:utf-8 -*- # 分析android a

Android中一个有趣的crash的日志分析

很久前写的一篇文章,发出来以作纪念:) Android中一个有趣的crash的日志分析 首先看看bugly平台中异常的统计信息,表面上是一个NullPointerException: 发生异常设备统计信息如下图,有意思的是全部都是root过的机器: 接下来看跟踪日志,在最下面可以看到这样的日志,抛出了NullpointerException: 引起异常的是com.lishu.net.LishuNet$2类,从类名看显然是某一个类的内部类. 第一个反应,当然是搜索一下应用的源代码,看看是不是有co

从Handler+Message+Looper源代码带你分析Android系统的消息处理机制

PS一句:不得不说CSDN同步做的非常烂.还得我花了近1个小时恢复这篇博客. 引言 [转载请注明出处:http://blog.csdn.net/feiduclear_up CSDN 废墟的树] 作为Android开发人员,相信非常多人都使用过Android的Handler类来处理异步任务. 那么Handler类是怎么构成一个异步任务处理机制的呢?这篇 博客带你从源代码分析Android的消息循环处理机制.便于深入的理解. 这里不得不从"一个Bug引发的思考"開始研究Android的消息

从Handler+Message+Looper源码带你分析Android系统的消息处理机制

引言 [转载请注明出处:从Handler+Message+Looper源码带你分析Android系统的消息处理机制 CSDN 废墟的树] 作为Android开发者,相信很多人都使用过Android的Handler类来处理异步任务.那么Handler类是怎么构成一个异步任务处理机制的呢?这篇 博客带你从源码分析Android的消息循环处理机制,便于深入的理解. 这里不得不从"一个Bug引发的思考"开始研究Android的消息循环处理机制.说来话长,在某一次的项目中,原本打算开启一个工作线

hadoop日志分析

一.项目要求 本文讨论的日志处理方法中的日志,仅指Web日志.其实并没有精确的定义,可能包括但不限于各种前端Web服务器--apache.lighttpd.nginx.tomcat等产生的用户访问日志,以及各种Web应用程序自己输出的日志. 二.需求分析: KPI指标设计 PV(PageView): 页面访问量统计 IP: 页面独立IP的访问量统计 Time: 用户每小时PV的统计 Source: 用户来源域名的统计 Browser: 用户的访问设备统计 下面我着重分析浏览器统计 三.分析过程

Android核心分析 ----- Android电话系统-概述篇

Android电话系统之概述篇 首先抛开Android的一切概念来研究一下电话系统的最基本的描述.我们的手机首先用来打电话的,随后是需要一个电话本,随后是PIM,随后是网络应用,随后是云计算,随后是想我们的手机无所不能,替代PC.但是作为一个电话的基本功能如下: 0)拨叫电话,接听电话,挂断电话,发送短信,网络连接,PIM管理 1)由于电话运营商为我们提供了呼叫等待,电话会议等补充业务,所以我们的手机需要管理多路通话,如何管理? 2)来电时,我们要播出来电铃声,接通时我们需要切换语音通道,这个又

以慕课网日志分析为例 进入大数据 Spark SQL 的世界

详情请交流  QQ  709639943 01.以慕课网日志分析为例 进入大数据 Spark SQL 的世界 02.漫谈spring cloud分布式服务架构 03.Spring Cloud微服务实战视频课程 04.漫谈spring cloud 与 spring boot 基础架构 05.Java秒杀系统方案优化 高性能高并发实战 06.Java深入微服务原理改造房产销售平台 07.快速上手Linux 玩转典型应用 08.快速上手Ionic3 多平台开发企业级问答社区 09.Java Sprin

点击流日志分析

课程介绍 课程名称: 1.什么是点击流系统?记录用户在网站上的操作,用户行为轨迹. 2.日志有哪些需要注意的地方,如何采集日志(flume),日志格式,日志包含的信息量(字段) 3.分析什么? 网址来源,TOPK 客户端流量占比 Android.IOS...... 网页热力图 课程目标: 1. 掌握点击流系统的架构及工作原理 2. 掌握点击点击流中常见的字段及其业务含义 3. 掌握点击流分析系统开发 课程大纲: 1. 背景知识 2. 需求分析 3. 架构设计 4. Storm程序开发 5. 同步

APP 日志分析

1. 首先通过adb devices查看设备是否连接成功 2.通过adb logcat命令抓取日志 Logcat 日志文件-android日志提供了记录和查看系统调试信息的功能,日志都是从各种软件和一些系统的缓冲区区记录下来的,缓冲区可以通过logcat来查看和是使用 Logcat输出量大,定义了4个log缓冲区: Radio:输出通信系统的log System:输出系统组件的log Events:输出事件 的log Main:所有的java 层(默认) 切换日志输出   Adb logcat