简介AndroidDialer 是一份基于 Java 开发的谷歌拨号器工程主要面向 Android N适合有一定 Android 基础、想研究官方拨号器交互逻辑与界面实现的开发者。资源包采用 zip 压缩格式大小约 12.73MB文件总数与具体类型明细暂未提供从资源描述推断主体应是 Android 工程源码、依赖配置和示例截图包含 appcompat、recyclerview、cardview、design、support-v13 等依赖库运行要求为 Android OS 5.0 及以上版本。目前已有 1572 人学习浏览。通过这份资源读者可以掌握 Google Dialer 的整体工程结构理解拨号列表、联系人数据绑定、通话界面切换以及 Material Design 组件在实际项目中的组合方式也可借助示例截图核对运行效果。对正在做拨号器相关功能或希望借鉴谷歌工程实践的开发者来说这是一份能够直接导入查看、方便二次开发的参考代码能节省从零搭建依赖与界面的时间。1. 谷歌拨号器到底是什么先搞清你改的是哪一层安卓源码树里有一个叫 Dialer 的系统应用管着拨号盘、通话记录、联系人搜索和来电界面开源社区习惯叫它谷歌拨号器。它和从网上下载的第三方拨号 App 有个本质区别它直接绑定系统的通信框架通话状态、联系人缓存、数据库权限都有一层现成链路。很多人拿到它就想改结果一改就翻车。问题大多出在没分清 Dialer 和底层框架的职责边界把 UI 层的事和数据层的事混在一起改最后编译过了真机上却闪退、重复记录、黑屏轮着来。这篇按“架构 → 编译 → 定制 → 避坑 → 验证”的顺序讲适合正在做系统裁剪、ROM 定制或者想把拨号器模块迁移进自己系统里的开发者。先花三分钟看架构再照着命令动手能少走很多弯路。你不需要对整个安卓源码有完整认知只要熟悉应用层开发并且手上有一套可编译的源码树就能照着落地。2. 谷歌拨号器的架构与模块边界Dialer、Telephony 和 InCallUI 各管什么2.1 Dialer 不是通信底层拨号盘只是壳Telephony 才是大脑AOSP 拨号器虽然叫“拨号”但它自己不负责建立呼叫。每次点下拨号键Dialer 做的其实是发一个带号码的 Intent剩下的路由、SIM 选择、音频通道管理全部交给 Telephony 框架。常见做法是这样区分Intent.ACTION_CALL是直接拨出ACTION_DIAL只是打开一个带号码的拨号界面。两者看起来差不多定制时差别很大。如果你在开机自启或第三方跳转逻辑里把 Action 写错设备会跳过通话界面直接呼出用户连二次确认的机会都没有。我在做过的一个定制项目里一开始以为通话界面卡顿是 Dialer 渲染问题花了好几天调布局后来把日志打出来才发现是音频路由切换阻塞了 UI 线程。那一次之后我习惯先把边界画清楚Dialer 是壳负责展示状态Telephony 是大脑负责维护状态。改壳不会影响通话但改错壳和数据链路的连接方式很可能让来电无界面、通话记录错乱。还有一点容易忽略Dialer 依赖TelecomManager和CallRedirectionService这类系统服务裁剪系统时如果把 telephony 模块砍掉了拨号器即便编译成功刷进设备也拉不起一通电话。所以判断一个定制方案能不能落地不能只看 APK 有没有编出来要看它依赖的服务模块有没有跟着进镜像。Dialer 通过 Binder 订阅电话状态具体接口在不同分支里叫TelephonyCallback或旧版的PhoneStateListener。它只拿状态去做 UI 展示不解析信令。有一段时间我想在来电界面显示小区和基站信息在 Dialer 里加了一堆日志数据永远是空的。后来去 framework 层翻了一遍才明白原始的小区信息在 RIL 层Dialer 拿不到得通过TelephonyManager的 API 往上透传。这个例子说明模块边界越清楚定制成本越低。前期花半天读一下packages/apps/Dialer的依赖关系比后期反复试错划算得多。2.2 模块构成拨号盘、通话记录、联系人 Tab、InCall 界面AOSP Dialer 不是单一 Activity它是多个模块的集合。定制时最怕在错误的文件里改了半天发现那是别家的镜像产物。下面这张表可以帮你快速建立对应关系找文件时按表去定位提交点。模块主要职责常见路径定制热点DialtactsActivity主界面容器管理底部 Tab 和 Fragment 切换src/com/android/dialer/DialtactsActivity.java默认 Tab、Fragment 容器CallLogFragment通话记录列表src/com/android/dialer/calllog/CallLogFragment.java列表 item 样式、分组、去重ContactsFragment联系人 Tabsrc/com/android/dialer/contacts/ContactsFragment.java联系人排序、筛选InCallActivity来电和通话中界面src/com/android/dialer/call/InCallActivity.java通话按钮布局、号码显示CallerInfo号码对应的联系人信息telephony 框架或 Dialer 内封装归属地、号码标记注意这张表是结构对应不是源码快照。不同分支把CallLogActivity和InCallUI拆得不一样老版本还有独立的packages/apps/InCallUI。找路径时先看该分支有没有Android.mk或Android.bp以里面声明的LOCAL_PACKAGE_NAME和模块名称为准别靠目录名猜。我在一个分支里遇到过packages/apps/Dialer目录下放的根本不是拨号器而是某厂商的定制壳真正的谷歌拨号器源码挪进了私有目录那种情况按模块名搜更稳妥。2.3 为什么厂商都基于 Dialer 改而不重写一个主要原因是三个现成的东西数据模型、数据库、状态恢复。通话记录写入由CallLog.Calls这个 ContentProvider 处理Dialer 只需要 query 它联系人的电话号码、头像、搜索也有ContactsProvider兜底。你在 Dialer 里改 UI不用动底层数据库结构这比从零写一个拨号器省了一个数量级的工作量。另一个原因是状态恢复链路。来电、断线、切换音频设备这类场景AOSP 已经有一套成熟的回调链路比如Call状态变化通知CallListCallList再驱动 UI 更新。自己重写很容易在这块踩坑来电黑屏、通话结束还显示旧状态都是重写者常撞的事故。我在某公司项目里见过一个团队最初想自研拨号器做了三个月只到“来电能展示、拨号能呼出”状态恢复仍然不稳最后回到 AOSP Dialer 上换皮两周就交付了。不是说自研一定不行而是拨号器的价值在于和系统服务衔接这部分复用现成的把精力花在 UI 和产品差异化上才划算。换皮不换芯意思是不动 Dialer 的数据查询和状态管理逻辑只替换 UI 资源、配色、图标和部分 Fragment。这样做既保留了谷歌拨号器的稳定性又能让产品看起来像自己的。换皮时最容易被牵制的是三方依赖。AOSP Dialer 会依赖一些内部库不同分支里这些依赖要么在packages/apps/Dialer同级目录要么已经被剥离成独立模块。遇到缺依赖编译失败不要硬绕直接在该分支源码树下搜LOCAL_STATIC_JAVA_LIBRARIES或static_libs里的库名把对应模块一并加进PRODUCT_PACKAGES就好。还有一个进程层面的坑有些系统版拨号器被配置成persistent系统进程重启后会自动拉起保证来电界面随时可用。部分定制为了省内存把它改成非 persistent结果通话时拨号器进程被杀导致来电界面延迟好几秒。如果你在做整机方案不要把拨号器改成普通应用尽量保留它的系统常驻属性内存占用远没有你想象的大。3. 把谷歌拨号器编进系统源码位置、构建变量与最小命令3.1 源码树里找 Dialer先认路径再认分支谷歌拨号器源码在 AOSP 的packages/apps/Dialer下这是一个约定位置绝大多数分支和衍生系统都沿用。比较新的裁剪版把紧急拨号独立成了EmergencyDialer更老的版本还会把通话界面拆成InCallUI。你需要先确认手里这套源码用哪种结构看packages/apps下有没有同名目录再打开Android.bp或Android.mk查LOCAL_PACKAGE_NAME。有些渠道把拨号器改名成DialerNew或者挪进vendor下的私有目录这时候去默认路径找不到。识别技巧很简单用命令搜一遍模块名find packages/apps -name Android.bp | xargs grep -l Dialer 2/dev/null这段命令的作用是列出所有声明了 Dialer 相关模块的构建文件。逻辑说明Android.bp是安卓新构建系统 Blueprint 的入口模块名通常写在name字段grep -l只输出匹配文件路径避免刷屏。参数说明如果不加2/dev/null遇到无权限目录会打一堆噪音如果一条数据都没有说明该源码树里 Dialer 不在packages/apps下再去vendor和device目录里搜。还有一种情况是依赖被拆分Dialer 依赖的公共库可能在另一个项目里编译时才统一拉取。报错信息里出现unresolved dependency时不是去网上找补丁而是就地查仓库清单把缺失的模块补进本地源码树。这里只讨论已经拿到源码树之后的依赖管理不涉及源码获取环节。3.2 PRODUCT_PACKAGES把 Dialer 变成系统必装应用系统应用不是“在开发机上能跑”就算数而是要构建脚本把它打进系统镜像。一般是在产品目录下的.mk文件里追加# 在 device/厂商/产品/产品.mk 中追加 PRODUCT_PACKAGES \ Dialer \ EmergencyDialer \ ContactsProvider每行一个模块名注意模块名必须和LOCAL_PACKAGE_NAME一致。加ContactsProvider是因为拨号器强依赖联系人数据裁剪时容易被误删。模块名写错不会在编译期报错只会被静默忽略最后镜像里没有拨号器这种失败在定制里最容易让人栽跟头。加完之后建议在构建日志里主动 grep 一下该模块名确认它真的被纳入产品包。PRODUCT_PACKAGES的语义是“必装应用清单”它不只是把 APK 拷进镜像还会处理模块间的依赖关系。比如 Dialer 依赖某个 framework 库构建系统会自动把库一起带上。所以这里的原则是只填你能明确说清用途的模块不要把整棵树的产品包都搬过来否则依赖地狱会在首次整包编译时爆发。3.3 最小构建命令单编 Dialer 和整包镜像开发阶段不需要每次都整包编译最快的是单编拨号器。下面是一组最常用的命令。# 1. 初始化编译环境 source build/envsetup.sh # 2. 选择产品userdebug 方便后面 adb root 和替换系统文件 lunch aosp_arm64-userdebug # 3. 只编译 Dialer 及其依赖 m Dialer # 4. 产物位置一般为 # out/target/product/generic/system/priv-app/Dialer/Dialer.apk参数说明userdebug比user多出 root 能力方便 push 替换系统文件和抓取日志aosp_arm64是通用目标产品名实际项目以你的目标设备为准。m Dialer只编译模块本身如果之前改过 framework 或联系人数据库要先把对应模块一起编译否则部署到设备上会因为接口不匹配闪退。验证单编产物最简单的方式adb root adb remount adb push out/target/product/generic/system/priv-app/Dialer/Dialer.apk /system/priv-app/Dialer/ adb shell reboot重启后打开拨号器能正常进入主界面说明单编链路没问题。这种方式只适合开发验证正式产线请用整包编译。另一个常见分歧是单编后界面资源还是旧的因为部分资源放在公共资源库里没被重新编进。遇到这种情况先m Dialer再对目标产品执行一次m整包让资源重新走一遍打包流程。不同编译系统行为不完全一样以报错提示为准。3.4 权限和签名为什么 Dialer 要放在 priv-appDialer 有读取通话记录、修改通讯录等敏感权限其中一部分只有特权应用才能拿到。priv-app目录是系统识别特权应用的固定位置放错成普通app目录会导致SecurityException现象是界面能打开但数据全空。这块我吃过不少亏所以现在习惯把“priv-app 签名对齐”当成检查清单第一条不要等闪退了再回头排查。# 查看应用是否作为特权应用被系统识别 adb shell dumpsys package com.android.dialer | grep -E pkgFlags|privapp如果pkgFlags里没有PRIVILEGED标记优先查镜像里 APK 的实际父目录路径。签名问题会更隐蔽开发阶段常用的测试 key 要和镜像里其他特权应用保持一致混签的后果是 Binder 调用被拒logcat 里会明确打印Permission Denial。这些错误有个特点重复出现、跟业务逻辑无关属于“构建配置错”而不是“代码错”。排查时不要一头扎进 Java 代码先把目录和签名对齐。4. 三个高频定制点默认页、归属地与通话记录样式4.1 把默认页从拨号盘换成通话记录改 Tab 的选定逻辑很多整机产品希望用户打开拨号器直接看到通话记录而不是拨号盘。常见做法是改DialtactsActivity的启动参数和selectTab逻辑。下面这段是一类很典型的实现// DialtactsActivity.java 的 onCreate 中 int startTab TAB_INDEX_CALL_LOG; // 默认改成通话记录 Intent intent getIntent(); if (intent ! null) { // 外部通过 ACTION_DIAL 拉起时仍回到拨号盘 if (Intent.ACTION_DIAL.equals(intent.getAction())) { startTab TAB_INDEX_DIALPAD; } } selectTab(startTab);逻辑说明先给默认值再根据 Intent 的 action 覆盖避免“从联系人点号码却跳到通话记录页”的错位。这里有两个关键常量TAB_INDEX_DIALPAD和TAB_INDEX_CALL_LOG不同分支可能命名成TAB_INDEX_CALLLOG以实际代码为准。selectTab内部会通知 Fragment 刷新不要试图直接改 Fragment 的可见性那样状态不同步。做完后重点测两个入口桌面点击图标、联系人详情页点号码。如果只改了onCreate而 Activity 配置了singleTask启动模式第二次从联系人跳转时走的是onNewIntent需要在里面补同样的判断逻辑否则会沿用上一次的页面状态。这个点很容易被忽略我在项目中就曾经只测了桌面入口结果联系人入口一直跳错页用户反馈上来才知道还有第二条链路。4.2 来电归属地CallerInfo 回调里的插入点AOSP 拨号器本身不带归属地库要显示归属地需要在号码查询链路里加一个补充步骤。常见做法是自定义CallerInfoAsyncQuery的监听器在号码查询完成后追加归属地字段。public class CustomCallerInfoListener implements CallerInfoAsyncQuery.OnQueryCompleteListener { Override public void onQueryComplete(int token, Object cookie, CallerInfo ci) { if (ci null || ci.number null) { return; } String normalized PhoneNumberUtils.normalizeNumber(ci.number); String location LocationDb.query(normalized); // 自己的归属地库 if (location ! null) { ci.geocode location; // 复用 geocode 字段显示归属地 } } }逻辑说明onQueryComplete是联系人数据库查完之后回到 UI 线程的回调在这里补归属地不会阻塞查询流程。normalizeNumber很关键来电号码常带空格、括号或国家码归属地库要按 E.164 格式建索引否则同一个号码会命中不了。参数说明ci.geocode在 AOSP 里原本用于地理信息借它来显示归属地可以少改 UI 绑定代码如果你新增字段要处理序列化成本更高不推荐。归属地库我一般做成 SQLite 放在 assets 里首次启动导入应用私有目录避免占用系统分区写入空间。不建议把号段硬编码成资源数组我在另一个项目里见过有开发者把几万条全国号段写进arrays.xml资源文件超过 8MB构建期差点撑爆而且号段一直在变硬编码注定要返工。SQLite 方案虽然首次启动多一点导入时间但后续升级、增量更新都方便。这个功能在通话记录列表、来电界面、去电界面都走同一条查询链路所以只改监听器一处即可。要注意的是通话记录列表的异步刷新归属地查询回来后如果列表 item 已经被回收直接更新Cursor是看不到变化的要把归属地缓存到Map里bindView时优先读缓存。4.3 通话记录 item 样式与分组改 Adapter 的绑定方法通话记录列表由CallLogFragment里的 Adapter 渲染每个 item 对应CallLog.Calls表的一行。想改布局和附加信息核心是bindViewpublic void bindView(View view, Context context, Cursor cursor) { ViewHolder holder (ViewHolder) view.getTag(); String number cursor.getString(cursor.getColumnIndex(CallLog.Calls.NUMBER)); long date cursor.getLong(cursor.getColumnIndex(CallLog.Calls.DATE)); // 显示归属地 String location LocationDb.query(PhoneNumberUtils.normalizeNumber(number)); holder.locationView.setText(location null ? : location); // 显示通话类型来电、去电、未接等 int type cursor.getInt(cursor.getColumnIndex(CallLog.Calls.TYPE)); holder.typeView.setText(CallLogUtil.typeToString(type)); }逻辑说明bindView是列表复用的关键ViewHolder复用 View避免频繁findViewById。这里查归属地用的是同步查询数据量小没问题如果列表滚动卡顿需要改成先设置占位符再异步刷新对应行。参数说明CallLog.Calls.TYPE的取值是系统固定的不要自己发明数值否则图标匹配、数据库查询都会出错。通话记录还有个高频需求同一号码多笔通话聚合成一条。只改bindView是不够的那是“显示时跳过”数据源里仍然是一行一行。常见做法是改 Adapter 的数据源在 query 阶段用GROUP BY NUMBER聚合取最新一条时间。这样做有个前提同一联系人用两个号码时聚合规则要设计好建议先用联系人 ID 聚合再用号码聚合避免双卡用户被错误合并。运营商标签这类需求也可以在bindView里做号段查询但不要写进数据库号码归属会变逻辑放数据库意味着每次发版都要迁移维护成本高。4.4 搜索拨号盘把号码匹配从内存层挪到 SQL 层拨号盘实时搜索是最容易被人抱怨“卡”的入口。AOSP Dialer 在输入地址过程中做内存过滤联系人一多就掉帧。常见优化是把号码前缀匹配推进ContactsProvider的查询里String selection Contacts.CommonDataKinds.Phone.NUMBER LIKE ?; String[] args new String[] { input % }; Cursor cursor getContentResolver().query( ContactsContract.CommonDataKinds.Phone.CONTENT_URI, new String[] { Phone._ID, Phone.DISPLAY_NAME, Phone.NUMBER }, selection, args, Phone.DISPLAY_NAME ASC);逻辑说明LIKE 前缀%在数据量小的时候足够快但如果联系人超过几千建议加一个规范化号码列并建索引不然每次输入都全表扫描。参数说明CONTENT_URI来自ContactsContract拨号器本身有读取权限不需要额外申请。这里最大的坑是号码格式化联系人可能存86 138...你输入的却是138...直接LIKE匹配不上。所以存储时就要落一列normalizeNumber处理过的号码查询时对输入也做相同归一化。拨号盘搜索属于高频路径做好了体感提升非常明显是所有定制点里性价比最高的一个。5. 避坑拨号器定制路上的 5 个经典翻车现场5.1 编译通过、打开闪退先查 priv-app 和签名问题现象模块编译成功m Dialer没有报错推送到设备后点图标直接闪退logcat 里全是ClassNotFoundException或SecurityException。原因大概率不是代码问题而是应用被放到了/system/app而不是/system/priv-app拿不到READ_CALL_LOG等特权权限或者 APK 签名和系统签名不一致导致 Binder 调用被拦。解决确认PRODUCT_PACKAGES里模块被编入priv-app目录检查输出路径中 APK 的父目录名跑一下adb shell dumpsys package com.android.dialer | grep -E pkgFlags|signatures看系统对它的权限标记是否包含特权属性。血泪经验闪退先看 logcat 里的 SecurityException别一头扎进 Java 代码找逻辑错误。5.2 通话记录出现两条一模一样的条目现象明明只打了一通电话通话记录里却出现两条。原因一种是你自定义的列表查询 join 了联系人表一对多膨胀了结果集另一种是 Adapter 的changeCursor被调用两次数据源里原本只有一行界面层重复渲染。解决列表绑定用CallLog.Calls._ID做唯一键不要用NUMBER或其他业务字段如果确实要合并同号码多条用GROUP BY NUMBER聚合而不是在bindView里跳过显示。ContentProvider 的notifyChange是异步的会触发全表刷新如果你在刷新回调里手动又插了一次数据就会看到明显的“假重复”。这个现象定位起来不算难按住条目看数据库_ID是否相同就能判断是数据层重复还是界面层重复。5.3 来电归属地不显示代码却执行了现象onQueryComplete里能看到 location 查到了日志也打了但界面不更新。原因归属地查询回调比 UI 绑定发生得更晚等数据回来时列表 item 已经被回收或复用。解决回调里拿到归属地后要按_ID或 position 定位当前正在显示的 View 再更新不要只改 Cursor常见做法是维护一个MapLong, String缓存bindView时直接读缓存没命中的再异步查询。另一个非常隐蔽的原因是号码匹配来电显示86138...你库里存的是138...没有normalizeNumber就查不到。这种查不到不会报错看起来就像代码没执行最容易让人多浪费半天时间。5.4 改完默认 Tab点联系人号码却跳去了通话记录现象桌面打开拨号器是通话记录页但从联系人详情点号码也跳到了通话记录页而不是拨号盘。原因DialtactsActivity被复用读取 Intent 时没有区分ACTION_DIAL把外部显式调用的意图覆盖成了默认值。解决在读取 Intent 时先判断 actionACTION_DIAL强制回到拨号盘同时检查启动模式如果是singleTask必须在onNewIntent里做同样判断否则第二次跳转沿用旧状态。这个坑要记住默认值和显式意图是两条逻辑不能用一个兜底值覆盖全部入口。我后来在代码里加了注释标明“桌面入口走默认页带号码入口走拨号盘”每次改动都会回归一遍这两个入口。5.5 来电能听到铃声屏幕却是黑屏现象来电铃声正常响但屏幕一直黑按电源键也不亮。原因InCallActivity的窗口属性或主题用了类似Theme.NoDisplay的配置或者拨号器依赖的锁屏状态判断被改坏系统把通话界面放到了后台。解决检查 Manifest 里 InCall 相关 Activity 的theme并确认对FLAG_SHOW_WHEN_LOCKED的处理符合当前分支的锁屏策略。这类问题模拟器上很难复现真机换一个锁屏方式可能就变所以拿到新设备第一件事是用adb shell dumpsys window看当前窗口状态确认通话界面确实在前台。还有一个原因是双屏或折叠屏的布局判断副屏被误判为不可见来电界面布局到了屏幕外只能真机多场景测试才能暴露。6. 验证与进阶用 adb 给拨号器做体检再挑一个高性价比定制方向6.1 用 adb 命令验证拨号器核心链路每次改完拨号器我建议先用三条命令做冒烟验证成本低反馈快。# 查看应用是否存在于系统以及权限标记 adb shell dumpsys package com.android.dialer | grep -E pkgFlags|versionName # 冷启动拨号器观察启动耗时 adb shell am start -W -n com.android.dialer/.main.MainActivity # 在无真实通话环境时验证通话界面能否拉起 adb shell am start -W -n com.android.dialer/.call.InCallActivity第一句判断应用有没有被系统当成特权应用有没有正确安装第二句的-W会打印冷启动总耗时改完启动逻辑后对比这个值第三句用于在没有电话网络的环境里验证通话界面是否正常拉起。注意InCallActivity的完整路径在不同分支有差异找不到就先执行adb shell dumpsys package com.android.dialer | grep Activity把组件列表拉出来。这几条命令解决的是“改完别翻车”的问题我每次改动后都会跑一遍。6.2 高性价比方向按联系人聚合通话记录 本地号码标记如果拨号器基础体验已经稳定下一个值得投入的方向是“按联系人聚合通话记录”。AOSP 默认按一笔笔通话平铺双卡联系人两个号码的记录会交错出现观感很乱。实现思路不复杂但自定义程度高先用CallLog.Calls.NUMBER做归一化关联到联系人 ID再把同一联系人的多个号码归成一组按最新时间排序。做法上可以维护一个小型 Room 缓存监听CallLog变化后重建列表层再合并展示。这一步做完拨号器的系统级质感会明显提升比去追那些复杂的智能接听场景好落地得多。还有一个投入产出比很高的补充本地号码标记。在CallerInfo回调里把常见服务号码或公司内部号码打上标签不需要联网也不涉及隐私争议用户体验却非常直接。这些功能共同点是改的不是 UI而是数据聚合方式风险小、可测试适合作为自定义拨号器模块化的起点。踩过这些坑之后我最大的感受是改拨号器最不值得的就是在 UI 上反复调颜色和图块真正拉开差距的是把数据链路捋顺。每次做完功能先在-userdebug版本跑一遍 6.1 的冒烟验证再打进真实镜像用半天真实通话重点盯“来电黑屏、记录重复、跳转错页”这三类回归。这个习惯在一个项目里帮我省掉了最多次返工。希望帮到你。本文还有配套的精品资源点击获取