Android 17 ACCESS_LOCAL_NETWORK 权限：APP加固后局域网功能如何验收？

**直接答案：**先确认应用的 targetSdkVersion 是否为 37 或更高，再判断产品需要系统设备选择器还是广泛局域网访问；前者可在适用场景避免申请宽泛权限，后者需要声明并在运行时请求 ACCESS_LOCAL_NETWORK。对加固候选，应分别核对最终 Manifest、权限授权状态和真实局域网业务路径。本文没有执行御盾 APK 或设备测试，产品兼容结果为 NOT_TESTED。

摘要

Android 17 将局域网访问从较宽松的默认状态转为面向 target API 37 及以上应用的强制权限管理。应用可以根据功能选择由系统代办的设备选择流程，或在确实需要广泛、持续访问时申请 ACCESS_LOCAL_NETWORK。这两种路径的权限范围不同，不能只靠一份 Manifest 或一张权限差异表判断业务是否可用。加固前后检查应固定同一业务版本、目标 SDK、设备系统构建和安装状态，依次比较原包、受保护候选与最终发布包，并在授权、拒绝和撤销条件下复核实际功能。

本文关注的是局域网访问权限与发布兼容，不是通用 Android 17 行为变化列表，也不是 Play 商店政策审批指南。现有APK权限差异检测指南说明怎样比较两份 APK 的声明权限；本文补充 Android 17 局域网权限语义、最小范围替代路径及原包/加固包的行为验收。权限列表相同不表示运行时网络行为相同，权限不同也不能仅凭出现阶段判断责任。

读者对象

本文面向维护投屏、局域网设备发现、智能家居、IoT 管理、局域网浏览或其他设备连接功能的 Android 研发、测试、安全和发布团队，也适用于评估 Android 17/API 37 升级影响的应用加固负责人。若应用只访问互联网服务、不发现或连接局域网设备，不能因为 API 37 出现了新权限就推断该应用必然需要申请它。若应用仍以 API 36 或更低为目标，应按当前 Android 官方文档核对目标 SDK 适用条件，不要提前把 API 37 才需要的权限无条件加入旧版本清单。

本文不提供御盾产品已经通过局域网兼容测试的声明，也不假设加固会改变权限或网络访问。只有对同一业务提交的 Original、Protected 和最终发布物完成可复核对照，才能报告对应范围内的结果。没有真实产物、系统 Build、权限状态与业务路径时，结论保持 NOT_TESTED。

核心结论

1. 适用条件由 target SDK 决定。 Android 官方说明，Android 17 的局域网访问强制要求适用于 target API 37 或更高的应用；对 target API 36 或更低的应用，官方当前指引要求不要提前添加或运行时请求 ACCESS_LOCAL_NETWORK。
2. 权限保护的是局域网通信，不是所有网络。 官方 API 文档将局域网描述为使用具备广播能力网络接口的 IP 网络，例如 Wi-Fi 或以太网，并排除蜂窝 WWAN 与 VPN 连接。局域网访问受限不能直接解释为普通互联网请求也被阻断。
3. 存在较窄的系统中介方案。 支持的投屏和 mDNS 设备发现流程可以使用系统设备选择器，让用户选择具体设备，避免应用请求广泛局域网权限；这取决于业务用例和平台 API，不是所有 socket 场景的通用替代品。
4. 需要广泛访问的业务仍需权限路径。 某些家庭自动化或 IoT 管理场景需要应用持续发现并连接多个设备，应声明权限、在访问前检查授权，并处理用户拒绝和设置中撤销的情况。
5. 权限组和历史授权会影响提示体验。 ACCESS_LOCAL_NETWORK 属于 NEARBY_DEVICES 权限组；如果用户已授予组内其他权限，系统可能不会再次弹出提示。不能用“没看到新弹窗”推断没有权限检查或没有新行为。
6. 静态差异和运行时验证必须分开。 apkanalyzer 可以帮助检查 APK 清单声明，但不能证明权限已授权、系统选择器正常、设备发现成功或受保护候选的网络栈行为与原包一致。
7. 产品级结论仍为未测试。 本文引用官方规则并提出验收方法，没有执行御盾候选、客户应用或 Android 17 真机测试，不能表述为御盾已兼容或不兼容 API 37。

事实依据与脱敏证据

Android 官方事实与检查动作对应表

官方资料：Android 17 目标行为变化、局域网权限指南、ACCESS_LOCAL_NETWORK API 参考。官方局域网指南标注的最近更新时间为 2026-10-02 UTC；实施前应重新核对其适用版本和 API 说明。

本文中的“证据”是可公开查阅的Android平台规则及其与发布检查项的映射，不是御盾候选测试记录。权限、网络和加固的产品结论必须另有对应产物、系统环境与实际运行记录。

