MTK Android 10侧键改造成相机键：全链路实现

拿到一台MTK平台的Android 10.0板子客户提了个需求侧键要做成相机功能键按一下打开相机再按一下拍照。听起来很简单对吧不就是把侧键的键值映射成KEYCODE_CAMERA再让相机App处理一下快门事件嘛。可真上手之后你会发现这件事从内核驱动到Framework再到App整整串了四五层任何一层没配合好按键都会像石沉大海一样毫无反应。这篇文章我就把自己在MTK 10.0上把侧键调成相机功能键的完整过程拆开来讲包括需求定义、按键事件链路、.kl映射改法、Framework截获快门事件、以及各种改了没反应的坑。适合做方案定制、系统集成的工程师也适合想搞懂安卓按键到底是怎么流转的的App开发同学。1. 拿到需求先别改代码把相机功能键拆成几种行为很多人接定制需求的第一反应就是改个键值映射就行了但相机功能键这句话太模糊了不同产品对它的预期完全不一样。我先花点时间问清楚了四种常见行为再决定改动路径。1.1 四种常见行为定义第一种是快捷启动相机任何界面下按一下侧键直接拉起系统相机这是最容易实现的本质是一个全局快捷键。第二种是相机内按一下拍照相机界面下侧键变成快门按下触发对焦松开拍照或者按下直接拍。这一层需要Camera App配合处理KeyEvent或者由Framework直接把快门事件塞给Camera应用。第三种是息屏直接拍屏幕关着、系统锁着长按或连按侧键直接打开相机并拍照。这个改动会牵扯到锁屏、Doze模式、唤醒逻辑复杂度和前两种不是一个量级。第四种是特殊手势组合比如同时按侧键和音量下键截屏或者长按侧键录视频。这基本就要走Framework或PMS层的key intercept逻辑了。回到我手上这个需求客户描述是侧键做相机功能键按一下打开相机在相机里按一下拍照再按一下或者按返回退出。这就是第一和第二种的组合不涉及息屏直拍我松了一口气。但即使如此真正落地时依然踩了好几个坑。1.2 MTK平台为什么要单独讨论MTK和Qualcomm在按键处理上有个明显区别MTK平台很多非标准按键侧键、功能键、NFC快捷键之类的往往不是走Linux标准的gpio-keys驱动而是挂在PMIC或者EINT中断上由MTK的misc和input子模块上报。这就导致一个问题你以为改了Android的kl文件就有用实际上内核端可能压根没把物理按键报成Linux键值或者报成了一个奇怪的扫描码。这也是为什么网上一搜MTK按键进入拍照会浮出一堆跟驱动、dts配置、按键上报有关的帖子。MTK的按键个性化定制起步阶段先要确定物理按键在哪个input设备上、以什么scancode上报然后再谈Android层的键值映射否则后面全是空中楼阁。2. 按键从硅片到App的完整旅程MTK上报链路的来龙去脉在动手之前我觉得有必要把按下侧键到相机快门被触发这条链路完整过一遍。搞不清楚这条链路改错层的代价就是反复编译、反复刷机、反复无效。2.1 物理到内核GPIO/EINT与Linux input keycode侧键物理上是一个轻触开关按下后把某个GPIO拉低或拉高MTK芯片通过EINT外部中断感知电平变化然后由平台驱动上报一个键值。比如常见的侧键可能上报KEYCODE_F159或KEYCODE_F260有的模组干脆恶心一点上报成一些多媒体键或未知扫描码。MTK平台定制按键早期方案喜欢在dts里加gpio-keys节点keypad { key_side { label Side key; linux,code KEY_F1; gpios pio 78 GPIO_ACTIVE_LOW; gpio-key,wakeup; debounce-interval 5; }; };不过MTK 10.0的板子很多是直接把按键走到PMIC的pressed/key中断里不一定在dts里看得到。所以最可靠的方式是先拿到root shell直接getevent看物理键到底报了哪个input event这一步能省后面80%的自我怀疑。2.2 InputReader与.kl映射Android这边先认个脸内核把键值报上来之后Android的InputReader会读取/dev/input/下的event设备然后用.kl文件把Linux键值映射成Android层的KeyEvent。这个映射文件在AOSP里叫Generic.klMTK设备上通常是mtk-kpd.kl、mt8167-kpd.kl之类的路径一般在/system/usr/keylayout/或/vendor/usr/keylayout/。典型的一行长这样key 59 CAMERA意思就是Linux键码59映射成Android的KEYCODE_CAMERA27。注意第2列的CAMERA是Android的KeyCode标签不是最终KeyEvent的数字值最终值在KeycodeLabels.h或InputEventLabels.h里查。表我这次用到的最关键映射Linux键码kl标签Android KeyEvent用途59F1KEYCODE_F1(131)侧键原始上报60F2KEYCODE_F2(133)侧键原始上报27CAMERAKEYCODE_CAMERA(27)相机快门80FOCUSKEYCODE_FOCUS(80)对焦24VOLUME_UPKEYCODE_VOLUME_UP(24)音量上/拍照2.3 快速定位当前键值和无头绪时的诊断命令如果你不确定手上的板子侧键当前上报的是什么用这三板斧最快# 1. 看哪些input设备是按键设备 adb shell dumpsys input # 2. 监听原始键码 adb shell getevent -l # 3. 看当前Klayout加载信息 adb shell dumpsys input | grep -A 5 KeyLayoutFile我在一台MT6765板子上实测侧键被内核报成了KEY_F1scancode 59Android默认把59映射成KEYCODE_F1所以App收到的就是KEYCODE_F1跟拍照毫无关系。定位到这第一步后面的改动就很清晰了。3. 第一步改动把侧键在系统中注册成KEYCODE_CAMERA既然内核已经把侧键报成59了Android层的第一步就是改映射把59从F1改成CAMERA。3.1 修改.kl文件与KeycodeLabels的步骤MTK 10.0设备上我习惯先查设备的kl文件是哪个adb shell su 0 ls /system/usr/keylayout/ adb shell su 0 ls /vendor/usr/keylayout/找到对应kl后修改59那一行key 59 CAMERA注意不要直接改AOSP的Generic.klMTK设备上很可能会被平台自己的kl覆盖改了Generic.kl等于白改。应该改设备具体加载的那个kl或者新建一个Vendor_XXXX_Product_XXXX.kl让InputReader按vendor/product匹配。改完后还有一步很多人漏掉如果打算新增一个Android KeyCode标签需要在framework/native/include/android/keycodes.h或KeycodeLabels.h里同步加但因为我们用的是现成的CAMERA压根不需要加新标签所以官方用kl映射就够了。3.2 改完没反应常见的原因清单改kl后没反应我列一下我在MTK平台上遇过的可能原因按概率排序kl文件被SELinux策略挡了加载失败。这种情况dumpsys input会打印找不到对应字库文件或拒绝读取。改错了kl文件。系统实际加载的是另一个设备的kl你改的是Generic.kl。设备事件没走InputReader被MTK的mtk-kpd驱动半路截住了。改了文件但没重启system_server。kl映射是在InputReader初始化时加载的必须重启UI进程。我的做法是先临时push一个kl文件到/data/local/tmp再用adb shell input keyevent 59做一次软件注入测试如果软件注入能被识别为CAMERA但物理按键不行那就多半是驱动层或input设备匹配的问题。3.3 一个很多人忽略的厂商分区问题Android 10的MTK平台普遍有system和vendor分区只读保护user版本还带dm-verity。你想直接adb remount改kl大概率会失败。adb root adb disable-verity adb reboot adb remount这条路在MTK userdebug上偶尔可行但如果是user版本就得老老实实编译system.img或vendor.img再刷机。MTK平台刷机也不要乱来OTA的logo.bin和vendor分区变动都会导致开机异常我遇到过一版改错vendor导致开机卡在logo的情况后来用SP Flash Tool强刷才救回来。所以正规做法是在源码里改vendor kl文件编vendor.img用update或fastboot刷vendor分区不要图快直接改system。毕竟侧键做相机功能键只是一个小需求搞到变砖就得不偿失了。4. 真正难的不是键值是App的拍照交互把侧键映射成KEYCODE_CAMERA之后我以为到了拍照这一步很简单——Camera App接到KEYCODE_CAMERA自然会拍照。结果一测按下侧键相机打开了但再按侧键没反应。4.1 Camera App通常怎么接KeyEventAOSP原生相机确实处理了KEYCODE_CAMERA但很多三方相机App、厂商定制相机、甚至一些轻量版相机App压根没有处理这个键。它们的拍照逻辑只监听两种KEYCODEKEYCODE_VOLUME_UP和KEYCODE_VOLUME_DOWN因为音量键兼容性最好、最无脑甚至有的ROM里连屏幕上的拍照按钮都不是App自己画的是SystemUI加的一个Activity。所以你的Camera App到底会不会响应KEYCODE_CAMERA必须先确认。最简单的方法adb shell input keyevent 27如果相机界面下发了27没反应就是App没处理这个KeyEvent。这时候有三条路改Camera App源码加KEYCODE_CAMERA的onKeyDown/onKeyUp逻辑。在Framework层把KEYCODE_CAMERA转换成别的键事件比如转换成App已经处理过的KEYCODE_VOLUME_DOWN或KEYCODE_FOCUS。在Framework层干脆不再往下发直接改由Camera应用代码通过Camera2 API触发拍照。4.2 焦点问题与事件被吞的现象即使App处理了KEYCODE_CAMERA还有一个焦点陷阱按键事件默认先派发给当前窗口如果当前界面不是Camera Activity而是桌面、系统UI那事件根本到不了Camera Activity。更恶心的是时序问题按下侧键你拦截KeyEvent并启动CameraActivity但Activity还没onResume此时第二次按侧键事件可能被SystemUI或Keyguard吃掉。这也是为什么按一下打开相机和在相机里按一下拍照是两个感受完全不同的需求前者是全局事件后者要求焦点必须在Camera App上。我曾经为了处理这个时序问题在Framework的PhoneWindowManager.interceptKeyBeforeDispatching里做状态机第一次按侧键启动相机记录时间戳300ms内收到第二次ActionDown就派发给相机超过300ms当作新的启动请求。实测下来比无脑拦截好用很多。4.3 为什么音量键拍照在部分手机上失效顺带说一下很多人问的事为什么有的手机上音量键能拍照有的不能原因还是在App和Framework两层。App层处理KEYCODE_VOLUME_DOWN拍照同时Framework层又把KEYCODE_VOLUME_DOWN当成系统音量下降来处理。如果Framework在dispatch之前拦截了音量键App永远收不到。AOSP在PhoneWindowManager里有音量键的特殊逻辑如果当前窗口是MediaSession要响应音量PMS会直接把事件消费掉。从这件事可以引出一个结论做侧键相机功能键最好的姿势不是在App层蹭事件而是先在Framework定格清楚——这个键是系统级快门还是App级快门。如果是系统级快门Framework拦截后启动Camera并发送快门KeyEvent或直接用RemoteControlClient/MenuAction的方式通知App如果只是App级快门就做好焦点管理别让别的界面抢事件。5. Framework层截获方案让侧键在系统里说了算考虑到兼容性和可控性我最后的方案选了Framework截获。原因很简单客户的三方相机App不可能允许我改源码我不能指望App去响应KEYCODE_CAMERA只能让系统统一处理快门事件。5.1 什么时候必须走Framework你是AOSP源码方案商、像我们一样的系统定制方手里握着framework源码走Framework拦截几乎是一劳永逸的选择。具体来说有几种需求必走Framework息屏/锁屏下长按侧键打开相机并拍照任何界面下单侧键立即打开相机哪怕当前处于全屏游戏既要有打开相机又要有在相机内拍照且不允许出现打开瞬间又拍照的误触发需要同时绑定多个手势长按、双击、组合键。5.2 截获KeyEvent并启动相机的实现逻辑以AOSP 10的PhoneWindowManager.java为例核心逻辑在interceptKeyBeforeDispatchingOverride public long interceptKeyBeforeDispatching(IBinder focusedToken, KeyEvent event, int policyFlags) { final int keyCode event.getKeyCode(); final boolean down event.getAction() KeyEvent.ACTION_DOWN; if (keyCode KeyEvent.KEYCODE_CAMERA) { if (down event.getRepeatCount() 0) { boolean cameraActive isCameraActive(); if (!cameraActive) { launchCamera(); mSideKeyDownTime event.getEventTime(); return -1; // 拦截不派发 } } if (event.getAction() KeyEvent.ACTION_UP) { // 如果相机已激活且当前时间接近按下时间避免误触发 long duration event.getEventTime() - mSideKeyDownTime; if (duration 350) { // 视为同一个按下周期不再重复启动 } } } return super.interceptKeyBeforeDispatching(focusedToken, event, policyFlags); }启动相机的Intent有两个选择MediaStore.INTENT_ACTION_STILL_IMAGE_CAMERAandroid.media.action.STILL_IMAGE_CAMERA和直接指定包名。前者会走系统默认相机后者适合客户明确要某个特定相机App。我倾向用前者因为客户可能换相机App用系统标准Intent更健壮。5.3 拦截与分发之间的时序细节拦截方案写起来不难难在时序。我在MTK 10.0上遇到过按下侧键相机打开了但松手的一瞬间又触发了一次截屏/返回的问题原因就是ACTION_UP没有拦干净事件漏给SystemUI处理了。所以Framework拦截时必须成对处理Down和Up两个都拦住。不然就会出现ACTION_DOWN启动相机ACTION_UP被SystemUI识别成返回键或截屏键用户操作体验很分裂。另外如果是做息屏直拍方案还要联动PowerManager.wakeUp()和KeyguardManager先亮屏再启动相机。MTK平台在这一步也要注意个别板子在doze状态下按键唤醒只走power键通路其他按键的上报路径会被PMIC关断处理起来跟普通唤醒不一样需要跟MTK原厂确认平台行为。我这次需求不涉及息屏直拍所以主动放弃了这部分只是在代码里留了KEYCODE_CAMERA从锁屏启动相机的处理没有做完整唤醒链路。6. 实机验证与踩坑排查链路改完代码、编完bin、刷上机之后我以为大功告成结果花在调试上的时间比写代码还多。这一节我把完整的排查链路和几个值得记录的坑分享出来。6.1 一个完整的排查流程拿到一台刷好包的MTK 10.0机器侧键相机功能键异常时我按这个顺序查第一步确认物理键有没有上报adb shell getevent -l按下侧键看有没有/dev/input/eventX和对应的KEY_F1/KEY_CAMERA输出。如果没有问题在驱动或dts改Android层没用。第二步确认Android层收到什么键值adb shell getevent -l adb shell input keyevent 27软注入27如果能触发热键说明系统层映射正常如果不触发问题在PMS拦截逻辑或Camera App接收逻辑。第三步看焦点和窗口状态adb shell dumpsys window | grep -E mCurrentFocus|mFocusedApp adb shell dumpsys input确认按下侧键时当前焦点窗口是哪个CameraActivity是否真的resume了。第四步抓event log和system logadb logcat -b events | grep -i keyevent adb logcat -b system | grep -i PhoneWindowManager看KeyEvent有没有被PMS拦截拦截后有没有执行到launchCamera。这个流程基本能把99%的侧键相机键失灵问题定位到具体层。我也建议你在自己的板子上把这套排查顺序固定下来别一上来就怀疑kl映射很多问题根本轮不到kl出场。6.2 几个我在MTK机器上遇到的经典坑坑一改了kl但不生效原因是MTK加载了vendor kl而不是system Generic.kl。这种情况改Generic.kl没用确认一下dumpsys input | grep -A 5 KeyLayoutFile。坑二相机打开了但打开瞬间又拍了一张照原因是Framework没有拦截ACTION_UPCommon的相机会把这次Up也当成快门响应。在PMS里对同一个KeyEvent周期内的Down/Up做配对消耗即可。坑三侧键映射成CAMERA之后三方相机依然没反应但音量键拍照正常。验证方法在相机界面执行adb shell input keyevent 24音量上如果能拍照但27不能就不要纠缠了直接改成Framework把相机侧的侧键事件翻译成音量快门或发送MediaAction。坑四MTK平台按键设备和触屏设备事件挤压InputReader在同一时间片内处理多个事件侧键快速连按时漏事件。这个我们后来通过抓dumpsys input发现事件其实进了队列只是App侧onKeyDown回调太慢丢了最后是让Camera App用HandlerQueue串行处理KeyEvent解决。坑五user版本无法remount修改验证效率极低。以后凡是涉及framework改动建议一开始就用userdebug版开发或者配置好adb disable-verity流程否则每次验证都像在原地踏步。6.3 顺手整理一份调试常用命令我把这次用得最多的调试命令整理成一个备忘你直接抄# 查看按键布局加载情况 adb shell dumpsys input | grep -E KeyLayoutFile|KeyCharacterMap # 查看当前焦点窗口 adb shell dumpsys window | grep -E mCurrentFocus|mFocusedApp # 查看input设备列表 adb shell getevent -i # 实时查看事件 adb shell getevent -l # 演示按键注入 adb shell input keyevent 27 adb shell input keyevent 24 # 查看PMS拦截日志 adb logcat -b system | grep PhoneWindowManager # 查看KeyEvent分发日志 adb logcat -b events | grep -E key|AM_ACTIVITY这套命令在MTK和Qualcomm平台上都能用不挑平台建议保存。以后做类似的功能键定制打开日志的瞬间你就能判断出问题在哪一层不用瞎猜。我自己在侧键做相机功能键这个需求上摸爬滚打后最大的体会是Android的按键机制从Linux input到Klayout再到InputDispatcher是一环扣一环的链条想走捷径跳层改动大概率会引入更诡异的问题。真正靠谱的打法是先把这个键在当前产品里应该是什么行为定义清楚再从驱动往上逐层确认没断点最后才做Framework或App的处理。如果你也是做MTK平台定制建议把这套链路里的日志命令记下来下一个功能键需求你一定用得上。