如何对Android设备执行器（Actuator）进行可靠测试？

Android设备上的执行器（Actuator）泛指那些能够把电信号转化为物理动作或状态变化的硬件组件，比如振动马达、闪光灯、扬声器、通知LED、摄像头对焦马达等。执行器测试的核心难点在于硬件状态难以被软件完全观测，而且同样的API调用在真机和模拟器上的表现差异极大。一个典型的例子是Vibrator.vibrate()调用在代码层面不会抛出任何异常，但实际振动马达可能因为驱动故障、权限未授予或者设备处于免打扰模式而没有产生任何触觉反馈。因此仅仅依赖单元测试断言方法调用成功远远不够，需要结合硬件状态验证、仪器测试和adb命令进行多层覆盖。

一、执行器测试的对象与常见挑战

Android系统通过不同的Manager类向外提供执行器控制接口。常见的有Vibrator用于控制振动马达，CameraManager用于控制摄像头闪光灯，AudioManager用于控制扬声器音量与音频输出，NotificationManager用于控制通知LED灯。每一种执行器都有独立的硬件抽象层驱动，上层API调用最终会经过Binder通信到达系统服务，再由系统服务下发指令到HAL层。这个链路中任意一环出现异常，都可能导致执行器不工作，而应用层只能通过有限的状态回调或返回值来间接判断。

执行器测试面临的挑战主要有四个方面。第一是权限依赖，例如控制闪光灯需要CAMERA权限，控制振动需要VIBRATE权限，测试代码必须正确声明权限并且在运行时动态申请。第二是异步性，很多执行器指令是异步执行的，比如振动开始后会持续一段时间，测试需要等待状态切换完成再断言。第三是资源释放，执行器使用完毕后需要及时关闭或取消，否则会影响后续测试用例甚至导致电池消耗。第四是环境差异，模拟器通常不支持真实振动、闪光灯或LED控制，测试代码在模拟器上运行时会得到空实现或静默失败。

二、使用adb命令快速验证执行器状态

在编写自动化测试之前，通过adb命令直接控制执行器是一种快速有效的验证手段。adb shell提供了多个命令可以绕过应用层直接驱动硬件，适合排查驱动和HAL层问题。下列命令演示了如何控制振动马达、闪光灯和音频输出：

# 让设备振动500毫秒
adb shell cmd vibrator vibrate 500

# 取消当前振动
adb shell cmd vibrator cancel

# 打开手电筒闪光灯
adb shell cmd flashlight on

# 关闭手电筒闪光灯
adb shell cmd flashlight off

# 设置媒体音量为50%
adb shell media volume --set 15

# 播放一段测试音频以验证扬声器
adb shell cmd audio play /system/media/audio/ringtones/ringtone.mp3

上述命令的执行结果会直接反映在设备物理状态上。如果震动没有发生但命令没有报错，说明问题可能出现在硬件驱动或者省电策略上；如果闪光灯命令执行成功但灯不亮，则需要检查摄像头模组排线或系统灯光服务。在CI环境中，可以预先通过adb命令检测设备是否具备相应执行器，例如使用adb shell dumpsys vibrator查看振动服务状态，使用adb shell dumpsys media.audio_flinger检查音频输出通道。

需要注意的是cmd flashlight命令在部分Android版本上可能不可用，这时可以使用cmd camera相关命令替代。同时adb命令测试通常不具备断言能力，只能作为人工排查或Shell脚本中的基础检查，真正的自动化验证仍需依赖仪器测试。

三、编写仪器测试用例驱动执行器

仪器测试（Instrumented Test）运行在真机或模拟器上，可以直接访问Android框架API并检查执行器状态。下面给出一个基于JUnit的振动器测试用例，验证振动马达能够启动和取消：

import android.content.Context;
import android.os.Vibrator;
import androidx.test.platform.app.InstrumentationRegistry;
import androidx.test.ext.junit.runners.AndroidJUnit4;
import org.junit.Test;
import org.junit.runner.RunWith;
import static org.junit.Assert.assertTrue;

@RunWith(AndroidJUnit4.class)
public class VibratorTest {