技术拆解：局域网权限到底保护什么

局域网功能通常包括发现设备、选择目标、建立连接、交换数据和断线重连。不同应用做的事情并不相同：投屏应用可能只需让用户选择一个接收设备；设备管理应用可能需要同时扫描并管理多个节点；浏览器或企业客户端可能要连接用户输入的 LAN 地址。权限策略应按最小必要范围选择，不能因为某个功能与 Wi-Fi 有关，就一概认定必须申请广泛权限。

Android 官方将 ACCESS_LOCAL_NETWORK 定义为 API 37 新增的危险权限，用于允许广告或连接局域网设备。该权限不是一般互联网访问权限，也不应与 INTERNET 或 ACCESS_NETWORK_STATE 混为一谈。官方指南指出，局域网访问范围与蜂窝网络、VPN连接有区别；因此，排查时要确认请求发往哪种网络和目标设备，而不是只根据应用当前显示“已联网”就下结论。

系统中介选择器的核心区别是：系统在用户参与下帮助发现或选择特定设备，应用不必先获得对整个 LAN 的广泛访问。对于支持的 Cast 工作流，Android 指向输出切换器；对于 mDNS 服务发现，官方说明 NsdManager 提供系统运行的服务选择流程。具体连接能力和所需数据应以所用 API、系统版本和设备选择结果为准。若产品需要应用自行发现多个设备、周期性扫描或管理多个节点，选择器未必满足其需求，这时应评估运行时权限方案。

权限组会影响用户看到的授权过程。API 37 应用的局域网请求属于 NEARBY_DEVICES 组，如果用户之前已经授予 Bluetooth 等组内权限，可能不会再次看到独立提示。这不等于应用可以跳过自身的授权状态检查，更不能依赖“第一次安装肯定会出现弹窗”的假设。测试账户在每次运行前应记录授权状态；对拒绝、撤销、重装、系统设置变更和已有邻近设备授权等条件分别设计用例。

局域网权限与 ECH 是两个不同检查面

Android 17 还引入 Encrypted Client Hello（ECH）平台支持。官方行为说明中，面向 API 37 及以上的 TLS 连接只有在应用使用的网络库已集成 ECH、且远端服务器支持协议时，ECH 才能实际协商；未协商时还可能使用 ECH GREASE。这个行为针对 TLS 握手隐私，不能替代 ACCESS_LOCAL_NETWORK，也不能解释局域网设备发现失败。若同时升级网络库与目标 SDK，应分别记录局域网访问授权、TLS 库版本、服务端能力和最终连接结果，避免将不同原因合并成“Android 17网络坏了”。

测试目标与非目标

本次主目标是说明如何将Android 17局域网权限规则转化为Original/Protected候选的发布前检查。本文没有执行APK、AAB、设备或局域网功能测试，所有产品级结果为NOT_TESTED。

非目标包括：宣称御盾已经通过Android 17测试、代替Google Play审核、断言所有应用都需要新权限、把权限清单一致等同于运行时兼容，或把单次Original/Protected差异直接定责。

工程落地：从权限清单到业务功能的发布检查

第一步：确认 target SDK 与网络功能边界

为被测候选记录 targetSdkVersion、Android 系统版本和系统 Build。随后把网络路径分为局域网发现/连接、普通互联网、蜂窝数据、VPN路径和系统中介设备选择。若目标 SDK 仍低于 API 37，按照当前官方说明不要无条件添加或请求新权限；若升级至 API 37，则根据具体功能评估选择器或运行时权限。该判断以官方当前文档为准，不是商店政策或御盾产品规则。

第二步：逐层读取最终 Manifest

Manifest 检查要覆盖构建变体、依赖库、合并结果、原始 APK、受保护候选和最终签名 APK。源码中没有权限不代表最终产物没有声明；相反，最终产物包含声明也不说明运行时已经获授权。可以使用 Android 官方 apkanalyzer 比较 APK 权限清单，参考权限差异检测指南；若输入是 AAB，则还要检查发布流程生成的设备交付 APK，不能将某个通用 APK 结果推到所有设备配置。

第三步：区分权限请求路径

若使用系统选择器，应确认用户能找到目标设备、选择结果能传递给应用、后续连接路径按平台设计执行。若采用广泛访问路径，应确认清单声明、运行时检查、用户说明、拒绝后的提示和撤销后的降级行为相互一致。只在 Manifest 添加权限而没有运行时授权处理，不能完整满足危险权限的用户体验和状态管理要求。

第四步：固定 Original 与 Protected 的比较对象

Original 与 Protected 必须来自同一业务版本、相同 target SDK、相同依赖状态和相同构建变体。记录各产物的本地摘要、构建来源、权限清单和签名阶段，但不要在公开文章中泄露客户包名、签名证书或私有文件信息。若受保护候选与原包 target SDK、Manifest 或依赖不同，应先说明差异，不能把所有行为变化归因给保护过程。

