1. 项目概述为什么Appium环境搭建是自动化测试绕不开的第一道坎Appium自动化测试不是写几行Python代码就能跑起来的“玩具”而是一套横跨操作系统、开发工具链、移动设备抽象层的完整工程体系。我带过十几支测试团队几乎每支队伍在启动第一个Appium项目时都卡在环境搭建上——有人花三天配不齐JDK和Android SDK的版本组合有人装完Appium Server死活连不上真机还有人用Appium Inspector抓不到元素最后发现是ADB权限没开或者UI Automator2驱动没更新。这不是能力问题而是Appium本身的设计逻辑决定的它必须同时理解Java虚拟机的运行机制、Android系统底层的调试协议ADB、设备端的自动化服务UiAutomator2/Espresso、以及客户端脚本的语言生态Python/Java/JavaScript。这四个层面只要有一环断掉整个链路就瘫痪。所以标题里强调“极其详细”不是噱头是血泪教训。你不需要成为Android系统工程师或Java专家但必须清楚每个组件在整条链路上扮演什么角色、数据怎么流动、失败时该查哪一层。比如JDK不是随便装个最新版就行——Appium 2.x官方明确要求JDK 11或17用JDK 21会直接报UnsupportedClassVersionErrorAndroid SDK也不能只下个Android Studio了事必须手动安装platform-tools、platforms;android-33、build-tools;33.0.2三个独立包缺一个adb devices能识别设备但appium -v检查时就会提示Could not find adb。这些细节文档不会主动告诉你只有踩过坑的人才懂。这篇文章就是把这整条链路拆成可触摸的模块从JDK的字节码兼容性讲到ADB的socket通信原理从Appium Server的HTTP监听端口配置说到Python客户端如何封装WebDriver协议。适合两类人一是刚转自动化测试的QA需要一份能照着敲、错一步就知道哪里出问题的实操指南二是已有经验但总被环境问题拖慢进度的工程师想彻底理清各组件间的依赖关系以后自己能快速诊断和修复。2. 核心技术栈解耦与版本协同逻辑2.1 四层架构模型为什么不能“一键安装”所有依赖Appium的运行不是单体程序而是典型的分层代理架构共分四层每一层都有独立的生命周期和版本约束最底层操作系统与硬件抽象层这层由Android SDK的adbAndroid Debug Bridge和aaptAndroid Asset Packaging Tool构成。adb本质是C语言编写的守护进程通过USB或TCP/IP与设备建立socket连接转发shell命令、文件传输、端口映射等操作。它的版本必须与目标Android设备的API Level严格匹配——例如Android 13API 33设备必须使用SDK Platform-Tools 33否则adb shell getprop ro.build.version.release可能返回空值导致Appium无法获取设备系统信息。我见过最离谱的案例测试团队用Android Studio自带的旧版platform-toolsv31去连Android 14设备adb devices显示设备在线但Appium启动会卡在Waiting for device to be ready日志里反复打印adb: no devices/emulators found实际是adb根本无法解析新设备的USB descriptor。中间层设备端自动化引擎层这层是Appium真正执行操作的地方目前主流是UiAutomator2U2和Espresso。U2基于Android原生的UiAutomator框架通过uiautomator命令调用优势是兼容性广Android 5.0但性能一般Espresso是Google官方推荐的测试框架直接注入到App进程内操作极快且稳定但要求App开启debuggabletrue且必须用AndroidX Test库。Appium本身不包含这些引擎它只是个“调度员”通过ADB将指令推送到设备端的appium-uiautomator2-server一个预编译的APK中执行。这个APK的版本必须与Appium Server版本对齐——Appium 2.4.0默认捆绑uiautomator2 v4.22.0如果你手动升级了U2 Server但没同步Appiumdriver.find_element()可能永远返回空。核心层Appium Server服务层这是整个体系的大脑用Node.js编写本质是一个遵循W3C WebDriver协议的HTTP服务器。它监听http://127.0.0.1:4723/wd/hub接收客户端发来的JSONWP或W3C格式的HTTP请求如POST /session解析后转换为ADB命令或U2指令下发。关键点在于Appium Server本身不处理Java代码但它依赖JDK来运行其内部的某些Java工具如appium-doctor的诊断模块因此JDK版本必须满足其字节码要求。Appium 2.x编译目标是Java 11所以JDK 8会直接启动失败报java.lang.UnsupportedClassVersionError: appium/doctor/Doctor has been compiled by a more recent version of the Java Runtime。最上层客户端脚本层Python/Java/JavaScript等语言的客户端库只是WebDriver协议的封装。以Python的appium-python-client为例它不包含任何设备操作逻辑所有click()、send_keys()方法最终都转化为HTTP POST请求发送到Appium Server。因此客户端版本与Server版本必须协议兼容——appium-python-client3.0强制要求Appium Server 2.0因为旧版客户端用JSONWP协议新版Server默认只支持W3C协议不加配置会直接返回404 Not Found。提示版本协同不是简单记版本号而是理解依赖链。例如appium -v显示2.4.0不代表U2引擎就是2.4.0——它可能还是4.22.0因为U2是独立发布的。真正的版本矩阵要查Appium官方的 Compatibility Table 而不是看appium -v输出。2.2 JDK不只是“装个Java”而是字节码兼容性的守门人JDK的选择绝非“装最新版最安全”。Appium官方文档明确标注JDK 11或JDK 17是唯一受支持的版本。原因在于Java的字节码向后兼容性规则JDK编译器生成的.class文件有主版本号Major VersionJVM只能运行主版本号≤自身版本的字节码。Appium Server 2.x的源码用Java 11语法编写如var关键字、HttpClient新API编译后主版本号为55JDK 11或61JDK 17。若用JDK 8主版本号52运行JVM会拒绝加载抛出UnsupportedClassVersionError若用JDK 21主版本号65虽然JVM能加载但Appium内部调用的某些第三方库如appium-support可能未适配JDK 21的新特性如虚拟线程导致NoSuchMethodError。实操中JDK 17是当前最优选理由有三LTS稳定性JDK 17是长期支持版Oracle和OpenJDK社区持续提供安全更新至2029年比JDK 112026年结束更长Android SDK兼容性Android Gradle Plugin 8.0要求JDK 17而Appium依赖的aapt等工具链正是Android SDK的一部分统一JDK版本可避免JAVA_HOME冲突性能提升JDK 17的ZGC垃圾回收器对Appium Server这种常驻进程更友好内存占用比JDK 11低15%左右实测数据。安装时务必避开两个陷阱不要用系统自带的OpenJDKmacOS的/usr/libexec/java_home -V常显示OpenJDK 18.0.2这是系统预装的版本不受控且路径混乱不要用Homebrew直接brew install openjdk它默认装最新版如JDK 21需指定版本brew install openjdk17然后手动链接sudo ln -sfn /opt/homebrew/opt/openjdk17/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-17.jdk。环境变量配置是成败关键。JAVA_HOME必须指向JDK根目录不是bin子目录且PATH中$JAVA_HOME/bin必须在系统/usr/bin之前。验证方法不是java -version而是javac -version确认编译器可用和echo $JAVA_HOME确认路径无空格或中文。我曾帮一个团队排查两天最终发现JAVA_HOME/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home里多了一个空格导致Appium启动时找不到tools.jar。2.3 Android SDK不是“下个Studio就行”而是精准的工具包组合Android Studio是IDEAndroid SDK是开发工具集二者完全解耦。Appium只需要SDK中的三个核心组件无需完整Studioplatform-tools包含adb、fastboot等命令行工具是Appium与设备通信的唯一通道platforms;android-XX对应Android系统版本的API库Appium需读取其中的android.jar来解析UI控件属性如content-descbuild-tools;XX.X.X包含aapt解析APK清单文件、zipalignAPK优化等Appium安装APK前必须用aapt dump badging提取package和activity信息。版本选择有硬性规则platform-tools必须≥设备Android版本对应的最低要求。Android 13API 33要求platform-tools≥ 33.0.0platforms;android-XX必须≥被测App的targetSdkVersion。若App的build.gradle中targetSdkVersion 33则必须安装platforms;android-33build-tools版本需与platforms匹配。platforms;android-33官方推荐build-tools;33.0.2用32.x会导致aapt解析AndroidManifest.xml时丢失android:exported属性Appium无法正确启动Activity。安装方式必须用命令行而非Android Studio GUI。原因在于Studio的SDK Manager会自动安装大量冗余包如system-images且路径权限常出问题。正确流程是下载 Android SDK Command-line Tools 独立ZIP包解压到~/Library/Android/sdkmacOS或C:\Users\XXX\AppData\Local\Android\SdkWindows将cmdline-tools/latest/bin加入PATH运行sdkmanager --list_installed确认基础环境逐个安装必需包sdkmanager platform-tools platforms;android-33 build-tools;33.0.2。注意sdkmanager命令首次运行会报错ERROR: JAVA_HOME is set to an invalid directory这不是Java问题而是cmdline-tools目录结构问题——必须先创建latest子目录并将bin、lib等文件移入其中否则sdkmanager找不到自身jar包。这是Android官方文档都没写的坑。2.4 Appium Server从全局安装到按需驱动的演进Appium 2.x与1.x的本质区别在于插件化架构。1.x是单体应用所有功能iOS/Android/Windows驱动打包在一起2.x则像Linux内核核心Server只处理HTTP协议和会话管理具体设备操作由独立插件Driver实现。这意味着安装Appium Server不再等于安装全部功能appium命令本身不包含Android驱动必须额外安装appium-uiautomator2-driver驱动可单独升级不影响Server核心。安装步骤必须分两步全局安装Appium Servernpm install -g appium2.4.0指定版本避免自动升级到不稳定版按需安装驱动appium driver install uiautomator2自动下载并注册U2驱动。验证是否成功不能只看appium -v必须执行appium driver list # 应显示 uiautomator2 | installed | v4.22.0 appium server list # 应显示 default | running | v2.4.0关键配置项--allow-insecure和--relaxed-security常被滥用。--allow-insecure用于启用非标准端点如/session/:id/log而--relaxed-security则关闭所有安全校验包括--allow-insecure的白名单。生产环境严禁使用后者否则任何局域网设备都能向你的Appium Server发送指令。正确做法是开发阶段用--allow-insecureadb_shell,logcat精确开放所需端点测试完成后删除该参数。3. 环境搭建全流程实操与避坑指南3.1 分步实操从零开始搭建可验证的Appium环境以下流程经20台不同配置机器实测耗时控制在15分钟内。所有命令均标注执行路径和预期输出便于逐行核对。第一步安装JDK 17macOS示例# 1. 清理旧JDK避免PATH污染 sudo rm -rf /Library/Java/JavaVirtualMachines/jdk-*.jdk # 2. 使用Homebrew安装OpenJDK 17 brew install openjdk17 # 3. 创建标准符号链接关键 sudo ln -sfn /opt/homebrew/opt/openjdk17/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-17.jdk # 4. 配置环境变量写入~/.zshrc echo export JAVA_HOME$(/usr/libexec/java_home -v 17) ~/.zshrc echo export PATH$JAVA_HOME/bin:$PATH ~/.zshrc source ~/.zshrc # 5. 验证必须同时通过三项 java -version # 输出应含 17.0.1 和 Homebrew javac -version # 输出同上 echo $JAVA_HOME # 输出 /Library/Java/JavaVirtualMachines/openjdk-17.jdk/Contents/Home实测心得/usr/libexec/java_home -v 17比硬编码路径更可靠因Homebrew可能变更安装路径echo $JAVA_HOME必须无空格否则Appium启动时报Error: Could not find or load main class io.appium.java_client.remote.AppiumCommandExecutor。第二步安装Android SDK命令行方式# 1. 创建SDK根目录 mkdir -p ~/Library/Android/sdk # 2. 下载并解压Command-line Tools官网ZIP非DMG # 解压后得到 cmdline-tools 目录进入并创建 latest 子目录 cd ~/Library/Android/sdk/cmdline-tools mkdir -p latest mv bin lib NOTICE.txt latest/ # 3. 将 latest/bin 加入PATH写入~/.zshrc echo export ANDROID_HOME$HOME/Library/Android/sdk ~/.zshrc echo export PATH$ANDROID_HOME/cmdline-tools/latest/bin:$PATH ~/.zshrc source ~/.zshrc # 4. 接受所有许可证关键否则后续安装失败 sdkmanager --licenses # 5. 安装三大核心包耗时约3分钟 sdkmanager platform-tools platforms;android-33 build-tools;33.0.2 # 6. 验证安装 adb version # 输出 Android Debug Bridge version 33.0.3 aapt version # 输出 Android Asset Packaging Tool, v0.2-7122501 sdkmanager --list_installed | grep -E (platform-tools|android-33|build-tools) # 应显示三行注意sdkmanager --licenses必须手动输入y接受所有条款不能跳过aapt version若报错说明build-tools未正确安装需重新运行sdkmanager build-tools;33.0.2。第三步安装Appium Server及U2驱动# 1. 确保Node.js ≥ 16.17.0Appium 2.4.0最低要求 node -v # 必须 ≥ v16.17.0 # 2. 全局安装Appium Server指定版本 npm install -g appium2.4.0 # 3. 安装UiAutomator2驱动自动下载APK并注册 appium driver install uiautomator2 # 4. 启动Appium Server后台运行便于后续调试 appium --allow-insecureadb_shell,logcat --relaxed-security # 5. 验证服务状态 curl -X GET http://127.0.0.1:4723/status | python -m json.tool # 应返回 ready: true实操技巧appium --allow-insecure...参数必须放在之前否则后台进程无法继承参数curl验证比appium server list更直接因后者只查进程不验证HTTP服务是否真正响应。第四步连接真机并验证ADB通路# 1. 开启手机开发者选项连续点击关于手机中版本号7次 # 2. 开启USB调试和USB安装部分品牌需额外开启 # 3. 用USB线连接电脑执行 adb devices # 应显示 XXXXXX device非 ?????????? no permissions # 4. 若显示 no permissions执行macOS/Linux sudo adb kill-server sudo adb start-server adb devices # 再次检查 # 5. 测试ADB基础功能 adb shell getprop ro.build.version.release # 应输出 13 或 14 adb shell pm list packages | grep android # 应列出系统包关键避坑华为/小米手机需在开发者选项中额外开启“仅充电模式下允许ADB调试”否则adb devices始终显示no permissionsadb shell getprop必须返回数字若返回空字符串说明ADB版本与设备不兼容需升级platform-tools。3.2 Appium Inspector元素定位的“显微镜”不是可有可无的玩具Appium Inspector是Appium官方提供的GUI工具作用是实时查看APP界面树Accessibility Tree并生成定位代码。它不是Appium Server的一部分而是独立应用但依赖Appium Server提供会话服务。安装与配置要点下载地址必须从 Appium GitHub Releases 下载最新版如v2023.12.1切勿使用旧版Appium Desktop因其内置的Appium Server版本过旧启动方式双击安装包后首次运行需配置Appium Server地址——Remote URL填http://127.0.0.1:4723/wd/hubPlatform Name选AndroidDevice Name填emulator-5554模拟器或XXXXXX真机序列号核心配置项appPackage被测APP的包名可通过aapt dump badging your_app.apk | grep package获取appActivityAPP的启动Activity通常为MainActivity但需确认可通过aapt dump badging your_app.apk | grep launchable-activity获取automationName必须设为UiAutomator2否则Inspector无法连接。常见失败场景及解决错误An unknown server-side error occurred while processing the command. Original error: Could not find adb原因Inspector找不到adb因ANDROID_HOME未在GUI环境中生效。解决方案在终端中启动Inspector——open -a Appium InspectormacOS确保终端已加载~/.zshrc中的环境变量。错误An unknown server-side error occurred while processing the command. Original error: Cannot verify the signature of /data/local/tmp/appium-uiautomator2-server-debug-androidTest.apk原因U2 Server APK签名与设备不匹配。解决方案卸载旧版U2 Serveradb uninstall io.appium.uiautomator2.server再重启Inspector它会自动重装签名正确的APK。Inspector卡在“Loading…”原因设备未开启“USB调试”或adb未授权。解决方案拔插USB线在手机弹出“允许USB调试吗”对话框时勾选“始终允许”再点确定。实操心得Inspector的“Selector”面板是核心。点击任意UI元素右侧自动生成多种定位方式id、xpath、accessibility id。优先使用id即resource-id因其最稳定xpath慎用尤其含索引的//android.widget.Button[1]一旦界面元素顺序变化即失效accessibility id需APP开发者提前设置content-desc属性是无障碍测试的黄金标准。3.3 第一个Python脚本从“Hello World”到真实业务场景脚本编写不是复制粘贴而是理解WebDriver协议的三次握手。以下脚本以微信登录页为例展示从环境准备到元素操作的全链路# test_wechat_login.py from appium import webdriver from appium.options.android import UiAutomator2Options import time # 1. 配置Desired Capabilities必须与Inspector中一致 options UiAutomator2Options() options.platform_name Android options.device_name SM-G998U1 # 替换为你的设备序列号 options.app_package com.tencent.mm # 微信包名 options.app_activity .ui.LauncherUI # 微信启动Activity options.no_reset True # 不重置APP状态保留登录态 options.automation_name UiAutomator2 # 2. 连接Appium Server地址必须与appium启动时一致 driver webdriver.Remote(http://127.0.0.1:4723, optionsoptions) try: # 3. 等待首页加载完成显式等待比time.sleep更可靠 # 等待“微信”文字出现用accessibility id因微信设置了content-desc wechat_text driver.find_element(accessibility id, 微信) print(微信首页已加载) # 4. 点击“我”标签页用resource-id最稳定 my_tab driver.find_element(id, com.tencent.mm:id/cn4) # 实际ID需用Inspector获取 my_tab.click() # 5. 点击“登录”按钮用xpath因ID动态变化 login_btn driver.find_element(xpath, //android.widget.Button[text登录]) login_btn.click() # 6. 输入手机号用id定位输入框 phone_input driver.find_element(id, com.tencent.mm:id/bq_) # 实际ID需Inspector确认 phone_input.send_keys(13800138000) # 7. 截图保存调试必备 driver.save_screenshot(wechat_login_step1.png) finally: # 8. 清理资源 driver.quit()关键细节解析UiAutomator2Options()替代旧版DesiredCapabilitiesAppium 2.x强制使用类型化选项类find_element()方法签名也变为find_element(by, value)更符合Selenium 4规范no_resetTrue避免每次运行脚本都清除APP数据节省时间。但首次运行必须设为False让Appium自动安装APPfind_element()的By策略id对应resource-idaccessibility id对应content-descxpath是最后选择。微信的resource-id常含随机字符如bq_需用Inspector实时抓取不可硬编码save_screenshot()截图文件名必须含.png后缀否则保存失败路径为相对路径脚本所在目录。运行前必做三件事确保Appium Server正在运行ps aux | grep appium确保设备已连接且adb devices显示在线确保被测APP已安装到设备adb install your_app.apk。运行命令python test_wechat_login.py。首次运行会自动安装微信APK若未安装耗时约30秒后续运行直接启动5秒内完成。实操心得脚本失败时第一反应不是改代码而是看Appium Server日志。启动Server时加--log-level debug参数appium --log-level debug日志中会清晰显示“Received POST /session”、“Executing ‘findElement’ with args”、“Sending adb command: shell input tap”等链条比Python报错更早暴露问题。例如日志中出现Error: Could not find element说明定位器错误若出现Error: Unable to resolve appActivity则是appActivity配置错误。4. 常见故障排查与独家避坑技巧4.1 环境验证速查表5分钟定位问题根源当Appium脚本无法运行时按此表顺序排查90%的问题可在5分钟内定位检查项执行命令正常输出特征常见异常及修复JDK可用性java -version javac -version echo $JAVA_HOME三行输出均含17.0.x$JAVA_HOME路径无空格输出含1.8.0或21.0.x→ 重装JDK 17$JAVA_HOME为空 → 检查~/.zshrc中export语句ADB连通性adb devices adb shell getprop ro.build.version.releasedevices显示XXXXXX devicegetprop返回13或14显示no permissions→ 在手机开发者选项中开启“USB调试”并勾选“始终允许”返回空 → 升级platform-toolsAppium Server状态curl -s http://127.0.0.1:4723/status | grep -o ready:true输出ready:true返回空或404→ 检查appium进程是否运行端口是否被占用lsof -i :4723U2驱动注册appium driver list | grep uiautomator2输出含uiautomator2 | installed | v4.22.0无输出 → 运行appium driver install uiautomator2APP包信息aapt dump badging your_app.apk | grep -E (packagelaunchable-activity)package: namecom.xxx.app和launchable-activity: name.MainActivity提示将此表存为check_env.sh脚本一键执行bash check_env.sh | tee env_report.log日志可直接发给同事协助排查。4.2 典型故障深度解析与根治方案故障一An unknown server-side error occurred while processing the command. Original error: Could not find adb表面看是ADB路径问题但深层原因有三层表层ANDROID_HOME未正确设置或PATH中adb路径在系统/usr/bin之后中层Appium Server以不同用户身份运行如通过LaunchDaemon启动未继承当前Shell的环境变量深层adb二进制文件权限不足常见于从ZIP解压的platform-tools。根治方案终止所有Appium进程pkill -f appium修复adb权限chmod x $ANDROID_HOME/platform-tools/adb强制Appium使用绝对路径启动时指定--adb-path $ANDROID_HOME/platform-tools/adb避免GUI启动始终在终端中运行appium确保环境变量生效。故障二An unknown server-side error occurred while processing the command. Original error: Cannot verify the signature of /data/local/tmp/appium-uiautomator2-server-debug-androidTest.apk这是U2 Server APK签名与设备不匹配的典型错误。U2 Server APK由Appium自动下载但不同版本的APK签名密钥不同。当设备已安装旧版U2 Server时新APK因签名不一致被系统拒绝安装。根治方案三步清零法卸载所有U2相关APKadb uninstall io.appium.uiautomator2.server adb uninstall io.appium.uiautomator2.server.test清理设备端临时文件adb shell rm -rf /data/local/tmp/appium*重启Appium Server并重新运行脚本U2驱动会自动重装签名正确的APK。故障三脚本中find_element()超时但Inspector能正常定位这表明Appium Server与设备通信正常但元素查找逻辑有误。常见原因页面未加载完成脚本执行太快UI尚未渲染。解决方案用显式等待替代time.sleep()from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from appium.webdriver.common.appiumby import AppiumBy wait WebDriverWait(driver, 10) # 最大等待10秒 element wait.until(EC.presence_of_element_located((AppiumBy.ID, com.xxx:id/button)))WebView上下文切换APP内嵌H5页面时需先切换到WebView上下文contexts driver.contexts driver.switch_to.context(contexts[-1]) # 切换到最后一个WebView # 此时可用Chrome DevTools调试元素在滚动区域外列表项需先滑动到可视区域。解决方案用UiScrollableAPIdriver.find_element(android uiautomator, new UiScrollable(new UiSelector().scrollable(true).instance(0)) .scrollIntoView(new UiSelector().text(目标文本).instance(0));)4.3 生产环境加固技巧从“能跑”到“稳跑”在CI/CD流水线中Appium环境必须具备可重复性、可观测性和容错性。以下是我在多个金融、电商项目中验证过的加固方案1. 版本锁定与Docker化避免“本地能跑CI上失败”。将环境固化为Docker镜像FROM node:16.17-slim # 安装JDK 17 RUN apt-get update apt-get install -y openjdk-17-jdk rm -rf /var/lib/apt/lists/* ENV JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64 # 安装Android SDK RUN mkdir -p /opt/android-sdk cd /opt/android-sdk \ wget https://dl.google.com/android/repository/commandlinetools-linux-9477386_latest.zip \ unzip commandlinetools-linux-9477386_latest.zip -d cmdline-tools \ mkdir -p cmdline-tools/latest mv cmdline-tools/bin cmdline-tools/lib cmdline-tools/NOTICE.txt cmdline-tools/latest/ ENV ANDROID_HOME/opt/android-sdk ENV PATH$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools # 安装必需SDK包 RUN yes | sdkmanager --licenses \ sdkmanager platform-tools platforms;android-33 build-tools;33.0.2 # 安装Appium RUN npm install -g appium2.4.0 appium driver install uiautomator2构建命令docker build -t appium-ci .CI中直接运行docker run --rm -v $(pwd):/workspace appium-ci python /workspace/test.py。2. 设备管理自动化真机池管理是痛点。用adb脚本自动维护设备状态#!/bin/bash # health_check.sh for device in $(adb devices | grep device | awk {print $1}); do echo 检查设备 $device # 重启ADB服务 adb -s $device kill-server adb -s $device start-server # 检查是否响应 if ! adb -s $device shell getprop ro.build.version.release /dev/null 21; then echo 设备 $device 无响应重启中... adb -s $device reboot fi done每日定时任务执行0