    @Test
    public void testVibratorStartsAndCancels() {
        Context context = InstrumentationRegistry.getInstrumentation().getTargetContext();
        Vibrator vibrator = (Vibrator) context.getSystemService(Context.VIBRATOR_SERVICE);
        if (vibrator == null || !vibrator.hasVibrator()) {
            return; // 设备不具备振动能力时跳过
        }
        long[] pattern = {0, 300, 100, 300};
        vibrator.vibrate(pattern, -1);
        // 等待振动开始
        try {
            Thread.sleep(200);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        // 查询振动是否处于活动状态（不同API级别方法不同）
        // 在API 29及以上可以使用vibrator.areEffectsSupported检查效果支持
        assertTrue(vibrator.hasVibrator());
        vibrator.cancel();
    }
}

对于闪光灯测试，可以使用CameraManager的setTorchMode方法。该方法是异步的，需要通过CameraManager.TorchCallback监听状态变化。下面的代码展示了如何打开闪光灯并验证回调被触发：

import android.content.Context;
import android.hardware.camera2.CameraManager;
import android.hardware.camera2.CameraCharacteristics;
import androidx.test.platform.app.InstrumentationRegistry;
import androidx.test.ext.junit.runners.AndroidJUnit4;
import org.junit.Test;
import org.junit.runner.RunWith;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import static org.junit.Assert.assertTrue;

@RunWith(AndroidJUnit4.class)
public class FlashlightTest {

    @Test
    public void testFlashlightTurnsOn() throws Exception {
        Context context = InstrumentationRegistry.getInstrumentation().getTargetContext();
        CameraManager cameraManager = (CameraManager) context.getSystemService(Context.CAMERA_SERVICE);
        String cameraId = null;
        for (String id : cameraManager.getCameraIdList()) {
            CameraCharacteristics characteristics = cameraManager.getCameraCharacteristics(id);
            Boolean hasFlash = characteristics.get(CameraCharacteristics.FLASH_INFO_AVAILABLE);
            if (hasFlash != null && hasFlash) {
                cameraId = id;
                break;
            }
        }
        if (cameraId == null) {
            return;
        }
        final CountDownLatch latch = new CountDownLatch(1);
        CameraManager.TorchCallback callback = new CameraManager.TorchCallback() {
            @Override
            public void onTorchModeChanged(String cameraId, boolean enabled) {
                if (enabled) {
                    latch.countDown();
                }
            }
        };
        cameraManager.registerTorchCallback(callback, null);
        cameraManager.setTorchMode(cameraId, true);
        boolean success = latch.await(2, TimeUnit.SECONDS);
        cameraManager.setTorchMode(cameraId, false);
        cameraManager.unregisterTorchCallback(callback);
        assertTrue("闪光灯未能在超时时间内点亮", success);
    }
}

音频执行器测试相对复杂一些，因为扬声器输出无法用简单的布尔状态来表示。可以使用AudioManager检查音频输出设备类型，或者播放一段固定频率的音频并通过麦克风采集分析。不过在基本的仪器测试中，通过AudioTrack写入数据并确认无异常即可验证音频通道通畅。同时应关注音频焦点申请和释放，避免测试结束后影响其他应用。

四、模拟器限制与CI环境中的执行器测试策略

Android模拟器对执行器的支持非常有限。官方模拟器通常没有真实的振动马达、闪光灯和通知LED，调用相关API会返回空操作或模拟状态。例如在模拟器上调用Vibrator.hasVibrator()可能返回false，而CameraManager.setTorchMode可能直接抛出IllegalArgumentException。因此执行器测试应当优先运行在真机上，模拟器只能用于验证代码逻辑不崩溃，不能作为硬件功能验证的依据。

在持续集成环境中，可以使用Firebase Test Lab或自建的真机测试集群来运行仪器测试。测试代码中需要加入能力探测逻辑，当设备不具备某项硬件能力时自动跳过相关用例，避免误报失败。此外可以利用Robolectric在JVM上模拟部分执行器的影子对象，进行快速单元测试，但这类测试无法验证真实硬件行为，只能用于逻辑覆盖。对于需要真实硬件反馈的场景，可以部署硬件在环测试方案，通过外部传感器或摄像头捕捉振动、闪光灯亮灭等物理状态，再与测试指令进行比对。

综合来看，Android执行器测试应遵循分层策略：单元测试覆盖状态管理逻辑，仪器测试覆盖API调用和状态回调，adb命令用于快速回归和故障定位，真机硬件在环测试负责最终的功能验收。只有在每一层都设置合理的断言和超时机制，才能避免执行器故障泄漏到生产环境。

Android执行器测试硬件测试自动化测试修改时间：2026-08-22 10:43:11