第五步：测试授权状态与网络路径

对可运行的目标候选，分别测试系统选择器路径、权限已授予、权限被拒绝、权限后来撤销、用户已有 NEARBY_DEVICES 组权限以及设备不在同一局域网等条件。检查发现、连接、数据交换和断线恢复各阶段。同步验证普通互联网请求是否仍然正常，以免把特定 LAN 阻断误判为全网故障。若功能在Original与Protected表现不同，先按相同账户状态和设备网络重复，再分析权限声明、运行时初始化、组件调用或打包差异。

第六步：定位差异首次出现阶段

按 Source Manifest → Merged Manifest → Original APK → Protected Candidate → Final Signed APK 逐阶段比较权限集合；随后把它与运行期授权状态和用例结果并列记录。权限在合并清单首次出现，优先检查变体与库声明；如果只在Protected产物出现，保护阶段进入调查范围，但仍需要复核输入身份、参数与重复结果；如果仅最终签名包变化，则检查渠道包装和后续重新构建。这个顺序是调查方法，不是预设归责。

第七步：设置审慎的发布状态

单一权限差异检查通过，不等于局域网业务通过；局域网访问成功也不等于隐私审查、Play 审核或加固安全评估已通过。发布门禁应让这些结论分别归档，再由负责团队依据业务风险决定是否发布。

动态时间线：API 升级、Manifest、授权与候选回归

兼容检查应沿着真实发布过程前进，而不是在看到一次权限弹窗后补写结论。首先确定当前稳定版本的 target SDK 与 LAN 功能基线，再建立目标 API 37 的升级候选；此时不要预设应用已经受影响。随后根据业务功能选择系统中介路径或广泛权限路径，并在相应构建变体中核对 Manifest 合并结果。

完成原始 Release 构建后，先测试 Original 在目标系统的设备发现、选择、连接、拒绝和撤销路径。基线明确后，再对同一输入生成 Protected Candidate，重复完全相同的权限状态、网络拓扑和用户操作。若两者结果不一致，记录第一处差异、权限组历史、网络类型和系统日志，并按首次差异阶段调查；不能为了得到PASS而更换账号、网络或APK。

在保护候选完成后还需检查最终签名和分发产物，确认Manifest、target SDK和授权流程仍对应已测试版本。如果发行流程生成设备特定APK，选择实际设备交付对象复核。发布后若 target SDK、网络库、Manifest、保护策略或Android系统 Build 发生变化，应按变更范围重跑受影响的测试。每条历史结果保留原始时间与范围，不通过改写日期把旧结果包装成新验证。

以下记录结构用于计划或保存真实授权测试；当前页面中所有产品测试字段均未执行：

record_type: android-local-network-compatibility
target_sdk: NOT_TESTED
android_build: NOT_TESTED
network_path: NOT_TESTED
permission_manifest: NOT_TESTED
runtime_grant_state: NOT_TESTED
system_picker_path: NOT_TESTED
original_artifact: NOT_TESTED
protected_candidate: NOT_TESTED
final_signed_artifact: NOT_TESTED
lan_discovery_result: NOT_TESTED
internet_connectivity_result: NOT_TESTED
revoke_and_recovery_result: NOT_TESTED
root_cause_category: INCONCLUSIVE

字段模板不是测试结果，不包含设备身份、APK摘要或客户信息，也不能代替相应团队在受控环境中执行真实测试。

攻防视角：最小权限和加固职责相互补充

系统提供选择器，是为了让用户控制共享哪一个局域网设备，而不是向应用授予对整个网络的宽泛发现能力。应用若确需管理多个设备，可以申请相应权限并解释用途，但应尊重拒绝和撤销。两种路径的选择应由真实产品功能决定，不能为了减少弹窗而隐藏权限用途，也不能因为具备加固就绕过 Android 系统授权模型。

APP 加固关注客户端代码、Native载体、完整性和运行时保护；Android 权限由系统控制；应用服务器负责账户、设备绑定和业务授权。权限声明、用户授权与加固保护是不同责任层。御盾不替应用团队决定是否需要扫描整个 LAN，也不替代Android权限审核、服务器端授权或目标设备的兼容测试。对投屏、企业设备管理和IoT场景，应由产品、研发、安全和发布负责人共同确定最小访问范围与回退体验。

风险边界

