当前位置：首页 > news >正文

欧盟裁决谷歌开放 11 项安卓功能，Open Home Foundation 智能家居互操作性获重大胜利

news 2026/8/3 7:15:39

欧盟裁决谷歌开放 11 项安卓功能，Open Home Foundation 迎来智能家居互操作性重大胜利

Open Home Foundation 相关介绍：

Who we are
- Our story
- Structure
- Supporters
What we do
- Projects
Resources
- Privacy paper
- Documents
Blog
Store
Support us

此前，谷歌对安卓的关键功能进行了限制，欧盟委员会就此征求了 Open Home Foundation 的意见。如今，Alphabet 必须向所有开发者开放 11 项安卓功能。

2026 年 7 月 31 日，星期五 · 阅读时长 9 分钟Timothy Nibeaudeau

作为 Open Home Foundation 负责 Home Assistant 的安卓开发者，受欧盟委员会（EC）邀请，参与了关于安卓互操作性的咨询。此次征求反馈是欧盟委员会依据《数字市场法案》（DMA）开展工作的一部分。DMA 是一项欧盟法律，对“守门人平台”进行定义和监管，目的是让数字市场更加公平，更具竞争性。开发者对谷歌对安卓的限制有很多意见，特别是谷歌将唤醒词检测功能局限于自家的 Gemini 语音助手，开发者在 Home Assistant 2026.3 版本发布派对上就提出了这一担忧。谷歌限制安卓互操作性是为了给自己谋取竞争优势，开发者将这些想法告知了委员会。

结果是，欧盟委员会听取了开发者以及其他所有参与反馈的组织的意见。2026 年 7 月 16 日，欧盟委员会依据 DMA 做出决定，要求 Alphabet（谷歌母公司）开放 11 项安卓功能，包括始终开启的唤醒词检测、环境传感器访问和屏幕自动化等，且要以平等的条件向所有语音助手开放。

开发者作为欧盟公民，很高兴看到这样的监管措施让大型科技公司在数字市场上的竞争更加公平，这对用户来说是实实在在的进步。对 Open Home Foundation 也是一场重大胜利：致力于为智能家居领域的隐私、选择和可持续发展而战，此次的结果证明，只要为社区发声，就能实现变革。开发者在 7 月的时事通讯中简单提及了这一消息，现在想详细分析一下事情的来龙去脉、这项决定的具体内容、它对社区的重要性，以及它将为 Home Assistant 和整个行业带来哪些机遇。

背景介绍

三年来，社区一直试图在安卓版 Home Assistant 伴侣应用中实现始终开启的唤醒词检测功能，希望用户说出“Okay Nabu”后，自托管的 Assist 语音助手就能做出回应。然而，早期的尝试总是失败，每次设备重启后，麦克风就无法再识别唤醒词。于是深入研究安卓源代码，发现有解决方案，但谷歌却不让使用。

安卓系统有一套设计精良的机制，能让设备全天监听“Hey Google”，同时又不会过度消耗电量。其唤醒词检测分为两个阶段。第一阶段由一个小型模型在 DSP（数字信号处理器）上运行检测，DSP 是一种专用芯片，处理音频所需的电量远低于设备主处理器（CPU）。这个阶段在一个与网络隔离的进程中运行，在检测到可能的唤醒词之前，无法提取音频。然后，第二阶段通过 CPU 使用更强的模型来确认检测结果。

大多数现代设备都配备了 DSP，但基于安卓系统的设备只允许谷歌和设备制造商访问 DSP。由于第三方应用无法使用基于 DSP 的唤醒词检测机制，且开发文档也未公开，只能尽力构建一个替代方案。

从 microWakeWord 到重大成果

解决方案是在应用内的设备 CPU 上运行一个小型的 microWakeWord 模型。这个方法虽然可行，但也存在一些严重的缺点：

