上面的 issue,附上测试机型:
Hi,作者:
我想问下这个 framework.jar 的作用是啥呢?为啥我 push framework.jar 和 monkey.jar 到手机后启动,然后同时抓取 logcat 的输出,发现系统在处理这个 framework.jar 时抛出了异常,这个应该没有起作用吧。下面是 logcat 中的输出:
01-14 16:43:21.256 E/System (31646): Unable to open zip file: /sdcard/framework.jar
01-14 16:43:21.258 E/System (31646): java.util.zip.ZipException: error in opening zip file
01-14 16:43:21.258 E/System (31646): at java.util.zip.ZipFile.open(Native Method)
01-14 16:43:21.258 E/System (31646): at java.util.zip.ZipFile.<init>(ZipFile.java:225)
01-14 16:43:21.258 E/System (31646): at java.util.zip.ZipFile.<init>(ZipFile.java:148)
01-14 16:43:21.258 E/System (31646): at java.util.jar.JarFile.<init>(JarFile.java:161)
01-14 16:43:21.258 E/System (31646): at java.util.jar.JarFile.<init>(JarFile.java:98)
01-14 16:43:21.258 E/System (31646): at libcore.io.ClassPathURLStreamHandler.<init>(ClassPathURLStreamHandler.java:47)
01-14 16:43:21.258 E/System (31646): at dalvik.system.DexPathList$Element.maybeInit(DexPathList.java:532)
01-14 16:43:21.258 E/System (31646): at dalvik.system.DexPathList$Element.findResource(DexPathList.java:568)
01-14 16:43:21.258 E/System (31646): at dalvik.system.DexPathList.findResource(DexPathList.java:440)
01-14 16:43:21.258 E/System (31646): at dalvik.system.BaseDexClassLoader.findResource(BaseDexClassLoader.java:74)
01-14 16:43:21.258 E/System (31646): at java.lang.ClassLoader.getResource(ClassLoader.java:793)
01-14 16:43:21.258 E/System (31646): at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:977)
01-14 16:43:21.258 E/System (31646): at java.util.ResourceBundle$RBClassLoader.getResourceAsStream(ResourceBundle.java:464)
01-14 16:43:21.258 E/System (31646): at java.util.ResourceBundle$Control$1.run(ResourceBundle.java:2603)
01-14 16:43:21.258 E/System (31646): at java.util.ResourceBundle$Control$1.run(ResourceBundle.java:2589)
01-14 16:43:21.258 E/System (31646): at java.security.AccessController.doPrivileged(AccessController.java:67)
01-14 16:43:21.258 E/System (31646): at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2587)
01-14 16:43:21.258 E/System (31646): at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1438)
01-14 16:43:21.258 E/System (31646): at java.util.ResourceBundle.findBundle(ResourceBundle.java:1402)
01-14 16:43:21.258 E/System (31646): at java.util.ResourceBundle.findBundle(ResourceBundle.java:1356)
01-14 16:43:21.258 E/System (31646): at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1298)
01-14 16:43:21.258 E/System (31646): at java.util.ResourceBundle.getBundle(ResourceBundle.java:723)
01-14 16:43:21.258 E/System (31646): at java.util.logging.Level.<init>(Level.java:223)
01-14 16:43:21.258 E/System (31646): at java.util.logging.Level.<clinit>(Level.java:96)
01-14 16:43:21.258 E/System (31646): at java.util.logging.Logger.<clinit>(Logger.java:177)
01-14 16:43:21.258 E/System (31646): at java.util.logging.Logger.getLogger(Logger.java:393)
01-14 16:43:21.258 E/System (31646): at android.icu.util.TimeZone.<clinit>(TimeZone.java:92)
01-14 16:43:21.258 E/System (31646): at java.util.TimeZone.setDefault(TimeZone.java:712)
01-14 16:43:21.258 E/System (31646): at com.android.internal.os.RuntimeInit.commonInit(RuntimeInit.java:132)
01-14 16:43:21.258 E/System (31646): at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:256)
没用过 C,只用过 Python 的有强迫症,去帮他改过来
出现这个的原因可能很多,比如有些界面禁止截屏,或者说动态界面。建议在执行时抓取下手机的 log 看下是否有相应的 log 输出。
分析下电脑端的代码流程,这个报错是出现在UiAutomatorHelper.java中的 166 行,
调用了IDevice的实现类Device中的 getScreenshot() 方法,
而其又调用了AdbHelper.java中的 getFrameBuffer() 方法。
而 AdbHelper.java 中的 getFrameBuffer() 处理方式就是通过与手机端的 adb server 建立 socket 连接,读取流信息。单独从这边看不出啥问题来,所以应结合手机端 adb server 是否有对应的 log 输出再分析具体产生的原因。
建议你升级下 appium 的版本,我看最新版本在设置 mock_location 的时候对异常是有捕获的
helpers.setMockLocationApp = async function (adb, app) {
try {
if (await adb.getApiLevel() < 23) {
await adb.shell(['settings', 'put', 'secure', 'mock_location', '1']);
} else {
await adb.shell(['appops', 'set', app, 'android:mock_location', 'allow']);
}
} catch (err) {
logger.warn(`Unable to set mock location for app '${app}': ${err.message}`);
}
};
代码地址:android-helpers.js
自己写个 SDK 指的是类似 bugly 的方式?
相互学习
湿人
没毛病吧 就是 6-10 点
建议看下社区的这篇文章,https://testerhome.com/topics/1030
ignore-native-crashes 不是表示忽略 monkey 本身的异常,直到事件执行完毕。
ignore-native-crashes 的作用是忽略运行过程中 Android Native 层出现的异常,一般是底层 C/C++ 实现的代码层。这个异常出现时系统会在 /data/tombstones 目录下生成 tombstone_xx 的日志文件,记录了应用 crash 发生时的内存、寄存器、堆栈信息等。
Monkey 的处理方式就是,如果有设置--monitor-native-crashes,并且设置了--ignore-native-crashes,则会对 Native 异常进行监控,在执行每一个事件的时候查看目录/data/tombstones 下是否有新的类似 tombstone_xx 文件生成,下面是 AOSP 的源码:
/**
* Watch for appearance of new tombstone files, which indicate native
* crashes.
*
* @return Returns true if new files have appeared in the list
*/
private boolean checkNativeCrashes() {
String[] tombstones = TOMBSTONES_PATH.list();
// shortcut path for usually empty directory, so we don't waste even
// more objects
if (tombstones == null || tombstones.length == 0) {
mTombstones = null;
return false;
}
boolean result = false;
// use set logic to look for new files
HashSet<Long> newStones = new HashSet<Long>();
for (String t : tombstones) {
if (t.startsWith(TOMBSTONE_PREFIX)) {
File f = new File(TOMBSTONES_PATH, t);
newStones.add(f.lastModified());
if (mTombstones == null || !mTombstones.contains(f.lastModified())) {
result = true;
waitForTombstoneToBeWritten(Paths.get(TOMBSTONES_PATH.getPath(), t));
Logger.out.println("** New tombstone found: " + f.getAbsolutePath()
+ ", size: " + f.length());
}
}
}
// keep the new list for the next time
mTombstones = newStones;
return result;
}
appActivity 不对,这是我使用 aapt 工具对 LINE 版本 8.13.2 查看到的 launcher-activity 为:jp.naver.line.android.activity.SplashActivity。
具体的命令:aapt dump badging jp.naver.line.android_8.13.2.apk |grep 'launchable-activity'
它采用了 C、C++ 甚至是 Dust、Go、Python 等编程语言 应为 它采用了 C、C++ 甚至是 Dart、Go、Python 等编程语言吧
一面的技术面那人一般般...
又来了............
44 课时,同求网络直播!!!
功能测试中的集成测试里面的 android 测试工具里的 appnium->appium
This page is taking way too long to load.
Sorry about that. Please try refreshing and contact us if the problem persists.