1. 项目概述当Appium遇上真机权限墙搞移动端自动化测试的朋友对Appium这个老伙计肯定不陌生。它就像一把万能钥匙能同时打开Android和iOS两扇门让我们用一套脚本驱动不同平台的设备。但越是强大的工具在特定环境下“尥蹶子”的时候就越让人头疼。今天要聊的这个报错就是很多人在从模拟器转向真机测试时必然会撞上的一堵“权限墙”。报错信息很直白Permission denial: writing to settings requires:android.permission.WRITE_SECURE_SETTINGS。翻译过来就是“权限被拒绝写入系统设置需要android.permission.WRITE_SECURE_SETTINGS权限”。这可不是Appium的bug而是Android系统为了安全筑起的一道高墙。WRITE_SECURE_SETTINGS是一个系统级签名权限signature|privileged普通应用哪怕是拥有adb shell权限的测试工具在未经特殊授权的情况下也绝无可能直接修改那些关乎系统全局安全的设置项比如全局动画缩放、默认输入法、无障碍服务开关等。当你从模拟器通常拥有root或更高权限切换到一台普通的、未root的商用真机上时环境发生了根本变化。Appium在初始化会话或执行某些自动化操作例如为了稳定测试而尝试禁用动画animator_duration_scale时会尝试去修改这些安全设置从而触发系统的权限拦截。这个问题不解决你的自动化脚本可能在启动阶段就“出师未捷身先死”卡在设备初始化环节。接下来我们就从根儿上拆解这个问题并提供一套从临时规避到根治解决的完整方案。2. 核心原理与权限体系深度解析要解决问题得先明白问题从哪来。这个报错触及了Android安全架构的核心——权限保护机制。2.1 Android权限等级与WRITE_SECURE_SETTINGSAndroid的权限不是铁板一块而是分成了几个保护级别Protection Level。我们遇到的WRITE_SECURE_SETTINGS属于最高级别之一普通权限Normal 应用在清单文件里声明了安装时即被授予用户无感。比如访问网络。危险权限Dangerous 涉及用户隐私或设备操作如相机、通讯录。需要运行时向用户弹窗申请。签名权限Signature 只有当申请此权限的应用其签名证书与定义此权限的系统应用或使用相同证书签名的应用相同时系统才会授予。这用于系统组件或深度集成的应用间保护。特权权限Privileged 是签名权限的一个子集。除了签名匹配应用还必须被安装在系统的特权目录如/system/priv-app下。这类权限通常用于设备制造商OEM预装的核心应用。WRITE_SECURE_SETTINGS的完整保护级别是signature|privileged。这意味着签名匹配 你的应用必须用与Android系统相同的平台密钥platform key签名或者与已经拥有该权限的系统应用如Settings应用使用相同的证书签名。这几乎不可能为你的测试应用实现。特权位置 你的应用必须被预装在/system/priv-app目录下。这对于用户后安装的应用来说也是不可能的。因此一个通过adb install安装的普通Appium测试包io.appium.settings或你的被测应用天生就不具备获取该权限的资格。当Appium的底层引擎通常是UiAutomator2尝试通过adb shell settings put命令修改secure表里的设置时系统会坚决地返回一个SecurityException也就是我们看到的Permission denial。2.2 Appium为何需要这个权限你可能会问Appium好好做自动化干嘛要去动系统安全设置这主要是为了测试的稳定性和可靠性。一些常见的场景包括禁用动画 这是最主要的原因。通过settings put global animator_duration_scale 0等命令可以关闭窗口动画、过渡动画和动画程序时长缩放。动画会导致元素出现、消失有延迟使得基于定时等待的自动化脚本变得不稳定元素未出现就操作导致NoSuchElementException。禁用动画后UI状态变化是“瞬间”的极大提高了元素定位和操作的可靠性。调整其他系统设置 例如确保“不锁定屏幕”stay_on_while_plugged_in防止测试过程中设备休眠或者设置默认输入法确保键盘输入可控。在模拟器或已root的真机上adb shell通常具有root或shell用户的超高权限可以绕过这个检查。但在非root真机上此路不通。2.3 关联热词现象解读浏览相关的搜索热词你会发现大量围绕“真机调试”、“环境配置”、“权限报错”的问题。例如“harmonyos 7 arkts 真机调试”、“微信小程序真机调试没有报错但是进程异常”、“androidstudio无法连接真机”。这反映了一个普遍现状开发与测试环境从理想的模拟器/root设备向复杂的、受限制的真实用户设备迁移时权限和环境差异是主要的绊脚石。我们的WRITE_SECURE_SETTINGS报错正是这一大类问题在Appium自动化测试领域的一个典型代表。理解并解决它对于构建健壮的真机自动化测试体系至关重要。3. 解决方案全景图从规避到根治面对这堵墙我们有几种策略从“绕过去”到“获得钥匙”风险和实施难度各不相同。下图清晰地展示了不同解决方案的路径与权衡flowchart TD A[遭遇WRITE_SECURE_SETTINGS权限错误] -- B{选择解决路径}; B -- C[路径一规避br修改Appium配置]; B -- D[路径二临时授权br使用adb grant]; B -- E[路径三根治授权br修改系统镜像]; C -- C1[禁用相关Capabilitybr如disableWindowAnimation]; C1 -- C2[结果br脚本可能不稳定动画影响操作]; D -- D1[前提brAndroid API 23 且已授权]; D1 -- D2[执行命令bradb shell pm grant ...]; D2 -- D3[结果br会话级有效设备重启后需重复]; E -- E1{设备是否已Root}; E1 -- 是 -- E2[方案A使用Root ADBbr风险低可逆]; E1 -- 否 -- E3[方案B刷入Magisk模块br风险高需解锁]; E2 -- E4[挂载系统分区为可写]; E4 -- E5[推送授权App至特权目录]; E5 -- E6[结果br永久授权一劳永逸]; E3 -- E7[解锁Bootloaderbr会清除数据]; E7 -- E8[刷入Magisk获取Root]; E8 -- E9[安装权限授予模块]; E9 -- E6;3.1 方案一修改Appium配置规避权限需求推荐首选这是最安全、最通用的方法。既然我们没有权限那就告诉Appium“别去做那些需要权限的事情”。通过调整Desired Capabilities来实现。核心思路 Appium UiAutomator2驱动提供了一些capability来精确控制其初始化行为避免触发敏感操作。关键Capability配置{ platformName: Android, deviceName: your_device, appPackage: com.example.app, appActivity: .MainActivity, automationName: UiAutomator2, noReset: true, disableWindowAnimation: true, // 关键禁止尝试禁用窗口动画 disableTransitionAnimation: true, // 关键禁止尝试禁用过渡动画 disableAnimator: true // 关键禁止尝试禁用Animator动画 }实操要点与解释disableWindowAnimation,disableTransitionAnimation,disableAnimator 这三个Capability默认是false。当设置为true时Appium-UiAutomator2服务器在启动时会跳过相应的settings put命令从而从根本上避免触发WRITE_SECURE_SETTINGS权限错误。效果 动画不会被禁用你的测试脚本需要能够处理动画带来的延迟。这意味着你需要更健壮的等待策略如WebDriverWait配合Expected Conditions而不是依赖固定的sleep。优点 无需改动设备兼容所有Android版本和机型包括华为HarmonyOS是最安全的方案。缺点 测试稳定性可能略低于禁用动画的环境对脚本的编写质量要求更高。注意 有些教程会建议使用adb shell settings put global animator_duration_scale 0命令在测试前手动执行但这同样需要WRITE_SECURE_SETTINGS权限在非root设备上行不通。此方案是“不做”而不是“做了但没权限”。3.2 方案二通过adb grant临时授予权限条件苛刻从Android 6.0 (API 23) 开始系统引入了adb shell pm grant命令允许通过ADB为应用授予某些权限包括部分签名权限。但这方法对WRITE_SECURE_SETTINGS极其有限。前提条件设备系统为Android 6.0及以上。设备必须是用户调试版本userdebug build或工程机而不是普通的用户版本user build。零售机几乎都是user build。在设备的“开发者选项”中必须已经开启了“USB调试安全设置”或“允许通过ADB授予权限”之类的选项不同厂商命名不同。操作命令 首先找到Appium设置辅助应用的包名通常是io.appium.settings。adb shell pm grant io.appium.settings android.permission.WRITE_SECURE_SETTINGS结果与局限如果成功当前会话内Appium将获得权限。设备重启后授权会失效需要重新执行。绝大多数消费级真机user build根本无法成功执行会报错Operation not allowed。因此此方案仅适用于极少数特定的测试设备不具备普适性。3.3 方案三修改系统永久获取权限激进方案这是“获得钥匙”的方法通过修改系统镜像使Appium的相关应用具备特权。警告此操作有风险可能导致设备变砖、失去保修、数据丢失请仅用于专属测试设备。方案A对于已Root的设备相对简单如果设备已经通过Magisk等方式获得了root权限你可以手动将Appium的Settings应用提升为特权应用。使用Root Explorer或ADB root shell将/system分区重新挂载为可读写adb shell mount -o rw,remount /system部分新机型路径可能是/system_root。将io.appium.settings的APK文件推送至特权应用目录adb push appium-settings.apk /system/priv-app/。重启设备。该应用将以特权身份运行自然拥有WRITE_SECURE_SETTINGS权限。方案B对于未Root的设备非常复杂这需要解锁Bootloader刷入自定义Recovery并刷入一个包含了特权版io.appium.settings的Magisk模块或系统补丁包。整个过程因机型而异风险极高通常只由高级玩家或企业测试部门对专用测试机进行操作。核心思路是制作一个系统模块在/system/priv-app目录下部署一个被授予了所需权限的Appium Settings应用。个人建议 对于团队自动化测试优先采用方案一配置规避。如果对测试稳定性有极致要求且拥有设备的完全控制权如公司采购的专用测试机可以考虑在专人指导下进行方案三的操作并做好设备隔离和数据备份。4. 完整实战从环境配置到脚本调试让我们以一个完整的实战流程将方案一落地。假设我们要在华为Mate 60HarmonyOS 4.0非root上测试一个名为DemoApp的应用。4.1 环境准备与检查清单在开始写脚本之前确保你的战场是准备好的。1. 基础环境Appium Server 建议使用2.0版本可通过npm安装npm install -g appium。启动时建议使用--allow-insecure和--relaxed-security标志以放宽一些安全检查但需注意安全风险。Appium Clients 安装Python的Appium-Python-Client库pip install Appium-Python-Client。Android SDK 确保ANDROID_HOME环境变量已设置并且adb工具位于PATH中。platform-tools版本尽可能新。2. 真机准备开启开发者模式与USB调试 在手机“关于手机”中连续点击“版本号”7次激活开发者选项然后在其中开启“USB调试”。连接电脑 使用原装或高质量数据线连接。执行adb devices确认设备已列出并显示device状态而非unauthorized。如果未授权请在手机弹出的RSA密钥指纹确认对话框中点击“允许”。安装必要APK Appium在首次运行时会自动向设备推送io.appium.settings,io.appium.uiautomator2.server等辅助应用。确保网络通畅。3. Capability配置详解 我们使用Python为例编写一个基础的测试脚本test_demo.py。from appium import webdriver from appium.options.android import UiAutomator2Options import time # 定义设备能力 options UiAutomator2Options() options.platform_name Android options.device_name HUAWEI Mate 60 # 自定义名称用于日志识别 options.app_package com.example.demoaPP # 替换为你的被测App包名 options.app_activity .MainActivity # 替换为你的主Activity # 关键规避权限错误的配置 options.disable_window_animation True # 跳过禁用窗口动画的命令 options.disable_transition_animation True # 跳过禁用过渡动画的命令 options.disable_animator True # 跳过禁用Animator动画的命令 # 其他常用配置 options.no_reset True # 不重置应用状态适合连续测试 options.auto_grant_permissions True # 自动授予应用运行时权限如定位、相机 # options.full_reset False # 与no_reset互斥通常用no_reset # 连接Appium Server driver webdriver.Remote(http://127.0.0.1:4723, optionsoptions) try: # 你的测试逻辑从这里开始 print(设备连接成功会话已建立。) time.sleep(3) # 示例等待实际应用应使用显式等待 # 例如点击一个ID为“btn_login”的按钮 # login_btn driver.find_element(AppiumBy.ID, btn_login) # login_btn.click() except Exception as e: print(f测试执行出错: {e}) finally: # 测试结束退出会话 driver.quit() print(会话结束。)4.2 执行流程与问题排查启动Appium Server 在一个终端运行appium或appium --allow-insecureadb_shell。运行测试脚本 在另一个终端运行python test_demo.py。观察日志成功迹象 Appium Server日志中不会出现Permission denial相关的错误而是正常启动UiAutomator2服务器并成功连接到设备。你的脚本会开始执行。失败排查session not created/Unable to create a new remote session 检查Capability拼写是否正确如disable_window_animation设备是否在线adb devices端口是否被占用。应用找不到/无法启动 检查app_package和app_activity名称是否正确。可以使用adb shell dumpsys window | grep mCurrentFocus命令查看前台Activity。其他权限错误 如果出现非WRITE_SECURE_SETTINGS的权限错误可以尝试在Capability中设置autoGrantPermissions为true或手动在设备上为被测应用授权。一个重要的实操心得 在配置了禁用动画规避后你的脚本等待策略需要调整。不要再使用固定的time.sleep(5)而应该使用显式等待。这是提升真机测试稳定性的关键。from appium.webdriver.common.appiumby import AppiumBy from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # ... driver初始化之后 ... wait WebDriverWait(driver, 10) # 最多等待10秒 # 等待一个元素出现并可点击 element wait.until(EC.element_to_be_clickable((AppiumBy.ID, btn_submit))) element.click() # 等待一个元素在页面上可见 element2 wait.until(EC.visibility_of_element_located((AppiumBy.XPATH, //android.widget.TextView[text成功])))5. 进阶讨论与衍生问题应对解决了启动权限问题只是真机自动化测试的第一步。在复杂的真实环境中还会遇到其他连带问题。5.1 与其他常见真机问题的关联处理查看网络热词很多问题与我们的场景交织“微信小程序真机调试没有报错但是进程异常” 这常与WebView上下文切换、小程序安全策略有关。在Appium中需要正确使用driver.context来切换到小程序的WEBVIEW_上下文并可能需要处理证书或跨域问题。“androidstudio无法连接真机” 通常是驱动问题华为、小米等需要单独安装USB驱动、ADB版本冲突、或5037端口被占用。确保使用Android SDK自带的ADB并通过adb kill-serveradb start-server重启服务。“雷电模拟器改真机环境” 有些游戏或应用会检测模拟器。Appium连接模拟器本质上和真机一样但模拟器的设备指纹、传感器数据可能与真机不同导致应用行为差异。这不是Appium能解决的需要修改模拟器配置或使用真机。5.2 企业级测试框架的权限管理思考在CI/CD流水线中面对成百上千台不同型号、不同系统的真机设备统一的权限策略至关重要。设备池分级 将设备分为“高权限组”已root/工程机可用于需要修改系统设置的测试和“标准组”普通零售机使用规避策略。动态Capability注入 在测试调度系统中根据设备属性自动为测试任务添加对应的Capability如为“标准组”设备自动添加disableWindowAnimation: true。前置检查脚本 在测试开始前运行一个adb shell脚本检查设备型号、Android版本、是否root并据此判断是否跳过某些测试用例或采用不同的断言标准。统一镜像管理 对专用测试机维护一个统一的、预装了所有必要特权辅助应用和基础配置的系统镜像快速刷机恢复保证环境一致性。5.3 HarmonyOS设备的特别注意事项华为HarmonyOS在底层兼容Android但仍有其特殊性。权限模型更严格 HarmonyOS对后台启动Activity、读取设备信息等有额外限制。确保在“设置-应用-权限管理”中为被测应用和Appium相关应用如io.appium.settings授予所有必要的权限。USB调试开关可能隐藏 在某些HarmonyOS版本中需要在“开发者选项”中打开“仅充电模式下允许ADB调试”才能稳定连接。Capability兼容性 本文提到的规避动画的Capability在HarmonyOS上同样有效。如果遇到连接问题可以尝试在Capability中指定automationName: “UiAutomator2”并确保使用的是最新版本的Appium。真机自动化测试的魅力在于它无限接近用户真实场景而它的挑战也正源于此——真实世界的复杂性和多样性。WRITE_SECURE_SETTINGS权限错误就像一道入门考题它迫使我们去理解Android系统的安全机制去思考测试脚本的健壮性去设计更优雅的测试架构。从最初的“报错了怎么办”到后来的“哦这是系统保护我们应该这样规避”再到最终的“我们的测试框架能自动适配不同权限的设备”这个过程本身就是测试工程师成长的缩影。记住在真机测试的世界里与其对抗系统不如学会在系统的规则内优雅地跳舞。把每一次报错都当成深入了解平台特性的机会你的自动化测试之路才会越走越稳。