开启唤醒词检测后，电池耗电量会从大约 1% 飙升至 15%，因为 CPU 在这项任务上的效率远不如 DSP。
麦克风隐私指示灯（绿色小点）会一直亮着，因为需要完全访问麦克风才能自行运行检测。虽然认为这个指示灯的设计是合理的，但无法像谷歌那样提供更安全的保障：一个无法将音频发送到任何地方的隔离进程。用户只能相信会妥善处理麦克风访问权限，这并非因为技术上没有更安全的方案，而是谷歌出于反竞争目的，任意封锁了 DSP 路径，迫使采用安全性较低的方法，给用户带来了隐私风险。
用户必须将 Home Assistant 设置为默认语音助手，因为这是安卓系统让服务在设备重启后仍能保持运行的唯一方式。这样一来，用户就无法使用 Gemini 及其相关功能了（而用户本不应面临这种二选一的困境）。

开发者受邀向欧盟委员会分享这些限制（以及其他问题）时，毫无保留地表达了观点。看到欧盟做出的这项精准且技术细节准确的决定时，感到非常兴奋：该决定准确描述了两阶段唤醒词架构、DSP、隔离进程以及角色耦合等内容。报告中提及的细节，是通过阅读安卓源代码才了解到的。接下来，看看这项裁决的具体内容……

给谷歌的警钟

该决定要求谷歌向第三方提供与自家语音助手“同等有效”的互操作性，且免费开放 11 项安卓功能。就唤醒词检测而言，谷歌必须提供以下支持：

允许在安卓系统中创建自定义唤醒词模型，第一阶段的检测由 DSP（如果设备支持）而非应用程序运行。
在 DSP 在第一阶段检测中可能识别出唤醒词后，允许运行第二阶段的验证。
提供测试工具和完整的文档，且无需与谷歌签订商业协议。

有两条内容值得特别关注。其一：谷歌“不得将功能访问权限与应用程序的默认角色挂钩，包括默认语音助手角色”，这正是与欧盟委员会讨论过的解耦问题。其二：唤醒词检测“允许多个服务（包括第三方服务和 Alphabet 的服务）同时运行”，这意味着用户可以在不更改任何默认设置、不放弃使用 Gemini 其他功能的情况下，说出“Okay Nabu”来控制家居。

除了唤醒词检测，该决定还涵盖了通过长按主页手势调用语音助手、在与谷歌相同的条件下访问环境数据（如麦克风和摄像头）、与应用程序（包括 Gmail、日历和地图）进行结构化集成、系统级控制、访问设备端 AI 模型以及公平的后台执行规则等内容。开放这些功能并非一帆风顺——谷歌就提出了安全方面的担忧，下面详细讨论。但综合考虑，认为这些举措给用户和行业带来的好处远远超过了风险。

时间紧迫

谷歌必须在 2027 年 8 月 1 日前，在安卓 18（下一个重大版本）中实现这些更改。并发热词检测功能（即允许多个服务通过语音触发）必须在安卓 19 中实现，最晚不超过 2028 年 8 月 1 日。

值得注意的是，这项决定仍依赖谷歌来设计和实施这些更改，这可能存在恶意合规的风险：一种技术上可行，但实际上无法使用的解决方案（守门人通过这种方式规避监管也不是第一次了）。不过，细则中也有令人期待的地方：谷歌必须提供在易用性、速度和能耗方面“同等有效”的解决方案，发布完整的文档和测试工具，并每月向欧盟委员会报告进展情况。这对开发者来说是一个真正的胜利，也让谷歌想要敷衍了事变得更加困难。基于此，下面看看这对 Home Assistant 意味着什么。

助力变革落地

一直努力为安卓版 Home Assistant 用户打造最佳体验，但团队规模较小，因此社区对安卓应用的贡献尤为重要。如果愿意提供帮助（请遵循最近发布的 AI 政策），非常欢迎加入。以下想法仅供参考，尚未列入路线图，但建议可能会在未来将其变为现实：

节能唤醒词检测

