欧盟裁决谷歌开放 11 项安卓功能Open Home Foundation 迎来智能家居互操作性重大胜利Open Home Foundation 相关介绍Who we areOur storyStructureSupportersWhat we doProjectsResourcesPrivacy paperDocumentsBlogStoreSupport 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 运动的反对对此也持怀疑态度。这提醒我们这场斗争还没有结束工作也不会停止。全程跟进谷歌必须在两个月内向欧盟委员会报告其实施计划资格计划条款将于 2027 年 2 月进行公开咨询。将全程参与测试测试版、评估实施效果是否符合预期并及时向用户通报最新情况。与此同时将继续竭尽全力倡导智能家居技术具备隐私性、本地化并让用户能够按照自己的意愿进行控制。DocumentsUser research agreementSupport usPrivacy PolicyImpressumJobsContact us[email protected]Follow usSubscribe to the newsletterSubscribeCopyright © Open Home FoundationOpen Home Foundation| CHE-416.988.952
欧盟裁决谷歌开放 11 项安卓功能Open Home Foundation 迎来智能家居互操作性重大胜利Open Home Foundation 相关介绍Who we areOur storyStructureSupportersWhat we doProjectsResourcesPrivacy paperDocumentsBlogStoreSupport 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 运动的反对对此也持怀疑态度。这提醒我们这场斗争还没有结束工作也不会停止。全程跟进谷歌必须在两个月内向欧盟委员会报告其实施计划资格计划条款将于 2027 年 2 月进行公开咨询。将全程参与测试测试版、评估实施效果是否符合预期并及时向用户通报最新情况。与此同时将继续竭尽全力倡导智能家居技术具备隐私性、本地化并让用户能够按照自己的意愿进行控制。DocumentsUser research agreementSupport usPrivacy PolicyImpressumJobsContact us[email protected]Follow usSubscribe to the newsletterSubscribeCopyright © Open Home FoundationOpen Home Foundation| CHE-416.988.952
