uniapp云打包自动添加电话权限？3步教你用AndroidManifest.xml精准移除-优快云博客

精准掌控应用权限：UniApp云打包权限管理的深度实践

最近在几个UniApp项目的隐私合规审查中，我发现了一个让不少开发者头疼的问题——云打包后应用会“自动”获得一些你从未主动申请的权限。这不仅仅是包体大小的问题，更直接关系到应用商店审核和用户隐私信任。如果你也遇到过在manifest.json里怎么都找不到某个权限的声明，但最终APK里却出现了，那么这篇文章正是为你准备的。我们将深入探讨UniApp云打包的权限机制，并手把手教你如何通过AndroidManifest.xml这个“终极武器”实现权限的精准管控，无论是移除冗余权限，还是添加特殊配置，都能做到心中有数。

1. 理解UniApp云打包的权限机制

很多从原生Android开发转向UniApp的开发者，最初都会对权限管理感到困惑。在原生开发中，所有权限都在AndroidManifest.xml文件中明确定义，清晰可控。而UniApp为了简化跨平台开发，通过manifest.json这一统一配置文件来抽象底层平台的差异。但正是这层抽象，有时会带来“黑盒”效应。

UniApp的云打包服务在构建APK时，并非简单地将你的manifest.json翻译成Android清单文件。其构建过程可以理解为：

基础模板注入：云打包服务器会从一个基础的Android项目模板开始，这个模板包含了UniApp运行所需的最小权限集和组件声明。
模块依赖合并：根据你在manifest.json中配置的模块（如“Maps”、“Push”等）以及引入的第三方原生插件（NativePlugin），系统会自动合并这些模块所声明的必要权限。
最终清单生成：将前两步合并后的清单，与你项目中可能存在的自定义AndroidManifest.xml文件进行二次合并，生成最终的应用程序清单。

问题就出在第二步。某些模块或SDK可能会声明一些“宽泛”的权限，例如READ_PHONE_STATE（读取电话状态），这个权限在过去常被用于获取设备唯一标识。即使你并未在代码中调用相关API，只要引入了相关模块，该权限就会被带入最终的APK。这导致了开发者意图与实际应用权限的不一致。

注意：READ_PHONE_STATE在Android高版本中属于敏感权限，其使用受到严格限制，且容易引发用户对隐私的担忧。不必要的声明会增加应用商店审核被拒的风险。

为了更直观地理解不同配置方式的影响，我们可以看下面这个对比：

配置方式	控制粒度	灵活性	适用场景
manifest.json (App模块配置)	粗粒度	低	声明应用基础功能所需的核心权限，如相机、定位。
manifest.json (SDK配置)	依赖模块	不可控	由所选模块（如推送、统计）自动引入，开发者通常无法直接干预。
原生插件配置	依赖插件	中	插件开发者在其配置文件中声明，应用开发者需知晓其内容。
自定义 AndroidManifest.xml	细粒度	极高	终极调控手段，可覆盖、移除或添加任何清单项，实现精准控制。

这张表清晰地揭示了为什么当我们需要解决自动添加的冗余权限时，必须深入到自定义AndroidManifest.xml这一层。它相当于给了你一把手术刀，可以对合并后的清单进行最后的、精确的修正。

2. 创建与配置自定义AndroidManifest.xml

既然知道了“病因”，接下来就是“对症下药”。在UniApp项目中创建自定义的Android清单文件，是覆盖云打包默认行为的关键。这个过程并不复杂，但需要确保文件的路径和格式绝对正确。

第一步：在项目根目录创建原生资源目录

UniApp约定，所有需要参与最终原生平台构建的自定义文件，都必须放在特定的“原生资源目录”下。这个目录不是默认存在的，需要你手动创建。

打开你的UniApp项目，在项目根目录（与pages.json、manifest.json同级）右键。
选择“新建” -> “目录”。
输入目录名：nativeResources
- 请注意，这个名字是固定的，必须全部小写。这是UniApp构建系统识别的关键。

第二步：在原生资源目录下创建Android平台配置

nativeResources目录是一个容器，里面需要按平台进一步组织。我们目前只关心Android。

进入刚刚创建的nativeResources目录。
再次右键新建目录，命名为android。
进入android目录，继续新建目录，命名为xml。这个xml文件夹就是专门用来存放自定义清单文件的地方。

现在你的目录结构应该看起来像这样：

你的UniApp项目/
├── pages/
├── static/
├── nativeResources/   （你新建的）
│   └── android/       （你新建的）
│       └── xml/       （你新建的）
├── manifest.json
└── ...

第三步：创建并编写AndroidManifest.xml文件

在xml文件夹内，右键新建一个文件，命名为AndroidManifest.xml。然后，你需要为其填充一个基础框架。

这个文件的内容不是任意的，它必须是一个合法的Android清单文件片段。其核心作用是“覆盖”或“修改”云打包合并后的清单。我们从一个最小化的模板开始：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="io.dcloud.nativeresource">

    <application>
        <!-- 这里可以放置需要覆盖或添加的application级配置 -->
    </application>

</manifest>

这里有三个关键点需要解释：

package属性：这个值io.dcloud.nativeresource是一个虚拟的包名，仅用于标识这个清单文件来自原生资源。它绝对不能与你应用在manifest.json中配置的真正的包名（bundle ID）相同，否则会引起冲突。保持这个默认值即可。
tools命名空间：声明xmlns:tools至关重要。它引入了Android构建工具（如AAPT2）的特殊指令，我们后续移除权限全靠这个命名空间下的属性。
<application>节点：即使你暂时不需要修改应用配置，也建议保留这个空节点，结构更完整。

