【问题标题】：Android UI tests with Espresso + MockK crash with SIGSEGV on emulators, fine on physical devices使用 Espresso + MockK 的 Android UI 测试在模拟器上使用 SIGSEGV 崩溃，在物理设备上很好
【发布时间】：2020-11-13 12:25:36
【问题描述】：

我刚刚开始使用 MockK 在基于 MVP 的应用中模拟所有存储库/服务逻辑以进行 UI 测试。

我有一些 UI 测试运行登录活动，其中 Espresso 输入登录名和密码并使用 MockK 我可以伪造各种登录失败或失败的情况。

所有服务和存储库都是标准 Kotlin 对象，所以我使用 mockkobject 和 every/coEvery 来覆盖和处理登录请求和任务。

在我的物理设备上，测试完全没有问题，但是当我尝试在运行 Android P+ 并带有推荐图像的模拟器上运行它们时，它们会在随机时间不断崩溃。在极少数情况下，它们可以存活足够长的时间来工作。

查看日志，我得到了各种 SIGSEGV：

A/libc：致命信号 11 (SIGSEGV)，代码 1 (SEGV_MAPERR)，tid 10425 (e.android.debug) 中的故障地址 0x0，pid 10425 (e.android.debug)

A/libc：致命信号 11 (SIGSEGV)，代码 1 (SEGV_MAPERR)，tid 10968 (HeapTaskDaemon) 中的故障地址 0xc，pid 10957 (e.android.debug)

A/libc：致命信号 11 (SIGSEGV)，代码 1 (SEGV_MAPERR)，tid 15050 (firebase-instal) 中的故障地址 0x0，pid 14972 (e.android.debug)

A/libc：致命信号 11 (SIGSEGV)，代码 1 (SEGV_MAPERR)，tid 8902 (Measurement Wor) 中的故障地址 0xd，pid 8858 (e.android.debug)

A/libc：致命信号 11 (SIGSEGV)，代码 1 (SEGV_MAPERR)，tid 22004 (Binder:21832_5) 中的故障地址 0x0，pid 21832 (e.android.debug)

但是深入查看日志，我相信我找到了罪魁祸首：

InputDispatcher: channel '9fa7335 my.company.com.android.debug/my.company.com.ui.login.LoginActivity(server)' ~ Channel 已不可恢复地损坏，将被丢弃！

正在寻找解决方案，这似乎是由于内存泄漏而发生的？

在任何情况下，我都确保在 @Before 方法中启动被测活动，在该方法中，所有模拟都会发生，而我正在清除此类模拟并在 @After 方法中进行验证。

显然，我相信测试确实可以正常工作，但 Espresso 或所有发生的嘲笑一定有问题......

[编辑 1]

进一步查看之前的日志，这可能是内存泄漏的原因：

ActivityThread：服务 com.google.android.gms.autofill.service.AutofillService 泄露了最初在这里注册的 IntentReceiver com.google.android.gms.autofill.smsretriever.TracingSmsBroadcastReceiver@ce00658。您是否错过了对 unregisterReceiver() 的调用？ android.app.IntentReceiverLeaked：服务 com.google.android.gms.autofill.service.AutofillService 泄露了最初在这里注册的 IntentReceiver com.google.android.gms.autofill.smsretriever.TracingSmsBroadcastReceiver@ce00658。您是否错过了对 unregisterReceiver() 的调用？

我在我的模拟器上禁用了 AutoFillService（在相关设置部分中设置为 none）。这似乎在一开始提高了我的测试成功率，但在几次运行后它们一直在崩溃。不过，现在日志不再显示此泄漏。

[编辑 2]

显然这个问题可能与 MockK 有关，因为我能够检索到更多日志：

2020-07-24 11:57:15.955 15767-15780/com.my.company.android.debug A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 15780 (HeapTaskDaemon), pid 15767 (e.android.debug)
2020-07-24 11:57:15.997 15962-15962/? E/crash_dump32: failed to detach from thread 15773: No such process
2020-07-24 11:57:15.997 15962-15962/? E/crash_dump32: failed to detach from thread 15778: No such process
2020-07-24 11:57:15.997 15962-15962/? E/crash_dump32: failed to detach from thread 15779: No such process
2020-07-24 11:57:15.997 15962-15962/? E/crash_dump32: failed to detach from thread 15780: No such process