如前所述，将第一阶段的检测从 CPU 转移到 DSP 应该能显著提高电池效率。计划支持两种方法：对于搭载安卓 18 的新手机，将使用手机的低功耗芯片来监听唤醒词；对于旧手机或没有该芯片的手机，检测将继续沿用现有方式。无论采用哪种方法，伴侣应用都会显示手机使用的检测方式。

一部手机，两个语音助手

目前，选择第三方唤醒词意味着要放弃 Gemini 以及通过默认语音助手进行的通话和消息功能。解除默认角色绑定和支持并发唤醒词访问将改变这一现状：可以像往常一样与 Gemini 交流，也可以在需要通过 Home Assistant 控制家居时说出“Okay Nabu”。

想象一下，可以在应用内为不同的语音助手设置不同的唤醒词，比如为管理仪表盘设置“Hey Jarvis”，为家庭控制设置“Okay Nabu”。虽然这要等到 2028 年安卓 19 发布后才有可能实现（而且需要付出大量努力），但这是一个值得期待的目标。

增强内置隐私保护

这是开发者最期待的部分。裁决要求唤醒词确认过程必须在通过 DSP 实现的安全隔离进程（即沙盒）中运行。这意味着控制该功能的系统部分被隔离，在确认唤醒词之前无法将音频发送到任何地方。在涉及与语音助手的敏感交互时，不想仅仅依赖信任，希望能够掌控局面，清楚了解所启用功能的具体含义。沙盒机制从设计上满足了这一需求：由操作系统本身强制实现隐私保护，谷歌一直享有的这种默认安全保护，现在终于也能惠及所有用户了。

更强大的语音助手

平等对待不仅体现在传感器访问方面。该决定还要求谷歌向符合条件的语音助手（而非仅 Gemini）开放与自家应用（如 Gmail、日历、地图等）的结构化集成。理论上，这意味着语音助手可以代起草邮件、管理日历事件、发送短信和拨打电话：这些正是用户在放弃 Gemini 时所缺失的功能，而它们确实能提升用户体验，尤其是对有特殊需求的用户。

同样的访问权限还可以扩大应用向 Home Assistant 报告的传感器和控制范围：将声音检测（烟雾报警器、玻璃破碎声、门铃）作为自动化触发条件，以及让语音助手能够实际操作（而非仅观察）的控制功能，如勿扰模式或蓝牙开关。

关于安全争议

谷歌对这项裁决提出了反对意见，称其存在安全风险。它警告说，该决定赋予第三方“敏感且强大的设备权限”，会在“用户不知情或未同意的情况下”暴露用户数据。这种说法夸大了风险，是一种常见的策略：以安全问题为由，阻碍互操作性的推进。作为第三方之一，要指出，该决定已经包含了相关的安全保障措施：谷歌仍然可以要求用户同意、显示隐私指示灯，并允许用户撤销每个服务的访问权限。对于健康数据访问等最敏感的功能，谷歌还通过应用商店制定了相关政策，在应用获得访问权限之前检查其安全性、隐私性和数据最小化情况。

需要明确的是，这些功能在手机上早已存在，谷歌自己的服务也在使用，却从未征求过用户的同意。欧盟要求更广泛地共享这些访问权限，并没有带来新的风险——改变的只是由谁来决定哪些人可以使用这些功能。无论剩余的风险如何（就像使用任何智能设备都会存在风险一样），都应该认真对待，但不能让谷歌以此为借口搞双重标准。

认为，未经验证的信任不能作为安全保障模式，仅让谷歌享有这些安全保护措施也并非真正的保护。即使是大型 AI 供应商也会遭遇安全事件，比如 Hugging Face/OpenAI。真正能提供保护的是，让用户在安全过程中有选择权和知情权，同时具备安全的技术架构：沙盒、隔离、可撤销的权限——并且平等地执行这些措施，这正是该决定所要求的。

值得关注的是谷歌未来的动向：从 2027 年起，其开发者验证计划将要求每个安卓开发者在应用安装前都要经过中央验证——这一举措遭到了 Keep Android Open 运动的反对，对此也持怀疑态度。这提醒我们，这场斗争还没有结束，工作也不会停止。