Fixed
Status Update
No update yet.
Comments
me...@thomaskeller.biz
Android Studio is actually 0.8.11
bl...@gmail.com
The stack trace seems to say you are running with several definitions of one annotation. This seems to often be caused by including 2 different versions of the same library in an instrumentation apk and its tested application apk. Could you please check it's not your case here? If it's your case, you should fix that.
Looking at dx about this report, it seems that DX may fail to check a duplicate class definition when running multidex, I've recorded a bug about this point.
That said, it does not look like we could be in the DX lack of check case here, because mainDexClasses is keeping all the annotations in the main dex (and dx seems to correctly identify the duplicate definition when the 2 definitions are added to the same dex). (Can you confirm that you're using mainDexClasses to create your main dex list?)
I'm assigning back to you xav in case you want to add some check in the SDK.
Looking at dx about this report, it seems that DX may fail to check a duplicate class definition when running multidex, I've recorded a bug about this point.
That said, it does not look like we could be in the DX lack of check case here, because mainDexClasses is keeping all the annotations in the main dex (and dx seems to correctly identify the duplicate definition when the 2 definitions are added to the same dex). (Can you confirm that you're using mainDexClasses to create your main dex list?)
I'm assigning back to you xav in case you want to add some check in the SDK.
ne...@gmail.com
The error is not reproducible in other machines, so it's probably a local config problem. We'll try the mainDexClasses approach.
[Deleted User] <[Deleted User]>
[Comment deleted]
sl...@google.com
ka...@gmail.com
We're still looking into it. We're *not* using mainDexClasses because it wasn't documented or included on the SDK, and the only blog file that references it (written on Monday) mentions libraries to be preDexed, which isn't available while --multi-dex, and removing --multi-dex doesn't allow our app to build due to the 64k method limit.
sl...@google.com
The error is localized to my computer and only in 4/10 builds, so whenever I want something and it doesn't work I have to edit a file, rebuild and hope for the best.
Description
Devices/Android versions reproduced on: any
I use the IntentsTestRule in my JUnit test to start my activity and capture intents that it issues. If the activity fails to launch for any reason, "Intents.release()" is called. In this method, "defaultInstance.internalRelease()" is called uncondtionally, i.e. also when "defaultInstance" is still null, which leads to an NPE.
Full stack trace:
java.lang.NullPointerException: Attempt to invoke virtual method 'void android.support.test.espresso.intent.Intents.internalRelease()' on a null object reference
at android.support.test.espresso.intent.Intents.release(Intents.java:140)
at android.support.test.espresso.intent.rule.IntentsTestRule.afterActivityFinished(IntentsTestRule.java:68)
at android.support.test.rule.ActivityTestRule$ActivityStatement.evaluate(ActivityTestRule.java:260)
at my.package.MockServerRule$1.evaluate(MockServerRule.java:29)
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:54)
at android.support.test.runner.AndroidJUnitRunner.onStart(AndroidJUnitRunner.java:240)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1976)
Source code of MockServerRule:
public class MockServerRule implements TestRule {
@Override
public Statement apply(final Statement base, Description description) {
return new Statement() {
@Override
public void evaluate() throws Throwable {
startServer();
try {
base.evaluate();
} finally {
stopServer();
}
}
};
}
...
}
My test class:
@RunWith(AndroidJUnit4.class)
public class LoginActivityTest {
@Rule
public final IntentsTestRule<LoginActivitySingle> mActivityTestRule = new IntentsTestRule<>(LoginActivitySingle.class, true, false);
@Rule
public final MockServerRule mMockServerRule = new MockServerRule();
@Test
public void someTest() {
Activity activity = mActivityTestRule.getActivity();
...
}
}