去年把家里那台天猫精灵CCH从客厅角落翻出来的时候我原本只是想让它继续当个放儿歌的喇叭。后来发现它的底包其实是一套裁剪过的Android系统带屏、能触控、还留着调试口那点折腾的心思就压不住了。于是就有了这轮天猫精灵CCH部分可安装的apk测试——不是要把这台音箱改造成什么万能终端而是想摸清一件事在这套被厂商收得很紧的系统上究竟哪些APK能装上、哪些装上了能跑、哪些跑起来了却根本没法用。这篇文章就是把这几个月的记录整理出来从设备底子、调试通道、安装包筛选逻辑到实测清单和踩过的坑一条条讲清楚。适合手上有带屏智能音箱、想让它多干点活的人看也适合刚接触Android应用分发的朋友当作一份兼容性测试的思路模板。看之前先提醒一句所有测试都只针对你自己拥有的设备和你自己有权使用的应用安装来源要正当这一点是底线。1. 先搞清楚天猫精灵CCH到底是个什么样的安卓盒子1.1 硬件底子与系统裁剪它为什么能装APK很多人第一次听说智能音箱能装APK反应都是这不就是个喇叭吗。天猫精灵CCH这类带屏设备本质上是一台跑着Android的嵌入式终端和手机的区别不在是不是Android而在Android被裁掉了多少。我手上这台的核心是一颗四核ARM处理器配1GB到2GB级别的内存屏幕在7英寸上下分辨率不算高出厂固件基于较老的一代Android版本做了深度裁剪。裁剪体现在几个地方没有完整的Google服务框架没有应用商店的自由安装入口系统自带的Launcher被换成了语音优先的桌面安装第三方应用的权限被收在系统层。但APK的安装机制本身没有被拆掉——因为系统预装的音乐、视频、闹钟这些应用本身也都是APK。只要调试通道还在PackageManager这套东西就还在pm install就还有可能跑通。这就是整个测试的基础逻辑不是破解什么而是用系统自己留着的正规接口把应用装进去。理解这一点很重要因为它决定了后面所有的技术路线都围绕如何让系统的包管理服务接受一个外来APK展开而不是去改系统本身。顺便说一句不同批次的CCH固件差异不小。我手上这台开放了网络调试朋友那台同型号的早期版本则需要先通过串口或者特定的升级包才能打开。所以下面写到的路径如果在你机器上对不上别急着下结论说不行先按思路去找对应的那一项。1.2 哪些能力天生缺失决定了APK的成功率上限把APK装进去只是第一步能不能用得看它依赖什么。这台设备缺的能力我大致归成四类。第一类是输入方式。它只有触摸屏和语音没有鼠标、没有实体键盘、没有遥控器的完整方向键部分固件支持语音模拟返回。这就意味着任何强依赖右键菜单、悬停提示、组合键的应用装上去也是残废。我装过一个桌面级的文件管理器界面能打开但长按选中、拖拽移动这些操作根本触发不了。第二类是硬件传感器。没有摄像头部分型号有、没有GPS、没有陀螺仪、没有振动马达。地图类、扫码类、体感游戏类基本可以直接排除。第三类是服务依赖。没有完整的Google Play服务也没有国内几大厂商的推送框架。很多应用启动时会去检查这些服务是否存在检查不到就直接退出。这类崩溃在日志里非常典型能看到ClassNotFoundException或者明确的Service not found。第四类是显示密度。它的DPI值和手机差得远系统默认按大屏做适配。很多应用没有为平板做布局装上去之后控件会被拉伸得变形按钮跑到屏幕外面去输入框点了不弹键盘。这不是崩溃但比崩溃更让人难受因为你没法用。提示做兼容性测试之前先给设备列一张有什么、没什么的清单。后面每装一个APK都可以拿这张清单对照一下判断失败原因是环境缺失还是应用本身的问题。这一步能省掉大量盲目试错。1.3 动手前的三件准备工作第一件确认你能恢复。任何在系统层做的改动理论上都有变砖的可能。我不建议一上来就去动系统分区但如果确实要改设置至少先确认这台设备能不能通过官方渠道恢复出厂、能不能重新刷回原固件。我自己的习惯是动之前先在纸上把当前的关键系统属性抄一遍出问题了还能对照着往回找。第二件准备一台电脑和一个稳定的局域网。所有操作基本都靠电脑上的ADB工具完成网络不稳会导致调试连接频繁掉线排查起来非常浪费时间。有线网络比无线稳如果设备支持网口就优先用网口。第三件把要测的APK按来源分好类。我给自己的规矩是只测三类开源项目自己编译出来的包、应用官方渠道发布的安装包、自己写的测试应用。这样做的好处是出问题时能排除掉包本身被动过手脚这个变量排查方向会清晰很多。别人二次打包过的APK尽量别碰一是可靠性没保证二是来源不明的东西装进家用设备风险很大。2. 打开调试通道让电脑认得出这台音箱2.1 开发者选项与调试开关的开启路径Android系设备的通用套路是先连点版本号。CCH上的入口藏得比手机深一些通常在设置 - 关于或者设备信息里找到版本号或者系统版本连续点七次左右会提示已进入开发者模式。部分固件不在设置里给入口而是要在语音指令里说一句特定的话或者在设备信息页做特定的组合点击才会解锁。打开之后回到设置菜单会多出开发者选项。里面需要关注三个开关USB调试、网络调试ADB over Network、允许安装未知来源的应用。第三个开关有的固件叫外部来源应用位置可能在安全里而不是开发者选项里找的时候两边都翻一下。有个细节值得一提部分固件的开发者选项是假开的开关能点但重启之后自动关掉。我在一台早期版本上遇到过这个情况最后是靠开机后立刻连接、在有限的窗口期内把需要的包装完。这种体验很糟糕如果你也碰到了说明固件的策略比较严后面的测试要尽量一次到位减少反复。注意不要因为图省事就用来源不明的一键开启工具去刷固件或者改系统属性。这类工具的行为不可控进家用网络设备之后留下的隐患很难清理。能用系统自带入口就用自带入口。2.2 网络调试与USB调试的取舍CCH这类设备通常没有标准的USB数据口对外或者那个口只用于供电。所以实践中用得最多的是网络调试设备连上你家路由器电脑也连同一个路由器通过IP和端口建立ADB连接。网络调试的优点是摆脱了线材束缚你能坐在电脑前操作客厅里的设备。缺点是它依赖网络质量而且设备的IP地址如果由路由器动态分配重启之后可能变。我的做法是在路由器里给这台设备做MAC地址绑定固定一个内网IP后面所有脚本里直接写死这个地址省心很多。USB调试在支持的型号上更稳定但有它的麻烦一是驱动二是线材三是很多智能音箱的USB口默认只走充电协议。如果你手上有支持USB调试的固件并且能找到合适的线优先选USB否则老老实实走网络。连接命令本身很简单关键是首次连接时设备屏幕上会弹一个允许调试的确认框必须用手点一下始终允许。如果屏幕没弹或者你手慢了连接就会一直在等待状态。我一开始在这个环节卡了半个多小时一直以为端口不对其实是弹窗被系统通知盖住了。2.3 八条命令摸清设备底细通道打开之后别急着装东西先用命令把设备信息摸干净。这一步的信息决定了后面能装什么。adb connect 192.168.1.123:5555 adb devices -l adb shell getprop ro.product.cpu.abi adb shell getprop ro.build.version.release adb shell getprop ro.build.version.sdk adb shell wm size adb shell wm density adb shell pm list packages | wc -l这几条命令分别查的是连接是否成功、CPU架构、Android版本号、API等级、屏幕分辨率、屏幕密度、已安装应用数量。下面把关键的几项整理成表方便你对照自己的设备。命令输出含义对测试的影响getprop ro.product.cpu.abi主ABI架构决定APK的so库能不能加载getprop ro.build.version.sdkAPI等级决定APK的minSdk门槛wm size物理与逻辑分辨率决定布局是否会被裁剪wm density屏幕密度DPI决定控件缩放比例pm list packages已装包名列表判断是否与系统应用冲突我手上这台的ABI是armeabi-v7aAPI等级在较老的一档分辨率是1280×800级别DPI在160到240之间。这几个数字一出来很多判断就能提前做了比如只提供arm64-v8a的包直接排除要求API 26以上的包直接排除为手机竖屏设计的包要做好布局错位的心理准备。顺便说个容易被忽略的点wm size和wm density都可以临时改。改密度能让一些平板布局的应用显示得更正常但改完需要重启界面进程而且部分固件重启后自动还原。这个技巧后面第4节会细讲。3. APK筛选先判断能不能装再判断值不值得装3.1 ABI架构这道硬门槛Android应用的native代码是按CPU架构编译的装错架构的后果是安装能成功一启动就崩日志里通常是UnsatisfiedLinkError或者dlopen failed。这是最容易被误判成应用不兼容的情况其实只是包里没有对应架构的so文件。判断方法很简单把APK当成zip包解开看lib/目录下有哪些子目录。目录名就是架构标识arm64-v8a、armeabi-v7a、x86、x86_64。如果你的设备是armeabi-v7a那包里必须有armeabi-v7a这一份只有arm64-v8a的包装上去就是白搭。这里有个经验很多应用会同时打包多个架构包体积因此变得很大。测试阶段可以优先挑那些明确标注支持v7a的版本装起来成功率高体积也小。反过来一些新版本应用已经放弃了对老架构的支持只留64位这类包在CCH上基本没戏不用浪费时间反复重装。还有一种情况是纯Java/Kotlin的应用没有native代码那就不存在ABI问题只要API等级和权限过得去装上去就能跑。这类轻量工具应用反而是成功率最高的一批后面第5节的实测清单里跑得最稳的几乎都是这一类。3.2 分辨率与DPI布局错位比闪退更常见如果说ABI问题导致的是打不开那分辨率问题导致的就是打开了没法用。这两种失败在排查上的难度完全不一样后者更折磨人因为日志里什么都没有一切正常就是按钮点不到。原理上Android的布局系统会根据屏幕的宽高和密度去选择资源目录。系统里可能有layout-sw600dp这样的平板专用布局也可能只有layout一套手机布局。设备宽度落在哪一档系统就取哪一套。CCH的屏幕宽度算下来属于较大的一档会命中平板的资源目录——但如果应用压根没做平板布局它就会把手机布局硬拉伸到这块屏幕上结果就是元素位置全乱。实测中我遇到的典型症状有三种。一是输入框和键盘不同步点了输入框键盘弹不出来或者弹出来直接盖住整个界面。二是横向列表被截断只能看到前两三项滑不动也点不到后面的。三是弹窗按钮跑到屏幕外明明弹窗出来了就是关不掉只能强杀进程。应对办法有两条。一条是临时改密度用wm density把数值调小让系统按手机逻辑去渲染界面会变小但完整。另一条是找应用的历史版本很多老版本反而对多尺寸支持更规矩。这两种办法都有副作用改密度会影响所有应用装老版本可能丢功能具体场景具体权衡。3.3 权限、签名与系统白名单安装失败的原因里有一大半和权限、签名有关。Android的安装校验会检查好几层东西包名是否与已装应用重复、签名是否一致、目标API是否满足系统策略、申请的权限是否被系统允许。包名冲突是最常见的。同一个应用装过旧版本再装新版本时如果签名不一致系统会直接拒绝并提示签名冲突。解决办法是先卸载旧的再装新的代价是数据全丢。我一般会在卸载前用adb shell pm path记一下包的位置万一是系统预装的应用卸载后可能恢复不了得谨慎。签名不一致还有一种隐蔽的坑有些应用会校验自己的签名运行时发现签名被改过就主动退出。这类应用不会给你任何提示就是启动后闪一下没了。日志里能看到它调用了签名校验相关的API。碰到这种情况我的建议是不要试图绕过那属于改动别人的软件既没必要也不合适直接换一个功能相近的替代方案。权限方面CCH这类设备对某些权限是硬性拒绝的比如通话、短信、后台弹窗。应用申请这些权限时不会被弹窗询问而是被系统静默拒绝。如果应用把某个权限当成必需项拿不到就走异常流程表现就是启动失败。这种情况在日志里通常能找到明确的拒绝记录。错误提示常见原因处理思路INSTALL_FAILED_ALREADY_EXISTS同包名已安装先卸载旧版本INSTALL_FAILED_UPDATE_INCOMPATIBLE签名不一致卸载后重装勿混用不同来源的包INSTALL_FAILED_OLDER_SDK应用要求的API高于设备换低版本API的应用或换包INSTALL_FAILED_NO_MATCHING_ABISABI不匹配换支持v7a的包INSTALL_FAILED_INSUFFICIENT_STORAGE存储空间不足清理系统缓存与无用应用INSTALL_PARSE_FAILED_NO_CERTIFICATES包未签名或被破坏重新获取完整安装包3.4 装之前先做一次静态体检摸清规律之后我养成了一个习惯装之前先把APK做一遍静态体检五项内容两分钟能看完能省掉后面大量反复。第一项看架构前面说过。第二项看AndroidManifest.xml里声明的minSdkVersion和targetSdkVersion前者高于设备API等级就直接放弃。第三项看权限清单如果里面列了一堆明显和功能无关的权限比如一个闹钟应用要读通讯录那这个包我基本不会装风险太高。第四项看有没有声明leanback电视端或者android.hardware.touchscreen这类硬件特性前者说明它是给大屏遥控器做的方向键导航在触摸屏上会别扭后者说明它必须触摸屏对CCH反而是好事。第五项看包体积和dex数量体积异常小的可能要警惕是被裁剪过的体积特别大的老设备加载会很慢。这五项检查不需要任何专业工具命令行解压加文本查看就够了。如果嫌麻烦也有不少开源的APK信息查看工具可以做同样的事用哪个都行关键是养成先看后装的习惯。提示静态体检还有个额外好处能提前发现应用是不是需要联网激活或者登录。CCH上输入账号密码非常痛苦如果应用强制要求登录才能用那它在你这台设备上的实际价值就要打个问号。4. 实测流程从安装到启动跑通一条线4.1 安装命令与那几个关键参数的用法基础安装命令就一行但参数用对了能省事很多。# 常规安装 adb install app.apk # 覆盖安装并允许降级 adb install -r -d app.apk # 安装时直接授予全部运行权限适合触摸不方便的场景 adb install -r -g app.apk # 大包安装超时保护 adb install -r --streaming app.apk-r是覆盖安装保留数据测试新版本的时候必备。-d是允许版本降级这个在CCH上特别有用因为很多时候我们要往回装老版本才能跑通。-g是安装时一次性授予所有运行权限这个参数的价值在于CCH上弹权限对话框时按钮位置往往被系统界面挡住点不到用-g直接绕过了这个交互死结。--streaming是流式安装对大包友好。我测过的一个30多MB的应用用普通方式装会卡住加上这个参数就顺利了。设备存储小的时候这个参数值得记住。安装完要确认是不是真装上了别只看命令返回的Success。有的固件返回成功但实际没写进去再查一遍包列表更靠谱。adb shell pm list packages | grep 关键词 adb shell pm path 完整包名还有一类情况是系统不允许通过ADB装到主用户空间需要指定用户。这种情况我遇到过用--user 0指定用户空间后就能装了。不同固件的策略不一样如果普通安装一直失败但错误码看着不像权限问题可以试试这个参数。4.2 启动应用与日志定位的完整流程装上了不等于能跑。启动应用有两种方式一种是点桌面图标一种是命令行直接拉起。# 命令行拉起需要知道包名和主Activity adb shell am start -n 包名/主Activity全名 # 只看某个应用的日志 adb logcat | grep -i 包名关键词 # 抓崩溃日志 adb logcat -b crash # 清空日志缓冲后重跑日志更干净 adb logcat -c adb shell am start -n 包名/主Activity全名主Activity的名字如果不知道可以用dumpsys package 包名查输出里找android.intent.action.MAIN那一行附近的内容。这一步刚开始会觉得繁琐熟练之后几秒钟就能搞定。日志的读法是重点。我总结下来的规律是启动就退出看FATAL EXCEPTION后面的第一段堆栈那里指出了具体的异常类型和发生位置能进界面但操作无响应看ANR记录能看到主线程卡在哪个调用上界面正常但功能失效看SecurityException和Permission denied这类通常是权限被拒。有几个异常类型在CCH上出现频率特别高值得单独记一下。ClassNotFoundException基本等于应用依赖的某个库在系统里不存在无解换应用。UnsatisfiedLinkError是so库加载失败先查架构。IllegalStateException出现在启动阶段通常是应用初始化时拿不到某个系统服务属于固件裁剪导致的缺失。WindowManager$BadTokenException是弹窗时机不对一般出现在应用试图在后台弹窗时被系统拦截。4.3 交互改造没有鼠标键盘怎么办这是整个测试里最需要动脑筋的部分。CCH只有一块触摸屏和一套语音系统很多为手机的精确触控或者为桌面的鼠标操作设计的应用在这上面会显得非常别扭。我的做法是分层处理。第一层是能用就用很多应用的核心功能就是一两个大按钮触摸完全够用不必强求完整体验。第二层是用系统辅助能力补齐比如输入文字可以通过语音输入法如果系统装了的话或者ADB命令注入。# 通过ADB模拟点击坐标 adb shell input tap 500 300 # 模拟滑动 adb shell input swipe 500 600 500 200 300 # 模拟返回键 adb shell input keyevent 4 # 模拟输入文字不支持中文中文需要输入法方案 adb shell input text helloinput tap这个命令实测在CCH上非常好用因为触摸坐标是绝对的只要你知道按钮在哪就能精确点到。我甚至用一组连续tap命令把某应用的初始配置流程走完了全程没碰屏幕。这招在按钮被系统界面挡住的时候几乎是唯一的解法。第三层是接受残废。有些应用的交互模型和这台设备天然冲突比如需要同时按两个键的、需要长按拖拽的、需要精细缩放的。这类应用我会直接归类到不可用不再花时间优化因为投入产出比太低。4.4 桌面入口与开机自启的处理装好的应用如果不出现在桌面上用起来就很别扭。CCH的Launcher是定制的部分固件不会自动把新装的第三方应用显示在应用列表里。这时候有两个选择。一个是通过语音或者设置里的应用管理去启动每次都要绕一圈体验很差。另一个是自己做一个极简的启动入口。我的做法是找一个小巧的开源启动器把常用应用的快捷方式放在首页作为第三方Launcher运行。这种方式不改系统恢复很容易。# 查看当前所有可用Launcher adb shell cmd package query-activities -a android.intent.action.MAIN -c android.intent.category.HOME # 临时切换默认桌面部分固件支持 adb shell cmd package set-home-activity 启动器的包名/Activity全名注意切换默认Launcher之前务必确认新启动器能正常工作。我吃过一次亏切过去之后新启动器一直卡在加载状态桌面进不去最后是靠ADB命令把默认桌面切回来的。所以这条命令最好提前查好、记在手里再动手。开机自启这块CCH的系统管控比较严普通应用基本没戏。有些应用自带的自启开关在系统的后台清理策略面前也不管用。可行的方案有两个一是把应用设成自启动允许部分固件在应用详情页里有这个开关具体位置在权限管理里找二是干脆不用自启改成需要时通过ADB命令远程拉起配合手机上的自动化工具效果差不多还更省电。另外提一句存储压力。老设备的存储空间都不富裕装几个大包就满了满到一定程度系统会开始杀后台甚至装不上新应用。我的习惯是每测完一个应用就卸载一个保持存储占用在七成以下系统稳定性会明显好一些。5. 实测清单与结果对照5.1 影音播放类成功率最高的一档影音播放是这台设备最合适的使用场景原因是它对输入的要求最低——选片、播放、调音量全靠触摸和语音就够了而且这类应用普遍做了多尺寸适配因为要在手机、平板、电视盒子上都跑。实测下来本地的视频播放器表现最稳。挑那种支持硬解码、支持多种封装格式的播放器装上去基本能直接用界面按大屏渲染按钮尺寸也合适。需要注意的是解码能力CPU硬解支持哪些格式取决于芯片我遇到过一个号称支持全格式的播放器实际播某种编码时画面是绿屏换成另一个播放器就正常了这就是解码器实现差异。音频类应用的成功率同样很高逻辑简单、界面元素少。但我发现一个现象部分音频应用在锁屏或者切后台之后会被系统清理播放中断。这属于后台保活的策略问题跟应用本身兼容性关系不大。应对办法是把应用加入系统的白名单或者在设置里把它标记为不受限制。在线视频应用的情况复杂一些。有的能装能开但播放时会因为缺少某些解码组件而黑屏有的则是登录环节过不去因为界面上输入框太小点不准。我最后固定使用的是两三个功能极简的本地播放器在线内容交给手机投屏反而更顺畅。5.2 工具与轻应用类接近一半能用一半半残工具类应用是这次测试量最大的一类结果也最分化。跑得最稳的是离线工具。计算器、单位换算、时钟、番茄钟、简单的记事本这类应用逻辑简单、无网络依赖、无硬件依赖装上去基本就是即开即用。我装过一个纯离线的桌面时钟界面适配得很好当个摆件相当称职。文件管理类分两种情况。纯浏览的能用能看目录、能打开文件带复杂操作的会残因为长按选中、多选、拖拽这些手势在触摸屏上不好触发。我的折中方案是用ADB命令来做文件操作需要看的时候再看界面。下载工具要看它依赖什么。纯HTTP下载的能用走特定加速协议的常常失败因为它需要的某个底层库在系统里没有。阅读类意外地好用尤其是那些支持大字号和翻页手势的应用。屏幕尺寸对阅读来说是优势前提是应用支持横向布局否则文字会被拉得很怪。我测过一个只做竖屏的阅读应用横过来之后整页文字全挤在左半边只能放弃。系统类工具几乎全军覆没。清理大师、电池优化、性能监控这类应用深度依赖系统权限装上之后要么拿不到数据要么直接闪退。这类应用本来也是给手机设计的装在音箱上没有意义。5.3 游戏与大型应用能装的少能玩的更少先说结论这台设备不适合玩游戏原因不是性能是输入。所有需要虚拟摇杆、多点触控、精确点击的游戏都玩不了。能跑起来的只有一类点击类或者挂机类的轻量游戏操作就是一个点界面元素也少。我试过两个一个能正常玩另一个在加载资源的时候卡住了查日志发现是申请显存失败。大型应用的情况类似。社交类、地图类、电商类这些应用装上去往往能打开界面但接下来就会遇到一连串问题布局错位导致关键按钮点不到、需要扫码或者定位的功能直接不可用、后台服务被系统杀掉导致消息收不到。我个人不推荐在这类设备上装这些应用投入大量时间最后得到的体验还不如用手机。有一个例外值得一提投屏与控制类应用。这类应用本身就是用来控制别的设备的对本地硬件要求低装在音箱上反而能补足它自身的能力短板比如把它变成一个遥控中枢。这个方向我认为是最值得继续探索的。类别安装成功率可用率主要卡点本地音频播放高高后台保活本地视频播放高中高硬解格式支持在线影音中中登录交互、解码组件离线小工具高高基本无文件管理器高中多点触控手势阅读类中高中高竖屏布局锁定系统优化工具高低权限被拒、服务缺失轻量点击游戏中中显存、加载资源大型综合应用中低布局、定位、后台保活6. 常见故障速查与排错6.1 白屏、黑屏、闪退这三兄弟闪退最好排查因为有日志。启动后立刻消失的先看logcat -b crash堆栈里第一行就是根因。我遇到最多的三类是类找不到、so库加载失败、系统服务缺失前面都说过了。有一个不太常见但很容易误判的情况应用在启动时做了网络校验网络不通就走异常退出。这种闪退日志上看不出权限或类的问题反而能看到网络相关的超时异常。解决办法是先确保设备网络正常或者找不需要联网校验的版本。白屏是指应用能启动、能占满屏幕但一直白着不加载内容。这通常是渲染层初始化失败或者某个异步加载卡住了。排查方法是看logcat里有没有Texture、Surface、EGL相关的错误。CCH这类设备的图形栈是裁剪过的如果应用用了比较新的渲染API就可能初始化不了。这种情况基本无解换应用是唯一出路。黑屏分两种。一种是屏幕黑了但声音还在说明进程活着只是画面输出有问题通常是硬件解码器初始化失败导致的。换播放器或者换编码格式能解决。另一种是彻底黑屏无响应那多半是系统层出问题了需要重启设备观察。如果重启后还是黑说明刚才那次安装或启动把某个系统组件搞坏了要尽快卸载掉最近装的应用。排错我有个固定顺序写下来供参考先看进程是否存活ps | grep 包名再看崩溃日志再看系统日志里有没有权限或安全相关的拒绝记录最后看资源占用。这个顺序能从最常见的原因往下逐层过滤效率比乱翻日志高很多。6.2 装上了却找不到图标这个问题的出现频率高得离谱原因通常是Launcher没有刷新应用列表的机制或者应用的MAIN/LAUNCHER意图声明不完整。先确认应用确实装上了用pm list packages查。确认之后用前面提到的命令查它的入口Activity能不能被系统识别。如果查得到那就是Launcher的问题重启一次界面进程通常能刷新。# 重启系统界面进程部分固件上会短暂黑屏属正常 adb shell am force-stop 桌面应用的包名 adb shell am start -n 桌面应用的包名/主Activity全名如果查不到入口Activity那说明这个应用本身没有桌面图标比如它是个后台服务型的应用或者是个插件。这种情况只能通过命令行或者从其他应用里跳转启动。还有一种情况是应用被装进了非主用户空间主用户自然看不到。用pm list packages --user 0和pm list packages --user 10对比一下能看出端倪。6.3 声音、画面与网络的异常处理声音方面最常见的是播放无声。先查系统音量是不是被静音了用adb shell media volume --get看当前值必要时用--set调上去。如果音量正常还是没声就要看应用是不是用了一个系统不支持的音频输出通路。CCH的音频输出是和语音系统耦合的第三方应用抢占音频焦点时可能会被拦。日志里搜AudioTrack和AudioFocus能找到线索。画面方面的典型问题是显示不全。一部分原因是布局错位前面讲过另一部分原因是系统强制了显示缩放。可以在开发者选项里找显示相关的缩放设置关掉再看。还有一个容易被忽略的点部分固件默认开启了画面比例适配把16:9的内容压到设备自己的比例上导致边缘被裁。这个在播放器里切一下画面比例设置就能解决。网络方面出问题的往往不是应用而是设备的休眠策略。屏幕熄了之后系统会限制后台网络导致下载中断、在线播放卡顿。应对办法是在系统设置里把相关应用的省电限制去掉或者在测试时保持屏幕常亮。开发者选项里有个保持唤醒的开关测试期间打开它很方便。提示每次排查完把现象、日志关键词、最后的解决办法这三个要素记下来。我攒了大概四十多条记录后来遇到新问题的时候靠关键词检索就能命中大半效率提升非常明显。7. 后续还能怎么玩以及个人的几点体会7.1 把它做成一个专用的信息看板折腾到最后我发现最实用的形态反而不是什么都能装而是只装一两件事做得好。我现在的配置是把CCH放在玄关柜上屏幕上常驻一个极简的时钟加天气页面需要的时候用语音切到音乐或者广播。它不再是一个试图模仿平板的设备而是一个专一的小终端。这种定位下兼容性问题几乎消失了因为需要的功能就那么两三个跑通了就一直稳。如果你也想走这个路线我的建议是先用一两天时间把候选应用过一遍挑出那个启动快、界面干净、不需要登录、占用小的组合然后把它固定下来别再频繁更换。老设备的稳定性很大程度上取决于你不动它。7.2 让老设备承担一个具体分工家里闲置的带屏设备其实可以按房间分工厨房那台只做计时器和菜谱朗读卧室那台只做闹钟和白噪音书房那台挂个待办清单。分工越明确对应用的要求就越低兼容性风险也越小。这套思路的另一个好处是隔离风险。每台设备只装一两个应用出问题了影响面很小卸载重装几分钟就能恢复。相比之下把十几二十个应用塞进一台设备然后逐个排查冲突成本高得多。7.3 我踩过的那几个坑顺手记一下坑一图省事用了别人打包的所谓适配版装上去之后各种异常排查了半天才发现是包本身处理过。从此只用自己的来源。坑二没备份就直接覆盖安装结果新旧版本签名不同导致数据全丢之前的配置白做了。现在我的规矩是覆盖安装前先用应用自带的导出功能把配置存一份或者记下关键设置。坑三一次装太多存储满了之后系统开始异常连卸载都卡。正确做法是装一个测一个保持空闲空间充足。坑四以为Success就是成功没做二次校验结果某个包实际没写进去白白浪费了半小时找别的原因。现在装完必查一遍包列表。坑五改屏幕密度之后忘了记原值想改回来只能猜。现在每次改之前先wm size和wm density各跑一遍把输出存到电脑上的一个文本文件里非常省心。这几个坑没有一个是技术难题全是因为急。做这类设备测试最需要的心态其实是慢下来每一步都验证过再走下一步。