本页依据截至 2026-10-30 可访问的 Android 17 行为变化、局域网权限指南和 Manifest API 参考整理。Android 官方文档可能随着 Beta、QPR 和 API 变更而更新，实施时应复核最新条件。本文没有对御盾自有Demo、客户APK、AAB、Android设备、局域网设备发现、权限对话框、拒绝/撤销、ECH握手或受保护候选执行实测；以上产品级状态均为 NOT_TESTED。静态清单、官方文档和本文的测试流程不能被引用为“御盾已全面兼容Android 17”或“任何保护候选的权限保持不变”。

本文也不对Google Play是否批准某项功能用途作法律或政策判断。局域网访问权限规则、联系人权限政策和商店声明流程属于相关但不同的议题；如需了解联系人权限，可参阅Android 17 READ_CONTACTS 与 Contact Picker 发布检查。若需要管理完整的原包、保护候选和最终发布物验收口径，可查看御盾性能与兼容性中心及APP加固PoC验收指南。

常见误区

• 误区：所有Android 17应用都需要ACCESS_LOCAL_NETWORK。 官方适用条件针对 target API 37 或更高且实际需要局域网访问的场景；旧 target 应用不能套用 API 37 规则。
• 误区：权限进入 Manifest 就表示授权完成。 ACCESS_LOCAL_NETWORK 是危险权限，还需按平台要求处理运行时授权和拒绝/撤销。
• 误区：用户没有看到新弹窗，说明权限没有变化。 NEARBY_DEVICES 组内历史授权可能影响提示；测试前应固定权限状态。
• 误区：LAN失败等于互联网也失败。 官方将局域网、蜂窝网络和VPN区分；应按实际网络路径分别验证。
• 误区：只要使用系统选择器，就不需要验证后续连接。 选择器只覆盖适用的发现/选择过程，用户所选设备的业务连接仍需测试。
• 误区：Manifest权限集合一致就代表Original与Protected网络行为一致。 静态列表不能证明授权状态、网络栈、设备发现和业务连接相同。
• 误区：局域网权限与ECH是同一网络开关。 ECH属于TLS握手隐私能力，受网络库和服务器支持条件影响，不替代局域网访问许可。

常见问题

target API 36 的应用需要在Manifest中提前声明 ACCESS_LOCAL_NETWORK 吗？

Android 官方当前局域网权限指南指出，该权限只要求 target Android 17/API 37 或更高的应用；target API 36 或更低时，官方建议不要提前添加或在运行时请求它。具体实施仍应按最新平台文档和应用目标版本复核。

Android 17 会自动阻断所有网络请求吗？

不会。这里讨论的是局域网访问策略，不是通用互联网访问封锁。官方资料将局域网范围与蜂窝 WWAN、VPN连接区分。应使用明确的目标设备和网络路径测试，而不要把一个socket错误泛化为“全网不可用”。

Cast或mDNS应用是否一定可以不申请新权限？

不应一概而论。官方列出Cast输出切换器和 NsdManager 系统服务选择器作为适用场景的最小权限路径。具体项目还要检查实际功能、使用的 API、用户选择后的连接方式和目标系统行为；广泛或持续访问的需求可能仍需要运行时授权。

为什么有些测试没有弹出新的权限对话框？

ACCESS_LOCAL_NETWORK 位于 NEARBY_DEVICES 权限组。若测试账户已有组内其他授权，可能不会再次出现提示。请在重复测试前记录应用权限状态和测试账号历史，并分别验证系统实际授权结果，而不是把“无弹窗”当作结论。

ECH会让局域网设备发现失败吗？

不能由官方说明直接推出这一点。ECH是TLS扩展，需要网络库与远端服务器支持；ACCESS_LOCAL_NETWORK管理Android应用访问局域网的权限。若同一功能使用TLS连接设备服务，应把TLS协商和局域网授权分开记录。

御盾是否已经验证加固包兼容 Android 17 局域网权限？

本文没有提供此类第一方测试证据，当前状态为 NOT_TESTED。要形成限定范围的结论，需要固定同一业务版本的Original、Protected和最终发布物，记录target SDK、系统Build、网络类型、权限状态及具体业务路径。

延伸阅读与官方来源

• Android 17：面向 Android 17 或更高目标版本的行为变化
• Android Developers：Local network permission
• Android API：Manifest.permission.ACCESS_LOCAL_NETWORK
• Android 17 联系人权限与 Contact Picker 发布检查
• APK Manifest 权限差异检测指南
• 御盾性能与兼容性中心
• APP加固PoC验收指南

结语

Android 17 局域网访问的发布检查，应先按 target SDK 判断权限规则是否适用，再根据产品需要选择系统中介设备选择或广泛运行时授权。要评估加固是否影响功能，必须把清单声明、授权状态、网络类型和业务连接分开验证，并固定 Original、Protected 与最终发布物。没有执行过的设备、候选和路径继续标记 NOT_TESTED；本文提供的是官方规则说明与验收方法，不是御盾产品通过报告。