切换到嵌入式 Android 时要知道什么

想象一下：您所在的公司刚刚为一系列触摸屏设备投入了大量资金用于定制 Linux 操作系统，因为该设备不存在硬件驱动程序支持。除了产品开发成本外，该公司还因必须自行管理操作系统并提供定期安全更新而产生了未来成本。

不幸的是，该项目最终以财务失败告终。原因如下：

为自定义 Linux 操作系统提供更新是一项艰巨且成本高昂的任务。它需要深入的 Linux 知识才能将外部补丁与自定义更改合并，而不会破坏整个系统。然后，在构建操作系统之后，需要一个复杂的基础架构来以安全可靠的方式分发这些更新。最后，设备端需要一个软件组件来下载和安装这些更新，这样设备就不会变砖。所有这些都会在原始投资之上引入大量的经常性成本。

制造商可能很想完全跳过无线 (OTA) 更新功能，因为它实施起来太复杂了。但一项新的德国/欧盟法律现在要求对消费设备进行定期操作系统更新，否则公司可能会面临违反保修的风险。Android 设备因不及时接收更新而臭名昭著，有时甚至根本不接收更新。

不幸的是，面对这些新法律，跳过 OTA 将不再是一种选择。

然后是质量问题：在一个由 Android 和 iOS 主导的世界中，用户期望设备具有一定程度的响应能力、对图形的流畅感以及用于导航、打开应用程序和更改设置的标准化方法。正如全世界在开发第一台 Mac 时从史蒂夫·乔布斯那里了解到的那样，如果不大幅提高处理能力，就很难实现软件的美感。而且，在嵌入式世界中，处理能力是有限的。

令人惊叹的软件还需要在可用性案例研究、开发工具、UI 标准、常见 UI 元素等方面进行大量投资。

对于三星这样仅在 2020 年就售出 2.66 亿台智能手机设备，并且拥有庞大开发团队的公司来说，上述成本是可以承受的。但对于一家只有 100,000 台设备的小公司来说，这种类型的财务负担可能会使整个产品无法生存。

但是，有一个选项可以使小型车队的项目更可行：嵌入式 Android。

是什么让嵌入式 Android 变得更好（或更糟）？

Android 基于经过修改的 Linux 内核，其中添加了许多功能，例如 WakeLocks 和 Early Suspend 等电源管理功能。

添加的一项改变游戏规则的功能称为“Binder IPC”或“Binder 进程间通信”，有时被称为 Android 的核心。与 Linux 发行版中使用的资源密集型方法（管道、套接字、内存队列、共享内存等）相比，Binder IPC 是一种轻量级的进程间通信方法。

从开发人员的角度来看，Binder IPC 允许所有应用程序和系统组件拥有一个简单的通信渠道。有时，开发人员甚至不必知道哪个应用程序将执行特定操作（例如打开相机或发送电子邮件）——Android 将负责将用户请求从一个应用程序传递到另一个能够满足它的应用程序.

Android 还具有应用程序沙盒和SELinux以提高安全性，更不用说一组丰富的包含组件，可以更轻松地处理图形、资源、通知、网络、位置、电话等。

对于具有触摸屏和 GUI 功能的设备，Android 显然是 Linux 的赢家。

但是，使用 Android 作为嵌入式操作系统也有其自身的挑战。

在专业嵌入式应用程序中使用标准 Android 的挑战

想要将 Android 移植到嵌入式系统时会遇到一些挑战。

Android 的 C 库（仿生）并非 100% 符合 POSIX。这有时会使引入外部代码变得困难。而且 Android 的文件布局也不符合 Linux 的文件系统层次标准。

Android 不能在开箱即用的自定义嵌入式系统上运行。大型手机制造商可以负担得起大型软件开发团队，他们从 Android 开源项目 (AOSP) 分支出来并根据自己的需要对其进行定制。

AOSP 很大。它有800多个项目。下载代码需要250GB 的硬件空间。构建一个操作系统版本需要另外 150GB。构建过程可以运行数小时。