文件创建好后，云打包时就会自动发现并合并它。但此时它还未做任何实际修改。

3. 精准移除冗余权限：以电话权限为例

现在，我们进入实战环节。假设通过分析生成的APK，或者从应用商店的审核反馈中，你发现了一个不需要的android.permission.READ_PHONE_STATE权限。我们的目标是在不修改任何模块代码的情况下，将其从最终清单中剔除。

原理：使用 tools:node="remove"

Android的构建工具链支持清单文件合并，并提供了强大的tools:属性来控制合并行为。tools:node="remove"就是一个“移除”指令。它的含义是：在最终合并清单时，找到匹配的元素并将其删除。

操作：在自定义清单中添加移除指令

打开刚才创建的nativeResources/android/xml/AndroidManifest.xml文件，在<manifest>标签内、<application>标签外，添加如下内容：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="io.dcloud.nativeresource">

    <!-- 权限控制区域 -->
    <uses-permission android:name="android.permission.READ_PHONE_STATE" tools:node="remove" />

    <application>
        <!-- 应用配置 -->
    </application>

</manifest>

就是这么简单的一行，就宣告了该权限的“死刑”。当云打包服务器完成所有模块的清单合并后，在最后阶段处理你的这个自定义文件时，会执行移除操作。

验证与排查

修改完成后，提交云打包。拿到APK文件后，如何进行验证呢？你不能只看安装时的权限提示，因为那是运行时动态申请的。你需要检查APK内部的清单文件。

使用构建工具：最准确的方式是使用Android SDK中的aapt2工具。在命令行中定位到你的APK文件所在目录，执行（路径可能需要调整）：
```
aapt2 dump xmltree your_app.apk AndroidManifest.xml
```
在输出的庞大XML树中，搜索READ_PHONE_STATE，如果找不到，说明移除成功。
使用可视化工具：对于大多数开发者，使用像Android Studio自带的APK Analyzer更直观。
- 将APK文件拖入Android Studio。
- 在分析结果中，找到并双击AndroidManifest.xml。
- 使用文本搜索功能，查找权限名称。如果自定义清单生效，你将看不到该权限的声明。

如果发现权限仍然存在，请按以下步骤排查：

检查文件路径和名称：确保是nativeResources/android/xml/AndroidManifest.xml，一字不差。
检查XML格式：确保没有语法错误，例如标签未闭合、字符编码问题。
检查合并冲突：极少数情况下，如果其他模块使用tools:node="replace"或tools:node="merge"等强指令，可能会产生冲突。这时需要更复杂的合并规则控制。

4. 高级技巧与扩展应用

掌握了移除权限的基本方法后，这个自定义清单文件的能力远不止于此。它实际上是你与原生Android构建流程对话的一个接口，可以完成许多高级配置。

扩展应用一：移除其他类型的冗余声明

除了权限(<uses-permission>)，你还可以移除其他自动添加的组件或元数据(<meta-data>)。例如，某些广告SDK可能会自动添加一个默认的Activity或Service，而你的应用并未使用。

<!-- 移除一个不需要的Activity声明 -->
<activity
    android:name="com.some.ad.sdk.SomeAdActivity"
    tools:node="remove" />

<!-- 移除一个不需要的meta-data -->
<meta-data
    android:name="com.google.android.gms.ads.APPLICATION_ID"
    tools:node="remove" />

扩展应用二：添加或覆盖原生配置

你还可以添加云打包模板中不包含的配置。例如，为你的WebView启用调试功能（仅限调试版本），或者强制应用使用硬件加速。

<application
    android:usesCleartextTraffic="true"
    tools:replace="android:usesCleartextTraffic">

    <!-- 为特定Activity添加硬件加速 -->
    <activity
        android:name="io.dcloud.PandoraEntry"
        android:hardwareAccelerated="true" />

    <!-- 添加应用级别的meta-data -->
    <meta-data
        android:name="com.example.CUSTOM_CONFIG"
        android:value="my_value" />
</application>

注意上面例子中的tools:replace属性，它用于替换已存在项的属性值。当你想修改基础模板中已有的<application>属性时，必须使用tools:replace指明要替换哪个属性，否则合并可能会失败。

扩展应用三：处理更复杂的合并场景

有时，你可能需要更精细的控制。例如，只想在打某个渠道包时移除权限，或者针对不同的API级别做不同配置。虽然UniApp的自定义清单本身不支持条件判断，但你可以通过结合HBuilderX的“自定义发行代码”和项目配置文件来实现变通。

一个常见的做法是，创建多个不同配置的AndroidManifest.xml文件，例如：

AndroidManifest.xml (默认，移除敏感权限)
AndroidManifest.channel_a.xml (渠道A特有配置)

然后在项目的package.json（如果使用cli项目）或通过HBuilderX的个性化打包脚本，在打包前动态地将对应的文件复制到nativeResources/android/xml/目录下。这需要一定的脚本编写能力，但为大型项目的多环境配置提供了可能。

在整个实践过程中，我最大的体会是：对构建产物的逆向验证至关重要。不要假设配置一定生效，每次重要的权限或配置变更后，养成分析APK包内容的习惯。这不仅能确认修改效果，还能让你更深入地理解UniApp应用的最终构成，从“黑盒”使用者转变为“透明”的掌控者。毕竟，在隐私合规要求日益严格的今天，应用里每一个多余的权限声明，都可能成为项目前进路上的绊脚石。