自动化工具 给 adb 加上全局的设备锁

williamfzc · April 10, 2019 · Last by williamfzc replied at April 11, 2019 · 868 hits

项目地址

目标

首先解释一下为什么会有这个需求:

在全自动化管理中,对于adb的依赖程度是非常高的。然而,一般来说我们将设备管理逻辑放在比较高的层级来解决:

  • 应用
    • 具体业务
    • 设备管理
  • adb
  • 设备

但显而易见的,由应用来管控adb命令实际上是非常软性的(很可能会因为疏忽而影响到其他设备),并没有硬性隔离设备。软件操作的边界不明显将很容易导致管理的越界与混乱。在jenkins构建中官方推荐用 lockable resource 来管理资源而不是流水线中用代码进行管理已经说明了很多问题。

然而在日常开发中,使用场景远不局限于jenkins。那么,有没有一种更加通用的方案?答案就是lockadb

像adb一样操作

在命令行中,直接用 ladb 替代 adb 。

lockadb是adb的超集,保留了所有的adb功能。理论上所有adb支持的功能都可以无缝切换到ladb。

防冲突机制

lockadb最关键的特性就是从adb层面避免了设备操作冲突。

连入一个设备123456F,我们先让该设备忙碌20秒:

ladb -s 123456F shell sleep 20

这样做之后,该设备将被标记为BUSY状态。此时你如果想操作它是被禁止的:

ladb -s 123456F shell echo hello

Traceback (most recent call last):
File "C:\Python37\Scripts\ladb-script.py", line 11, in <module>
load_entry_point('lockadb', 'console_scripts', 'ladb')()
File "f:\lockadb\lockadb\client.py", line 106, in main
LockAdbRunner.run(command)
File "f:\lockadb\lockadb\client.py", line 95, in run
with lock_device(device_id):
File "c:\python37\lib\contextlib.py", line 112, in __enter__
return next(self.gen)
File "f:\lockadb\lockadb\client.py", line 39, in lock_device
assert acquire_device(device_id), 'device {} is busy'.format(device_id)
AssertionError: device 123456F is busy

主动锁定

除了自动模式,你也可以手动给设备加锁,更加自由地管理设备。

# 上锁
ladb acquire 123456F
# 解锁
ladb release 123456F

在你上锁之后,除了主动释放设备,该设备将一直保持在BUSY状态。

python API

除了命令行的模式,你也可以直接调用python API来管理设备。

from lockadb.client import LockAdbRunner, acquire_device, release_device


DEVICE_ID = '123456F'

acquire_result = acquire_device(DEVICE_ID)
print('acquire result is: {}'.format(acquire_result))
LockAdbRunner.run(['devices'])

# ...

release_result = release_device(DEVICE_ID)
print('release result is: {}'.format(release_result))
LockAdbRunner.run(['devices'])

设计

使用C/S架构,S端启动常驻服务器用于设备的管理,通过API提供给C端使用。

提供两种形式的CLI用法:

  • 命令行CLI
  • python API

Bug与建议

这个项目是一个个人想法的实践,不一定是最好的解决方案。欢迎交流 :)

共收到 2 条回复 时间 点赞

我建议是如果已经在work的手机 在数据库或者文件里面加1个状态标记,执行完释放了adb才修改回状态。
链接得时候,先遍历手机池子里 符合状态的手机。

陈子昂 回复

😹 对呀 现在确实是这么设计的

至于为什么用服务器而不是文件与数据库,我的理由是设备状态是个时效性比较强的东西,并不是很有必要进行持久化保存。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up