Keep Awake,Keep Studying,Keep Moving,Keep...

美国时间 2013 年 10 月 31 日， Google 正式发布了全新版本的移动操作系统 Android 4.4 KitKat 。据 google 官方介绍，Android 4.4 降低了硬件的需求，提高了程序运行效率。距离 4.4 发布已经过去3个月了，不少朋友也已经体验到了 4.4 所带来的快感，大家可以用过刷入三方ROM(比如知名的CM ROM等)体验Android 4.4。

Call的状态分为6种：ACTIVE、HOLDING、DIALING、ALERTING、INCOMING、WAITING。这里的依据是什么呢？在Google AOSP代码中，我们可以看到google使用的是AT+CLCC的方式来获取当前通话信息的，CLCC的状态描述总共有6种，也就是：active(0)、held(1)、dialing(2)、alterting(3)、incoming(4)、waiting(5)，括号里为状态对应的数值，关于AT+CLCC的指令描述，请大家参考相关AT文档。这些状态值由Mod

在整个MO/MT流程的分析过程中，遗漏了很多细枝末节，在弄清楚整个MO/MT的始末之后，便发现有一些疑问疑问，因此打算陆陆续续分析一些遗漏的细节。本篇文章的发起缘由很简单，就是想知道InCallActivity是如何显示和更新的，通过分析后发现，现在Android 4.4 的界面更新也是从Modem状态改变发起，并不像以前那样直接更新显示界面。

本文来自http://blog.csdn.net/yihongyuelan 转载请务必注明出处       本文代码以MTK平台Android 4.4为分析对象，与Google原生AOSP有些许差异，请读者知悉。前置文章：《Android 4.4 Kitkat Phone工作流程浅析(一)__概要和学习计划》《Android 4.4 Kitkat Phone工作流程浅析(二)_

本系列文章以MT/MO为主线流程，并对其中的细枝末节进行补充说明，比如来电响铃流程。在MT流程的分析中已经涵盖了流程的发起与终止，本文所描述的响铃流程始于MT流程的发起，如对MT流程不熟悉的童鞋请查看文章《Android 4.4 Kitkat Phone工作流程浅析(五)__MT(来电)流程分析》以及《Android 4.4 Kitkat Phone工作流程浅析(六)__InCallActivity显示更新流程》。

上一篇文章简单分析了RILJ的工作流程，实际上MTK对于RILJ的改动还是较大的，添加了很多request和respone类型。对于MT(来电)来讲，首先还是会由Modem接收到信息，然后发给RILC，RILC再发送给RILJ，并在RILJ的RILReceiver中接收到并进行处理。MTK对于Modem侧的AT指令进行一些定制，这和AOSP原生使用CLCC方式后去来电信息不同，MTK这里使用了自己添加的AT指令ECPI来反馈通话状态改变的信息。后面会针对MTK的log进行一个简单的分析，根据log来分析 M

之前有分析过Android 4.2的InCallScreen结构(传送门)，但后面Google发布了Android 4.4即Kitkat，遂决定以之前的文章为模板，重新整理并记录。在4.4中当有来电或去电时，显示给用户的界面如图1，在4.4之前称之为InCallScreen，但在4.4之后叫做InCallActivity。在4.4中我们调出的拨号盘界面，实际为DialtactsActivity并隶属于Dialer应用.

对于手机OEM/ODM厂商来讲，客制化是必不可少的。国际厂商比如三丧，LG等等。我们买到的手机，系统都是经过定制的，这跟Google Android AOSP有很大的区别，这些区别就是厂商们想搞的差异化。以下内容为GlowPadView客制化的一些笔记，怕以后忘了再去查。       GlowPadView就是用来实现滑动接听的控件，该控件隶属InCallScreen界面，也就是我们拨打或接听

最近在做类似于三星S4的那种皮套(后面简称SmartCover)，具有可操作的窗口，一方面用户可以保护手机屏幕，另一方面用户可以直接在SmartCover上接听电话，非常方便。在开发过程中发现一个问题，虽然最终解决但还是记录一下，好记性不如烂笔头啊。

想查看锤子ROM的“显示GPU过度绘制”情况，没想到竟然被屏蔽了，那只能自己动手咯！！！

今天遇到一个很奇特的问题，当用户设置了PIN码，在锁屏界面正常解锁PIN码后，进入Launcher时显示com.android.phone 已停止运行。一开始猜想会不会是解锁PIN码的时候处理导致了Phone进程报错，通过log分析找到了问题的大概原因：AndroidRuntime: FATAL EXCEPTION: mainAndroidRuntime: java.lang.Illegal

场景有的时候需要定制Android默认蓝牙设备名称，当然在我们有源码的情况下自然是很好处理，但如果没有源码呢？这时候就需要修改so文件了。蓝牙默认设备名称的修改在：frameworks\base\core\jni\Android_bluetooth_common.h 主要就是修改BTMTK_ANDROID_DEFAULT_LOCAL_NAME的值#define BTMTK_AN

