Test oprzyrządowania kończy się losowo z włączoną obsługą wielościeżkową

Question

W mojej aplikacji na Androida włączono funkcję wielościeżkową. Aplikacja działa dobrze na emulatorach. Używam robotów do testowania aplikacji. Ale kiedy wykonuję testy testowe oprzyrządowania, czasami test przechodzi, ale przeważnie również zawodzą po ponownym uruchomieniu systemu. Nie ma żadnej zmiany kodu między czasem, który upłynął a porażką.

domyślna konfiguracja Gradle:

android { 
     defaultConfig { 
     applicationId "com.example.androidapp" 
     minSdkVersion 16 
     targetSdkVersion 23 
     multiDexEnabled true 
     testInstrumentationRunner "com.android.test.runner.MultiDexTestRunner" 
     testProguardFile "proguard-test.txt" 
    } 
} 

także dodawać zależności do badań:

androidTestCompile fileTree(dir: 'libs', include:'robotium-solo-5.3.0.jar') 

androidTestCompile ('com.android.support:multidex-instrumentation:1.0.1') { 
     exclude group: 'com.android.support', module: 'multidex' } 

AndroidManifest.xml już wspomniano znacznik stosowana jest jako:

<application 
     android:name="StartupActivity" 
     android:allowBackup="true" 
     android:icon="@mipmap/ic_launcher" 
     android:label="@string/app_name" ...../> 

I przedłużony "android.support.multidex.MultiDexApplication" w StartupActivity. Czasy, gdy przypadki testowe oprzyrządowanie spadnie pojawia się następujący błąd:

INSTRUMENTATION_RESULT: shortMsg=java.lang.IllegalAccessError 
INSTRUMENTATION_RESULT: longMsg=java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation 
INSTRUMENTATION_CODE: 0 

Komunikat o błędzie w LogCat jest:

W/dalvikvm﹕ Class resolved by unexpected DEX: Lcom/example/androidapp/StartupActivity;(0xa695df08):0x9910e000 ref [Landroid/support/multidex/MultiDexApplication;] Landroid/support/multidex/MultiDexApplication;(0xa695df08):0x99a2c000 
W/dalvikvm﹕ (Lcom/example/androidapp/StartupActivity; had used a different Landroid/support/multidex/MultiDexApplication; during pre-verification) 
W/dalvikvm﹕ Unable to resolve superclass of Lcom/example/androidapp/StartupActivity; (540) 
W/dalvikvm﹕ Link of class 'Lcom/example/androidapp/StartupActivity;' failed 
D/AndroidRuntime﹕ Shutting down VM 
W/dalvikvm﹕ threadid=1: thread exiting with uncaught exception (group=0xa628c288) 

Klasa test wygląda nieco jak:

public class HelloActivityTest extends ActivityInstrumentationTestCase2<HelloActivity> { 
private Solo solo; 
public HelloActivityTest() { 
    super(HelloActivityTest.class); 
} 
    @Override 
    public void setUp() throws Exception { 
    setActivityInitialTouchMode(false); 
    solo = new Solo(getInstrumentation(), getActivity()); 
    } 

    public void test1() {} 

    public void test2() {} 

} 

I prowadzę test jako test Androida. Nie jestem w stanie zrozumieć, która zależność psuje kod. Poza tym losowe niepowodzenia kodu są sceptyczne. Proszę pomóż.

Answer 1

Znaleziono rozwiązanie dla tego samego, to jest ustawienie parametrów weryfikacji i optymalizacji dex. Można również ustawić flagi dalvik.vm.dexopt na v = n, aby ramka przeszła -Xverify: none -Xdexopt: zweryfikowano, aby wyłączyć weryfikację.

Execute:

adb shell setprop dalvik.vm.dexopt-flags v=n,o=v 
adb shell stop installd 
adb shell start installd 

Musieliśmy czekać na kilka sekund po wykonaniu komendy. Test oprzyrządowania z wielodrutem działa płynnie po tym.

Answer 2

Jeśli używasz wtyczki gradle powyżej 1.4.0-beta3. Obsługa wielu Dex została dodana do wtyczki gradle, co oznacza, że ​​zależności są już zawarte i nie musisz ich wyraźnie określać. Niestety, wydaje się być błędny w urządzeniach pre-Lollipop, wygląda na to, że różne wersje MultiDexApplication są używane do aplikacji docelowej i testowej. Jako Instrumentation wynik nie biegać i logcat daje coś podobnego do tego:

W/dalvikvm: Class resolved by unexpected DEX: Lcom/example/dexproof/App;(0x43893f90):0x64d46000 ref [Landroid/support/multidex/MultiDexApplication;] Landroid/support/multidex/MultiDexApplication;(0x43893f90):0x5de01000 
W/dalvikvm: (Lcom/example/dexproof/App; had used a different Landroid/support/multidex/MultiDexApplication; during pre-verification) 
W/dalvikvm: Unable to resolve superclass of Lcom/example/dexproof/App; (457) 
W/dalvikvm: Link of class 'Lcom/example/dexproof/App;' failed 
E/AndroidRuntime: java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation 

Rozwiązaniem byłoby wykorzystanie 1.3.1 Gradle wtyczki i uważać, aby jednoznacznie określić i multidex-instrumentation (w przypadku trzeba to również) zależności tej samej wersji. Prawdopodobnie będziesz także chciał użyć AndroidJUnitRunner, ponieważ ma wbudowaną obsługę wielu dokumentów.

Zapraszam do obsady powiązanego problem: https://code.google.com/p/android/issues/detail?id=194609

Answer 3

Dla wtyczki Gradle 1.5.0 można użyć tego obejścia w swojej budowie.gradle:

// Workaround for Multidex bug in gradle-android-plugin 
// Replace Multidex dependency with some dummy dependency to avoid dex problems 
// @see https://code.google.com/p/android/issues/detail?id=194609 
project.getConfigurations().all { config -> 
    if (config.name.contains("AndroidTest")) { 
     config.resolutionStrategy.eachDependency { DependencyResolveDetails details -> 
      if (details.requested.name == "multidex") { 
       details.useTarget("de.felixschulze.teamcity:teamcity-status-message-helper:1.2") 
      } 
     } 
    } 
}