Нет статического метода deleteRecursively (Ljava / io / File;) в androidTest при включении proguard - PullRequest
0 голосов
/ 19 февраля 2019

Я пытаюсь включить proguard в моих тестах Android.Но я сталкиваюсь со странной проблемой:

java.lang.NoSuchMethodError: No static method deleteRecursively(Ljava/io/File;)Z in class Lkotlin/io/FilesKt; or its super classes (declaration of 'kotlin.io.FilesKt' appears in /data/app/org.walleth.offline-BAciL8erjxU-sHGjQe6uQg==/base.apk!classes2.dex)
at org.ligi.trulesk.RulesKt.doBefore(Rules.kt:82)
at org.ligi.trulesk.RulesKt.access$doBefore(Rules.kt:1)
at org.ligi.trulesk.TruleskIntentRule.beforeActivityLaunched(Rules.kt:58)
at android.support.test.rule.ActivityTestRule.launchActivity(ActivityTestRule.java:351)
at android.support.test.rule.ActivityTestRule$ActivityStatement.evaluate(ActivityTestRule.java:525)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at android.support.test.internal.runner.TestExecutor.execute(TestExecutor.java:56)
at android.support.test.runner.AndroidJUnitRunner.onStart(AndroidJUnitRunner.java:384)
at org.ligi.trulesk.AppReplacingRunnerBase.onStart(AppReplacingRunnerBase.kt:19)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:2145)

Proguard при сборке релиза работает - не уверен, почему он так агрессивен в тестах Android.В идеале классы инструментовки не должны быть удалены вообще.

Ответы [ 2 ]

0 голосов
/ 13 марта 2019

Я думаю, что основная проблема в том, что androidTest - это другая единица компиляции.app/src/androidTest собирается в app-debug-androidTest.apk, а app/src/main собирается в app-debug.apk.И поэтому Proguard во время assembleDebug также не видит и не включает app/src/androidTest в построение графика использования «встряхивания дерева», потому что он недоступен в пути к классам.Практически это означает, что код приложения, на который ссылаются только в тестах, не работает.

Эта тема соотносится с "Должен ли я изменить видимость с частного на общедоступный только для тестового доступа?"Дилем.В зависимости от того, какие тесты вы пишете, вы можете рассмотреть следующие вопросы:

  • Всегда оставляйте дополнительные точки входа в приложение (используемые тестами) для отправки пользователям release.apk
  • Скомпилируйте основной apkиначе при запуске теста и снова принимаю на себя риск доставки пользователям не совсем того же кода, который выполняется тестом

К сожалению, я не знаю ни одного автомагического решения в данный моментпохож на all-open плагин).Но можно решить проблему отсутствующих методов в индивидуальном порядке.

buildTypes {
    debug {
        minifyEnabled true

        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-project.txt', 'proguard-project-ext.txt'
        testProguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-test-project.txt'
    }
}      
  • proguard-project.txt - конфигурация для app/src/main и implementation зависимостей
  • proguard-project-ext.txt - конфигурация для app/src/main, которая содержит -keep инструкции для каждого метода / поля, используемого только в тестах, которые были "ложно" удалены proguard.Я предпочитаю хранить его отдельно, условно удалить при публикации в google play
  • proguard-test-project.txt - конфигурация для app/src/androidTest и ее androidTestImplementation зависимостей.Обычно содержит -dontwarn net.bytebuddy.** и т. Д. Хотя обратите внимание, что тестовый apk не поддерживает multidex, поэтому можно использовать метод ограничения 65k, включив слишком много зависимостей.

Проверка android/platform/tools/base/studio-master-dev/./build-system/integration-test/test-projects/minify для справки по реализации.

0 голосов
/ 12 марта 2019

test сборок по умолчанию всегда debug сборок - даже при установке testBuildType, это должно иметь конфигурацию initWith debug, что намекает на другие ошибки.извините за то, что не дал ожидаемого ответа, но эта неправильная конфигурация основана на определенной неправильной концепцииЯ бы предложил отключить запутывание, потому что в этом случае это бессмысленно, потому что этот пакет никогда не будет распространяться.может даже оказаться невозможным определить правила ProGuard для тестового приложения (которое представляет собой отдельный пакет).это поведение "разработано", вызвано работой с тестовой средой ... потому что тестовое приложение не будет знать о отображении запутывания класса / метода другого пакета приложения - и поэтому шансы довольно малы, что это можеткогда-нибудь получится.

Лаборатория тестирования Firebase Тест Robo UX наиболее похож на то, что требуется эффективно.

...