即使对于经验丰富的 Android 开发人员来说，这个过程也是缓慢而复杂的。对于 Android 技能为零的团队来说，这几乎是不可能的。

因此，对于希望从 Linux 转向嵌入式 Android 的公司来说，这是一条捷径。很多这些公司可能坐拥数十年的内部开发的定制嵌入式 Linux 库。

但对此有新的认识是，如果公司计划将 OTA 更新功能出售给欧盟消费者，则必须将其包含在未来的物联网设备中。这已经成为整个欧盟新车的强制性要求。构建有效的 OTA 和 FOTA（Firmware Over The Air）基础设施需要巨大的初始工作负载，以促进自动构建、代码签名、上传和未来的更新管理。对于能够通过 OTA 更新的设备，需要构建设备配置系统以及安全的固件安装引擎。当发现漏洞时，必须尽快提供安全补丁。

公司还需要为硬件故障、更新回滚和软件错误做好准备。

遗憾的是，谷歌官方将 Android 移植到嵌入式的 Android Things 已被关闭。这进一步加剧了嵌入式 Android 缺乏硬件支持的情况。

在某些情况下，Linux 硬件支持可以说被认为更好。但是Android是建立在Linux之上的，也就是说，如果Linux支持的东西，原则上Android也可以支持。但是，由于应用程序接口的抽象级别很高，可能很难将硬件支持应用到实际应用程序中。

此外，Android 最初是为具有固定设置（小屏幕、预定义的连接模块、硬件按钮、WiFi 等）的设备设计的。将此配置更改为不同的配置是可能的，但如果产品的硬件发生变化，则可能需要恢复以前的更改并从头开始开发。

从本质上讲，如果嵌入式 Android 是由经验丰富的 Android 开发人员团队构建的，那么它比 Linux 具有许多优势。当然，从理论上讲，开始使用 Android 就像选择一个好的原型设计套件来学习一样简单——比如 RockPi、Raspberry Pi 或 i.MX8 SBC 之一。但是，需要一支经验丰富的 Android 开发人员团队来大规模构建任何设备规模的东西，其中还包括更新新推出的操作系统所需的 OTA 基础设施。

为任何机队规模构建可扩展的嵌入式 Android 操作系统

嵌入式 Android 挑战的更有效解决方案通过提供可根据底层硬件要求轻松修改的可定制 Android 发行版来应对这些挑战。例如，emteria.OS是完整形式的 Android。开发人员会收到 AOSP 的扩展版本，但带有额外的接口、组件和应用程序，可提供许多开箱即用的企业级元素，例如：

OTA更新申请

发布版本控制

操作系统和应用程序的签名，包括自定义密钥

私人应用商店

远程访问

信息亭模式

移动设备管理 (MDM)

根访问权限

下图中可以看到其中的一些功能。

emteria.OS 堆栈的简化示意图。（来源：emteria GmbH）

虽然是emteria。操作系统根据任何给定的BSP或OEM的要求进行修改，处理MDM、OTA和FOTA的底层基础设施不需要修改。因此，该操作系统与数百万现有应用程序和库保持兼容，而更新在emteria的服务器上处理，并由fleet manager按自己的时间表推送到设备上，通过web浏览器控制。

尽管安卓作为嵌入式系统越来越受欢迎，但由于缺乏面向小型车队的专用操作系统供应商，该行业仍然支离破碎，并为有缺陷的软件打开了大门，这些软件可能会在新的欧盟制度下引发保修条款。

从更大的角度来看，缺乏适合中型嵌入式设备的高度可定制、开发人员友好和用户友好的操作系统，已成为物联网领域不断增长的需求中创新的主要障碍。嵌入式安卓的更新版本，如emteria。操作系统是向嵌入式安卓领域标准化迈进的一步，将安卓的功能以很低的成本提供给原始设备制造商。通过减少现有的创新障碍，更有效的嵌入式安卓版本使解决方案构建者能够专注于增加客户价值，而不是解决操作系统挑战。

审核编辑 黄昊宇