InCallScreen是什么本文来自http://blog.csdn.net/yihongyuelan 转载请务必注明出处本文以MTK平台Android 4.2为分析对象，MTK在原生的基础之上添加了许多自己的东西，因此个别地方跟原生代码以及QCOM的代码不同，请读者知悉。在电话的呼出流程中，我们最后需要按下拨号键，才能将电话拨打出去，那么在按下拨号键之后

当手机Modem状态改变后会将状态变化信息通知到上层，通过《Android 4.4 Kitkat Phone工作流程浅析(八)__Phone状态分析》和《Android 4.4 Kitkat Phone工作流程浅析(六)__InCallActivity显示更新流程》的分析，我们知道了Phone状态的类型，以及这些状态的上报流程，而本文主要分析Phone状态改变之后是如何通知到三方应用的。

NotificationListenerService是Android 4.3 之后新增的接口服务，用于获取系统Notification信息，这在之前的Android版本是无法直接办到的。在Android 4.4中，增加了Notification.extra变量，使得获取Notification相关信息更加丰富，这些接口的开放更加利于三方应用的使用，但同时也会带来一些隐私问题。本文对NotificationListenerService的使用进行了分析，如果觉得不错请推荐一下吧 :)

本文主要描述了如何控制Android闹钟，简介清晰

Google在2015年3月9日低调发布了Android 5.1，从官方博客的描述来看只是进行了小幅更新，如增加多SIM卡支持，HD Voice支持等。虽然Google对外声称只是稳定性和性能上的微调，但在查看Telephony Phone相关代码后，Android 5.1在这一块的动作还是很大的。

在Android源码中，经常可以看到使用isLoggable来控制Log输出的代码，该方法可以非常方便的控制log输出，无论在user/userdebug/eng版本的系统中，isLoggable都能正常激活，便于开发者调试。

在前一篇文章《Android 5.0 如何正确启用isLoggable(一)__使用详解》中分析了isLoggable的使用方法，本文主要分析isLoggable实现原理以及user版系统root后永久enable isLoggable的原理，并使用脚本自动设置isLoggable相关属性。

我们在Android framework中修改资源文件时，在Android 4.0之前，都是直接在sourcecode/frameworks/base/core/res/res下面添加对应的资源文件，然后编译framework-res即可，但是这种情况到了Android 4.1就有改变了。按照以前的方法在编译的时候却会报错，提示找不到引用的资源文件，一般情况下找不到资源文件有以下几个原因：

在Android 4.4 中，Google 对Telephony_Phone进行了重构，前面也通过一些列文章分析了Android 4.4 中Telephony Phone的工作流程。但在2014年10月15日，Google发布了Android 5.0 预览版，正式版也在一个月之后发布。Android 5.0 变化非常大，无论从UI风格还是功能实现上，Google都进行了大刀阔斧的修改。同时，Telephony_Phone模块的架构也再次进行了调整，调整之后的Telephony_Phone各个模块之间耦合性更

Dynamic Adaptive Streaming over HTTP (DASH), also known as MPEG-DASH, is an adaptive bitrate streaming technique that enables high quality streaming of media content over the Internet delivered from conventional HTTP web servers. Similar to Apple's HTTP Li

Android boot animation is contained within a an uncompressed zip file called bootanimation.zip that can be found in the media folder of the system partition i.e. /system/media on the internal memory of the device. When device boot up,/system/bin/bootanimat

Google Android default using testkey, so we can change to our release key

本文以MTK Android 4.4 源码为模板，分析了Android 4.4 拨号流程。MTK在Android的原生的基础上添加了很多功能，比如VideoCall, 来电/去电归属地等等，这些功能是Android原生所不具有。MTK在加入这些功能的同时，为了方便后续移植使用了一套自己的架构即pluginManager ( Phone中使用ExtensionManager从PluginManager中获取实例，Contacts也使用同样的方式 )。什么是PluginManager呢？

本文主要分析了在InCallUI中PSensor如何控制屏幕的亮灭及其实现原理。全文分为三大部分，即：ProximitySensor初始化流程，ProximitySensor使用流程和PSensor工作流程。前两部分主要分析了上层应用如何使用PSensor提供的接口，第三部分则详细分析了PSensor如何控制屏幕的关闭/点亮。

无论是在MT (Mobile Termination Call被叫——来电)，还是MO (Mobile Origination Call主叫——去电) 流程中，通话界面上都会显示当前通话的名称( 后文以displayName指代 )。通常情况下，如果是一个陌生号码，则会显示为该陌生号码。如果是已知联系人，则会显示该联系人的名称。当然，在会议电话( Conference Call )的情况下则直接显示"会议电话"。但是，在某些特殊情况下，displayName还会显示诸如"私人号码"、"公用电话"、"未知号码

