从WEB 端批量移动设备管理控制工具 STF 的环境搭建和运行文章了解到STF这个工具,然后试用了一下。最近在做一个测试工具,发现Android原生的截图工具截图非常缓慢,然后想起了stf工具中截图非常快,甚至连执行monkey的动作都能在web端查看,这就很爽了,所以在github上提了一个Issue,询问这个是如何实现的,很快得到答复,stf自己写了一个工具叫minicap用来替代原生的screencap,这个工具是stf框架的依赖工具。
minicap使用
minicap工具是用NDK开发的,属于Android的底层开发,该工具分为两个部分,一个是动态连接库.so文件,一个是minicap可执行文件。但不是通用的,因为CPU架构的不同分为不同的版本文件,STF提供的minicap文件根据CPU 的ABI分为如下4种:
从上面可以看出,minicap可执行文件分为4种,分别针对arm64-v8a
、armeabi-v7a
,x86
,x86_64
架构。而minicap.so文件在这个基础上还要分为不同的sdk版本。
获取设备的CPU版本和系统版本
CPU版本
adb shell getprop ro.product.cpu.abi | tr -d '\r'
58deMacBook-Pro:minicap wuxian$ adb shell getprop ro.product.cpu.abi | tr -d '\r'
armeabi-v7a
- 1
- 2
系统版本
adb shell getprop ro.build.version.sdk | tr -d '\r'
58deMacBook-Pro:minicap wuxian$ adb shell getprop ro.build.version.sdk | tr -d '\r'
22
- 1
- 2
将文件push到手机
根据上面获取的信息,将适合设备的可执行文件和.so文件push到手机的/data/local/tmp
目录下,如果你不想自己build这些文件可以去STF框架的源码下找到vendor/minicap文件夹下找到这些文件,我上面的tree信息就是我在stf根目录vendor/minicap下打印的,所以我们将这两个文件导入到我手机的/data/local/tmp目录下:
shell@shamu:/data/local/tmp $ ls -l
-rw-rw-r-- shell shell 1053609 2015-08-07 19:19 1.png
-rwxr-xr-x shell shell 1062992 2015-08-03 12:02 busybox
-rwxr-xr-x shell shell 358336 2015-08-03 12:02 busybox1
drwxrwxrwx shell shell 2015-07-21 15:16 dalvik-cache
-rw-r--r-- shell shell 193 2015-08-13 19:44 krperm.txt
-rwxrwxrwx shell shell 370424 2015-08-07 18:16 minicap
-rw-rw-rw- shell shell 13492 2015-08-07 18:26 minicap.so
-rw------- shell shell 11192 2015-08-06 10:46 ui.xml
-rw------- shell shell 2501 2015-08-07 10:36 uidump.xml
启动工具
首先我们测试一下我们的minicap工具是否可用,命令如下(其中-P后面跟的参数为你屏幕的尺寸,你可以修改成你自己设备的尺寸):
adb shell LD_LIBRARY_PATH=/data/local/tmp /data/local/tmp/minicap -P 1440x2560@1440x2560/0 -t
最后输出OK就表明minicap可用:
58deMacBook-Pro:minicap wuxian$ adb shell LD_LIBRARY_PATH=/data/local/tmp /data/local/tmp/minicap -P 1440x2560@1440x2560/0 -t
PID: 7105
INFO: Using projection 1440x2560@1440x2560/0
INFO: (external/MY_minicap/src/minicap_22.cpp:240) Creating SurfaceComposerClient
INFO: (external/MY_minicap/src/minicap_22.cpp:243) Performing SurfaceComposerClient init check
INFO: (external/MY_minicap/src/minicap_22.cpp:250) Creating virtual display
INFO: (external/MY_minicap/src/minicap_22.cpp:256) Creating buffer queue
INFO: (external/MY_minicap/src/minicap_22.cpp:261) Creating CPU consumer
INFO: (external/MY_minicap/src/minicap_22.cpp:265) Creating frame waiter
INFO: (external/MY_minicap/src/minicap_22.cpp:269) Publishing virtual display
INFO: (jni/minicap/JpgEncoder.cpp:64) Allocating 11061252 bytes for JPG encoder
INFO: (external/MY_minicap/src/minicap_22.cpp:284) Destroying virtual display
OK
然后我们启动minicap工具,命令如下(就比上面的检测工具少了个-t): adb shell LD_LIBRARY_PATH=/data/local/tmp /data/local/tmp/minicap -P 1440x2560@1440x2560/0
本地端口转发
上面其实是启动了一个socket服务器,我们需要跟该socket服务通信,首先我们要将本地的端口映射到minicap工具上,端口自己随意:
adb forward tcp:1717 localabstract:minicap
获取信息
然后使用命令nc localhost 1717
来与minicap
通信,然后你会发现好多乱码。
效果
上面的乱码我们也看不懂,官方提供了一个demo来看效果,在minicap项目下的example目录,我们来启动该例子:
58deMacBook-Pro:example wuxian$ PORT=9002 node app.js
Listening on port 9002