简介面向全志H313与H616平台的安卓系统开发笔记覆盖从Linux环境搭建、git/repo使用、C/C与Java基础到Android应用四大组件、系统架构、启动流程、H313/H616编译流程、系统调试与平台定制的完整知识链适合从事全志方案系统开发、驱动移植或应用定制的工程师参考。资源以PDF单文件呈现整包大小1.26MB仅1个文档轻量便携目录和章节结构清晰便于在电脑或手机上直接检索阅读。文档系统梳理Android应用基础Activity、Service、Broadcast、ContentProvider与Manifest配置和系统基础源码目录结构、编译流程、调试方法并针对全志平台展开定制说明包括升级地址、设备型号、默认语言时区、开机静画/动画、预装应用、遥控器配置等实用主题。同时集中整理setprop/getprop、getevent/sendevent、dumpsys、logcat、adb等常用命令深入init.rc属性系统与输入事件拦截帮助理解系统启动与事件分发机制。目前已有934人学习适合希望快速上手全志Android系统开发并沉淀实操经验的开发者。 全志H313/H616这两颗芯片是我最近大半年一直在折腾的平台。手头这本《全志平台H313 H616安卓系统开发笔记》从拿到SDK的第一天开始记一直写到量产固件发布。记录的内容不算精致但都是实打实的踩坑和排雷过程放到这里分享出来希望对正在做OTT盒子、电视盒子或者广告机方案的兄弟有点参考价值。这颗芯片在市面上见得多的地方是各种电视盒子、商用显示终端和低成本数播方案。如果你做的是这几类产品又恰好要跑安卓系统那这篇文章里的内容大概率能帮你少走不少弯路。整个笔记覆盖了平台选型的考量、SDK环境搭建、内核与系统裁剪、常见问题的定位思路基本是一个完整项目的复盘偏实战不偏理论。1. 项目全景与平台选型考量1.1 H313与H616同宗不同命的双胞胎全志H616和H313在官方定义上属于同一代方案都采用四核Cortex-A53架构也都集成了Mail-G31 GPU。但两者针对的市场定位有明显差异H616要稍高半档H313更像是为极致成本场景做的收缩版。从实际开发角度看两颗芯片最大的区别主要体现在三个地方我列了一个简单的对照表方便查看对比维度H616H313CPU四核 Cortex-A53四核 Cortex-A53GPUMali-G31 MP2Mali-G31 MP2频率略低视频解码4K60fps H.265/VP94K60fps H.265/VP9内存支持支持到4GB DDR3/DDR4/LPDDR4常见2GB以内偏DDR3/LPDDR3定位OTT中高端、混合型终端入门级盒子、低成本显示终端内核方面两颗芯片的BSP代码很多是共用的设备树和内核配置差异不算大。这带来的直接好处是如果团队先做了H616方案再切H313做低配版本软件工作量主要集中在内存配置、DDR频率参数和个别外设的重新适配上整体成本可控。1.2 我为什么选这个平台做安卓系统选择全志H313/H616做安卓系统开发最核心的原因是市场定位非常清晰。拿盒子和数播这类产品来说用户关心的不是跑分而是开机速度、视频解码兼容性、接口稳定性和整机成本。全志这套方案在性价比上有明显优势BSP里已经带了比较完整的安卓系统适配层包括显示、音频、WiFi、蓝牙这些常用模块的驱动缩短了从立项到量产的时间。另一个值得一提的点是全志在Linux和安卓两条线都有长期维护社区资料丰富遇到问题能搜到大量现成的讨论。相比某些芯片厂商给的半成品SDK全志的SDK整体完成度要高不少只是需要开发者在细节上多花些心思去调整。2. 开发环境与SDK架构拆解2.1 搭建编译环境的那些事我实际用来编译这套系统的机器是Intel i7-10700的CPU配了32GB内存和1TB的SSD系统用的Ubuntu 20.04。这个配置编译H616的完整安卓固件首次全编大概需要50到60分钟如果机器配置低一些比如只有16GB内存可能会出现内存不足导致的编译中断建议至少16GB起步。依赖库的安装这一步很容易被忽略但跳过之后编译会在某个环节突然报错而且报错信息五花八门。按官方文档装完依赖后我还额外装了几个常用工具有些是后面调试时才发现的必需项sudo apt-get update sudo apt-get install -y git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g-multilib libc6-dev-i386 libncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig python2 python3python2这个包在Ubuntu 20.04上需要从老源单独找不装的话部分全志老脚本会跑不起来。我从实际经验总结先确认python2可用再开始第一次编译否则会在定义全局变量的脚本阶段卡很久。2.2 SDK目录结构怎么看全志向客户释放的安卓SDK解压后根目录下通常有两个最关键的部分一个是lichee这是内核、uboot和rootfs构建的主战场另一个是android里面是AOSP的工程。lichee负责底层android负责上层两者通过特定的打包脚本最终生成可烧录的固件。lichee内部的linux-4.9或linux-5.4目录是内核源码device/config/chips对应不同芯片型号的配置包括dts设备树源文件、sys_config.fex这类板级配置文件。android目录下的device/softwinner目录则存放不同方案板级配置、产品mk文件、预装应用清单等相关内容。理解这个结构的意义在于很多问题的定位需要先判断是出在内核层、HAL层还是纯安卓应用层而这三者分别对应的代码位置是截然不同的。如果不清楚SDK组织方式经常会出现改错地方、编译无效的情况。2.3 首次编译的完整流程全志SDK的编译流程做得还算顺手不需要过于复杂的组合命令。在lichee目录下先编译底层然后进入android目录编译上层最后用打包脚本生成固件。我整理了一份简易步骤# 第一步编译licheeuboot、内核、rootfs cd lichee ./build.sh config # 选择芯片方案、板级配置、系统类型比如H616 Android ./build.sh # 第二步回到SDK根目录编译安卓系统 cd ../android source build/envsetup.sh lunch # 选择对应产品配置例如 sugar_h616_android11 make -j16 # 第三步打包生成最终可烧录固件 ./pack首次全编最值得提醒的是磁盘空间。完整编译后lichee加android两个目录加起来很容易超过200GB。如果分区空间不够会在编译到一半时提示磁盘已满这时候要么清理旧输出要么重新规划目录挂载非常影响节奏。3. 核心开发实战要点3.1 内核与设备树的调整策略设备树是这套平台开发中绕不开的关键环节。H616/H313的设备树文件路径一般在lichee/device/config/chips/h616/configs/某板级目录下主要用的是board.dts。修改设备树直接决定了内核启动时如何初始化内存、外设和引脚功能。我在这套平台上做的第一项工作是根据实际硬件调整DDR参数和GPIO复用。比如如果硬件上把某个串口接成了一个外设的调试口那就要在设备树里把对应引脚从普通GPIO复用为UART功能。实际节点修改大致如下uart3 { pinctrl-names default; pinctrl-0 uart3_pins; status okay; };注意这类修改往往会牵扯到板级配置文件里引脚复用表的同步修改。如果只改设备树不更新fex配置有时会出现内核日志显示设备树已识别但引脚不工作的情况这算是一个比较隐蔽的坑。另一个容易踩的坑是CPU和GPU频率策略。系统默认的调频策略偏向保守如果产品有较高的UI流畅度要求需要调整CPU governor和频率表。我通常会在设备树中把soc opp表里的最高频率档位打开同时把安卓层powerhal策略对齐避免系统频繁降频导致掉帧。3.2 显示与多媒体适配盒子和数播这类产品显示输出和多媒体解码能力是命根子。H616/H313在视频解码方面的硬件能力不错主流的H.265 4K视频都能硬解但要在安卓层面实现“拿来就能播”还需要花不少功夫。尤其要注意的是HDMI输出的初始化顺序、分辨率支持和HDCP相关配置。我在适配过程中把HDMI输出的分辨率列表做了裁剪只保留实际出货需要的几档分辨率比如1080p60和4K60。这样做的目的有两个一是加快系统启动时显示协商的速度二是避免某些劣质电视在EDID上报了奇怪分辨率后导致黑屏。裁剪位置在设备树hdmi节点中通过关闭不必要的video mode来实现。音频适配方面数播产品对I2S输出到外部DAC的通道要求比较高。全志平台默认的audio HAL可以配置多个声卡设备需要根据实际硬件在audio_policy_configuration.xml里指定正确的输出设备。这个文件在android源码的device/softwinner/某板级目录下修改后需要通过make systemimage重新生成系统镜像。3.3 系统裁剪与预装应用管理Android系统裁剪直接决定了整机的流畅度和内存占用。全志SDK默认带了不少用不到的东西比如一些演示应用、多余的输入法、网络定位服务等。我在这套方案里做了几项针对性瘦身移除不必要的GMS相关服务和包减少后台进程数量精简系统内置壁纸和铃声资源关闭默认开启的自动更新和遥测功能将部分系统应用合并到vendor分区方便后续OTA时减少system分区改动。预装APK的管理相对简单。全志方案支持在板级mk文件里通过PRODUCT_PACKAGES方式添加预装应用也可以在system/vendor的app目录下直接放APK。前者在编译时控制是否打包后者更灵活但不利于版本管理。我这边采用的是两种结合的方式核心预装应用走mk文件定制应用放vendor目录升级时只更新vendor分区。开机logo的定制也要提一下。很多客户对开机画面有品牌要求改boot logo需要先准备一张BMP格式图片然后通过SDK提供的工具生成对应分辨率下的开机logo资源替换内核或boot分区中的默认图片。这个操作本身不难但要注意图片格式和色彩深度必须符合要求否则可能出现花屏或logo不显示。4. 调试工具与问题排查4.1 串口调试实战安卓系统的开发调试串口是最可靠的生命线特别是在系统起不来、屏幕无显示的情况下基本只能靠串口日志定位问题。全志平台的串口默认是UART0一般就在主板上预留了4针或5针的调试接口。连接时用USB转TTL工具波特率设置为115200接好GND、TX、RX三根线就能看到输出。看串口日志有几个关键阶段值得注意第一阶段是uboot打印可以看到DDR初始化、启动介质检测等关键信息第二阶段是内核解析设备树和初始化驱动的过程很多硬件适配问题会在这里暴露第三阶段是安卓用户空间的启动日志包括zygote、system_server的启动过程。业务问题一般看第三阶段系统起不来则重点看前两个阶段。我遇到过好几次内核启动panic日志里会明确指出panic的调用栈和出错代码行。比如一次DDR频率配置过高导致的不稳定问题在串口日志里表现为启动过程中随机死机或报出internal error。排查这类问题优先检查设备树里DDR频率表是否超出了芯片在该内存类型下的稳定范围。4.2 常见问题速查表把这大半年遇到的高频问题整理了一下做了一个速查表每一项都是我实际定位和处理过的故障现象可能原因排查与解决思路开机卡在logo画面内核驱动初始化失败或系统服务崩溃串口看日志定位最后一条正常输出重点查display和storage屏幕无显示但系统在运行HDMI握手失败或分辨率不匹配检查HDMI线材、显示模式列表串口确认hdmi驱动是否probe成功音频无声或爆音I2S配置错误或声卡通道不对查看音频HAL日志用tinyalsa工具测试playback通道WiFi频繁断开天线匹配差或电源纹波大检查WiFi模块供电优化天线布局尝试调整电源管理策略系统内存长期偏高预装应用过多或存在内存泄漏用adb shell top查看进程占用裁剪无用进程和服务休眠后无法唤醒内核suspend/resume逻辑异常串口查看休眠日志检查外设驱动在resume阶段的恢复逻辑4.3 性能优化与稳定性调优产品稳定性是量产前必须重点投入的环节。这套平台在长时间运行后偶发的卡顿和黑屏是最让人头疼的。针对卡顿问题我做了CPU调度策略优化把交互相关的进程绑定到大核同时调整了LMKLow Memory Killer参数尽量避免系统在内存紧张时杀掉关键进程导致的桌面重启。黑屏问题排查到最后发现有些是HDMI线和电视兼容性不好引起的。解决方案是在软件层增加一个显示服务的心跳检测一旦发现显示无输出超过设定时间自动重新初始化HDMI输出。这个机制实测下来能解决相当一部分的场景兼容问题。发热问题也不能忽视。H616在高负载解码场景下发热明显如果散热设计做得不好长时间高温运行会触发芯片降频进而影响播放流畅度。我在做方案时除了硬件上增加散热片外在软件上还限制了后台播放时的最高CPU频率在保证播放流畅的前提下降低整机功耗和温升。写在最后的一点经验这套系统从拿到SDK到稳定量产我前后迭代了整整三个版本踩过最多的坑集中在两处一处是内存参数配置另一处是显示输出兼容性。DDR频率不是越快越好稳定性才是第一位方案出来之后先花时间跑压力测试比急着调高频率有意义得多。显示输出的兼容性没办法靠单台设备调试解决有条件就多找几台不同品牌的显示设备做交叉测试有些问题只有在特定电视上才复现。最后分享一个实用技巧每次编译完固件后第一时间把编译时间戳、commit号、设备树版本写进系统版本号里。后续不管是客户反馈问题还是自己回溯Bug都能快速定位到对应固件版本避免“这个问题在新版本还是旧版本”这种低效的来回确认。这个习惯帮我省了不少时间也推荐给你。本文还有配套的精品资源点击获取