在上一篇文章《Android 4.4 KitKat NotificationManagerService使用详解与原理分析(一)__使用详解》中详细介绍了NotificationListenerService的使用方法，以及在使用过程中遇到的问题和规避方案。本文主要分析NotificationListenerService实现原理，以及详细分析在上一篇文章中提到的相关问题和产生的根本原因。

在Android 4.2中系统默认解锁是滑动到任意位置后就会解锁，如果想添加解锁内容需要修改如下代码：1.frameworks/base/core/res/res/layout/keyguard_glow_pad_view.xml - prvandroid:targetDrawables="@array/lockscreen_targets_unlock_only"- pr

案件还原：        修改Android 4.0源码中的Setting，添加一项功能之后，在eng模式下编译，一切正常，遂提交代码到服务器。第二天，传来噩耗，Setting上新添加的功能无法使用，一点击则报错。案件分析：        上传代码之前，已经在本地编译测试过，咋会有错呢？？！！管它三七二十一，操起adb logcat抓取log进行分析。不看不知道，一看吓一跳，log中显

很多时候，我们对源码进行二次开发编译时会报以下错误：packages/apps/Settings/src/com/android/settings/powersaver/PowerSaverDialogActivity.java:50: cannot find symbolsymbol  : variable toPowerSaverSettingslocation: class co

前面的三篇博文《Android 2.3 SD卡挂载流程浅析(一)》、《Android 2.3 SD卡挂载流程浅析(二)》、《Android 2.3 SD卡挂载流程浅析(三)》的分析，知道了SD卡挂载的消息是如何从底层传递到上层的，在《Android 2.3 SD卡挂载流程浅析(三)》中，我们已经知道了最后是在updatePublicVolumeState()中调用onStorageStat

在我们的程序挂掉之后，我们抓取log分析，有时候有以下提示：      "I/ActivityManager( 2212): Process com.seven.test (pid 2758) has died."      这句话的意思就是说我们的程序主进程已经死掉了，这肯定不是我们所期望的啊，那么这种错误如何分析呢？以下是我的分析过程      1.首先找到关键logI/D

最近在做东西的时候，发现有时会出现两个相同的Activity，本来从Act_A跳转到Act_B，那么按下返回键的时候正常情况下会返回到Act_A，但按下返回键之后居然还是Act_B，这问题一开始还让我纳闷了半天，不过了解了关于Activity的LaunchMode之后就豁然开朗了，在此留个笔记。        在Android 2.3中Activity的启动模式有4种，分别是：Standard

在前面两篇博文《Android 2.3 SD卡挂载流程浅析(一)》《Android 2.3 SD卡挂载流程浅析(二)》中，主要简单介绍了SD卡的挂载流程以及所涉及的关键文件。在《Android 2.3 SD卡挂载流程浅析(三)》中，将简要介绍Android 2.3中Vold的运行机制，并从接收内核uevent开始介绍程序调用流程。      1. Vold     Vold的全

前面六篇文章：      《Android 2.3 SD卡挂载流程浅析(一)》      《Android 2.3 SD卡挂载流程浅析(二)》      《Android 2.3 SD卡挂载流程浅析(三)》      《Android 2.3 SD卡挂载流程浅析(四)》      《Android 2.3 SD卡挂载流程浅析(五)》

在上一篇博文《Android 2.3 SD卡挂载流程浅析(一)》主要简单的介绍了SD卡的挂载流程。包括了从内核层到用户层事件消息的传递，以及Vold的简介。本文将继续介绍SD卡的挂载，但文中并不会涉及代码的详细分析，因为这部分网上已有资料，我会在文章结尾贴出来供大家参考。本文主要目的是一方面对自己学习这一部分的总结，另一方面希望大家能够指出文中理解错误的地方。      1.SD卡挂载

Android 2.3中关于SD卡挂载简介      在Android 2.3中，当SD卡插入系统之后，系统会自动挂载。Vold 就是负责挂载SD卡的，vold 的全称是volume daemon。实际上是负责完成系统的CDROM,USB 大容量存储，MMC 卡(后文有简介，具体请百度)等扩展存储的挂载任务自动完成的守护进程。它提供的主要特点是支持这些存储外设的热插拔。在Android上的这个

前面五篇文章：     《Android 2.3 SD卡挂载流程浅析(一)》     《Android 2.3 SD卡挂载流程浅析(二)》     《Android 2.3 SD卡挂载流程浅析(三)》     《Android 2.3 SD卡挂载流程浅析(四)》     《Android 2.3 SD卡挂载流程浅析(五)》       在这五篇文章中，简单的分析了将SD卡插

前面四篇博文：《Android 2.3 SD卡挂载流程浅析(一)》、《Android 2.3 SD卡挂载流程浅析(二)》、《Android 2.3 SD卡挂载流程浅析(三)》、《Android 2.3 SD卡挂载流程浅析(四)》主要是对SD卡的挂载流程从底到上的一个分析，本文将继续接着《Android 2.3 SD卡挂载流程浅析(四)》文章分析，前文主要分析了C/C++的一些代码，本文将主