// 20 more times of exact same line //

2020-07-24 11:57:16.007 15962-15962/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2020-07-24 11:57:16.007 15962-15962/? A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:10/QSR1.190920.001/5891938:user/release-keys'
2020-07-24 11:57:16.007 15962-15962/? A/DEBUG: Revision: '0'
2020-07-24 11:57:16.007 15962-15962/? A/DEBUG: ABI: 'x86'
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: Timestamp: 2020-07-24 09:57:16+0000
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: pid: 15767, tid: 15780, name: HeapTaskDaemon  >>> com.my.company.android.debug <<<
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: uid: 10136
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG: Cause: null pointer dereference
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG:     eax 00000000  ebx ef8a6c34  ecx 00000000  edx f310b604
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG:     edi f3200380  esi 00000000
2020-07-24 11:57:16.008 15962-15962/? A/DEBUG:     ebp e659d9a8  esp e659d940  eip ef7d89f4
2020-07-24 11:57:16.027 2044-2135/? E/InputDispatcher: channel '342ebda com.my.company.android.debug/com.my.compan.android.ui.error.LoginActivity (server)' ~ Channel is unrecoverably broken and will be disposed!

经过进一步调查，Android Test Github repo 上有一个存在 1 年的 issue 显示相同的问题（但 issue 现已关闭）：https://github.com/android/android-test/issues/352

Mockk 的相关问题已在此处打开：https://github.com/mockk/mockk/issues/466

[编辑 3]

我正在探索返回Mockito 的替代方案，它具有更多历史和更积极的发展。花费了一些时间，但将 UI 测试迁移到 Mockito 没有什么大问题。

结果：好吧，起初崩溃完全消失了。我可以毫不费力地进行 10、20、30 次测试。至少在移动设备上。

但是，在 Android TV（仍带有模拟器）上，崩溃很快再次出现。然后在移动设备上也是如此，但来自InputDispatcher 的可怕消息的频率要低得多。

在设置迁移到 Mockito 时，我注意到 Mockk 在模拟 Android 测试仪器时与 Mockito 共享相同的限制和依赖项。我遇到了同样的问题和困难。

所以这让我相信他们都不是罪魁祸首，但很可能是 Android Instrumentation API。

我还注意到手动重启模拟器大大改善了这种情况。

【问题讨论】：

标签： android kotlin mocking android-espresso mockk

【解决方案1】：

这是在我的堆栈跟踪中：

  W  Unexpected CPU variant for X86 using defaults: x86
         ActivityThread  W  Package uses different ABI(s) than its instrumentation:

切换到 64 位模拟器解决了这个问题。

【讨论】：

【解决方案2】：

我的仪器测试套件也遇到了这个问题，并且怀疑 MockK （至少部分）有问题。

这远非真正的解决方案，但我注意到使用 Android Test Orchestrator 运行我的测试大大降低了由于测试进程崩溃（由上述段错误引起）而导致随机失败的机会。（如果您使用 Firebase 测试实验室模拟器运行测试，这可能特别有用。）使用 Orchestrator 的另一个好处是，如果您的测试在 Orchestrator 进程中失败，它可以很好地挖掘日志（在 Firebase 测试实验室中）以找到根本错误。

我不确定这是否适用于所有人，但如果确实如此，则可能表明 MockK（如果它确实是此问题的根源）没有完全清理并且正在泄漏到其他测试中。

【讨论】：

感谢您的反馈。当我们要设置我们的测试实验室时，我会牢记这一点。我也更新了我的帖子，我说 Mockk 可能不是罪魁祸首......

【解决方案3】：

我遇到了完全相同的情况，即我的测试在模拟器上随机崩溃，Process crashed 错误提示检查 Logcat。 Logcat 上出现SIGSEGV 错误，但并非总是如此。

就我而言，是com.linkedin.dexmaker:dexmaker-mockito-inline 导致了随机崩溃。我不得不将它添加到在 Instrumentation 测试中模拟 Kotlin 数据类，毕竟我不需要。所以删除这个依赖解决了我的问题。

我建议调查一下你的测试是在什么时候开始崩溃的，这样会更容易追根究底。

【讨论】：

嗨。谢谢你的建议，不幸的是，我需要这种依赖来模拟最终方法，默认情况下，所有方法都使用 Kotlin。