安装新应用之后，分应用清单不会自动按显示名称更新。Android 要求：只有当时已经安装的应用才能加入允许或拒绝列表；列表必须在 VPN 连接建立前写入 VpnService.Builder；若要让新应用按新的接管关系生效，必须建立一次新的 VPN 连接。Clash Meta for Android 是 Clash.Meta 的图形界面客户端，包名 com.github.metacubex.clash.meta，通过该 VPN 接口工作。仓库记载了启停意图与导入配置方案，未记载分应用菜单名称，因此维护清单应依据 per-app VPN 规则，而不是未写明的按钮路径。
适用条件与三种默认后果
设备需 Android 5.0 及以上（建议 7.0 及以上）。每个用户或工作资料仅能有一个活动 VPN，新服务会停掉旧服务。未创建允许或拒绝列表时，系统把全部流量送入 VPN，新安装的应用也会走 VPN。若使用允许列表且列表非空，则只有列表内应用走 VPN，新应用默认走系统网络，直到被加入列表并重建连接。若使用拒绝列表，被拒绝者走系统网络，其余走 VPN，新应用默认走 VPN，除非随后把它写入拒绝列表并重建连接。允许与拒绝不能同时使用。官方提醒：当系统阻止不经 VPN 的连接时，不在相应名单语义下的应用会失去网络，维护新应用时要把“未接管”和“被切断”区分开。
安装后如何把新应用纳入或排除
第一步确认新应用已安装，并取得真实包名。官方示例循环包名数组，对每一项 getPackageInfo；成功则 addAllowedApplication，捕获 NameNotFoundException 则跳过。安装尚未完成、包名写错、只记下桌面标题，都会让该项无法进入 Builder。第二步在完整 Builder 流程中写入列表：至少 addAddress()、addRoute()，按需要 addDnsServer()，再 establish()。第三步因为“改列表必须新建连接”，应停止当前 VPN 再按同一套最新名单建立接口，而不是假设旧 TUN 会热更新过滤表。always-on VPN 由系统在开机后拉起服务，应用须在每次启动时用保存的最新配置建立连接；文档要求在系统托管生命周期时禁用“由应用自己断开”的交互，并把配置在各次启动间保存。
维护策略可以固定为一种：以允许列表为白名单时，每安装一个需要进 Clash.Meta 的应用，就把它的包名并入集合后重建；以拒绝列表为黑名单时，只有当新应用必须离开 VPN 时才追加包名并重建，其余新应用保持默认进 VPN。无列表策略则无需为新应用改名单，但也就没有按应用过滤。Clash Meta 隧道套接字仍应 protect()，避免客户端自环；这与新应用是否加入名单无关。工作资料里新装的应用只属于该资料，不能把个人资料的名单直接套过去。
判断维护是否完成
判断依据不是“应用已经出现在桌面”，而是：包名能被 getPackageInfo 解析；当前 Builder 只使用允许或拒绝之一；establish() 发生在写入该包名之后且未返回空；系统 VPN 指示（状态栏钥匙图标、快捷设置、不可关闭通知）显示服务活动。若采用允许列表，新应用在重建前应表现为走系统网络；重建且纳入后，其流量才进入 TUN。若采用拒绝列表且未把新应用列入，重建前后它都应进入 VPN。开启拦截非 VPN 流量时，允许列表尚未包含的新应用可能直接无网，这表示维护尚未把该包名按预期写入并重建。
失败时的下一步
新应用仍不按预期走或绕开 VPN 时：先确认安装完成与包名；再确认没有同时写两类列表；然后停启服务以强制新接口。仓库提供向 ExternalControlActivity 发送 com.github.metacubex.clash.meta.action.STOP_CLASH、START_CLASH 或 TOGGLE_CLASH 的方式。establish() 为空时重新 VpnService.prepare() 并完成系统授权。若 always-on 已开启，以设置项与系统生命周期为准，同时确保服务每次被拉起都带上含新包名的名单。若新应用绑定了其他网络（bindProcessToNetwork 或 bindSocket），仅维护名单不够，还须考虑建立接口时是否 allowBypass()。把“已安装 → 写入唯一一类列表 → 重新建立连接”当成固定维护循环，即可在后续每次装新应用时重复同一判断，而不依赖未记载的界面名称。
https://developer.android.com/develop/connectivity/vpn https://github.com/MetaCubeX/ClashMetaForAndroid