原生 AOSP 不需要
国内魔改系统就难说了

adb shell settings put global package_verifier_enable 0

自己先找一些自己实际遇到的图片,做些训练
然后再识别看看

configparser 是 python3 的
你确定 jenkins 用的和你手动用的是同一个 python?

把错误堆栈打出来,一级级往下看是哪里出的空指针

家里没法看源码,明天可以看看怎么 import
另外又想到一个 api
swipe(Point[] segments, int segmentSteps)
设 3 个点,第一个第二个用来拖拽到目标位置,第三个点可以横向拖

换一种思路,在点了第一张图之后,用 key 来移动,比如 pressDown 之类的

重写不代表你要替换 jar 包里原来的功能,你可以自己写一个 draghold 方法,你只要能调用 touchMove/Down/Up 就行,仿照原来的写法

先看是不是 webview,有些 APP 用了自己的 view,而不是标准 webview,所以 appium 对这种情况无能为力

一种,你可以用 flingForward() 代替 drag,不过你的控件必须是 UiScrollable 的
另一种,重写 swipe
extras\android\m2repository\com\android\support\test\uiautomator\uiautomator-v18\2.1.2\uiautomator-v18-2.1.2-sources.jar!\android\support\test\uiautomator\InteractionController.java

public boolean swipe(int downX, int downY, int upX, int upY, int steps, boolean drag) {
    boolean ret = false;
    int swipeSteps = steps;
    double xStep = 0;
    double yStep = 0;

    // avoid a divide by zero
    if(swipeSteps == 0)
        swipeSteps = 1;

    xStep = ((double)(upX - downX)) / swipeSteps;
    yStep = ((double)(upY - downY)) / swipeSteps;

    // first touch starts exactly at the point requested
    ret = touchDown(downX, downY);
    if (drag)
        SystemClock.sleep(mUiAutomatorBridge.getSystemLongPressTime());
    for(int i = 1; i < swipeSteps; i++) {
        ret &= touchMove(downX + (int)(xStep * i), downY + (int)(yStep * i));
        if(ret == false)
            break;
        // set some known constant delay between steps as without it this
        // become completely dependent on the speed of the system and results
        // may vary on different devices. This guarantees at minimum we have
        // a preset delay.
        SystemClock.sleep(MOTION_EVENT_INJECTION_DELAY_MILLIS);
    }
    if (drag)
        SystemClock.sleep(REGULAR_CLICK_LENGTH);
    ret &= touchUp(upX, upY);
    return(ret);
}

把 SystemClock.sleep(REGULAR_CLICK_LENGTH);这一行的 REGULAR_CLICK_LENGTH 改成 mUiAutomatorBridge.getSystemLongPressTime()

第二种我没试过,仅仅理论上可行

看代码,用了 popen.commiucate,所以肯定是跑完了才会跑下一个命令

shell=True -> shell=False 呢? 其实你也不会运行 cmd 里的自带命令吧
另外还是推荐 subprocess 的命令用列表的方式传进去,避免一些转义的问题

另外错误 log 不足啊
不是 sc.Error("cannot create file/directory '%s': %s", dst, strerror(errno));么
后面的 strerror(errno) 是几呢

虽说 python 是支持在 windows 用 / 作为路径分隔符,但是 c++ 未必,所以推荐在 windows 还是老老实实用 \ 吧

另,adb 的 wrapper 真是好多个人写....
https://github.com/264768502/adb_wrapper

adb shell settings put global package_verifier_enable 0
adb shell settings put global verifier_verify_adb_installs 0

pytesseract

系统版本? 4.2 以上才行
拿 takeScreenshot 的返回值看看是 true 还是 false

至少标准的安卓系统是不会阻止直接启动某个 Activity 的
但是国内这些魔改版就很难说了,就像你遇到的那样.

自动化的目标不一样
比如如果只是测遍历元素,用用 monkey 也能成
但是要测逻辑/行为,遍历就不行了
我不认为 testin 有办法逃出比图的套路

要么让他们改代码,让这个 view 继承自 webview
要不只能玩比图了http://tmq.qq.com/2017/02/test_guide/

谁告诉你 Appium 只能定位原生控件的?
能支持 webview 也算是它的一大卖点
https://testerhome.com/topics/2987

理论上,从系统上来说不需要,起 activity 不需要目标 app 已启动,除非目标 APP 自己设了限制
如果可以的话,看看 logcat,看看启动后 logcat 是否有显示目标 app 的相关打印来确定问题
另外,adb shell am start XXX 如果也启动不了,可以看看打印是什么

直接调用 API 去起不行么?非要用 shell
Context context = InstrumentationRegistry.getInstrumentation().getContext();
Intent intent = context.getPackageManager().getLaunchIntentForPackage(appPackageName);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK);
context.startActivity(intent);

用 UiWatcher

和 appium 用同一个同路径的 adb.exe

其实没特殊需求的话,直接在手机里运行你的命令 (uiautomator2 的 executeShellCommand) 然后再 pull 出来

用堆栈

语言?操作系统?平台?