Command-line gradle clean caused Robolectric to not find android.app.Application [65354278]

Fixed

Bug

[AOSP] mac

Status Update

No update yet.

Description

pe...@gmail.com

created issue #1

Sep 5, 2017 05:54AM

This may be gradle-related, as it's also happening when trying to run tests from the command line. Here's a stack trace:

Exception in thread "main" java.lang.NoClassDefFoundError: android/app/Application
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.robolectric.annotation.Config.<clinit>(Config.java:38)
at org.robolectric.annotation.Config$Builder.<init>(Config.java:398)
at org.robolectric.RobolectricTestRunner.buildGlobalConfig(RobolectricTestRunner.java:421)
at org.robolectric.RobolectricTestRunner.getConfig(RobolectricTestRunner.java:403)
at org.robolectric.RobolectricTestRunner.getChildren(RobolectricTestRunner.java:216)
at org.junit.runners.ParentRunner.getFilteredChildren(ParentRunner.java:426)
at org.junit.runners.ParentRunner.getDescription(ParentRunner.java:351)
at com.intellij.junit4.JUnit4IdeaTestRunner.getDescription(JUnit4IdeaTestRunner.java:78)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:50)
at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMainV2.main(AppMainV2.java:131)
Caused by: java.lang.ClassNotFoundException: android.app.Application
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 29 more

Another test fails due to not finding 'Parcelable'. The tests were running fine (tm) yesterday. I also made a change to the build.gradle files, adding a dependency, but reverting that change doesn't help. Also, doing './gradlew --stop' did not have any impact. I will report this now and continue to try to find a way to make the tests run again.

This is also using AGP 3.0.0-beta4.

Build: 3.0 Beta 4, AI-171.4304935, 201708291904,

AI-171.4304935, JRE 1.8.0_152-release-915-b01x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.12.5 unknown, screens 1680x1050, 2560x1440

IMPORTANT: Please read

https://developer.android.com/studio/report-bugs.html carefully and supply all required information.

Comments

pe...@gmail.com <pe...@gmail.com> #2Sep 5, 2017 06:13AM

Seems like similar things have happened before:

https://github.com/robolectric/robolectric/issues/3232, though I sort of wonder why I'm having this problem both in AS and command-line Gradle.

pe...@gmail.com <pe...@gmail.com> #3Sep 5, 2017 06:30AM

This very weird. I had just tried deleting the entire Gradle cache (rm -rf ~/.gradle/caches), and got the same error when running Gradle from the command line, so decided that wasn't it. Then, making no further changes, I tried again from AS (once it had finished with a long indexing update), and it worked, in the sense that AS/Gradle could now find the Android OS classes. The only change was converting a constant field in a Java test file from public to private access. And after that, command-line Gradle test invocations succeed as well.

pe...@gmail.com <pe...@gmail.com> #4Sep 5, 2017 07:21AM

(for clarity, the 'making no further changes' comment above was incorrect; there was a code change, making a constant private - but there were no other changes to gradle, AS or build files.)

xa...@google.com <xa...@google.com> Sep 5, 2017 07:10PM

Assigned to be...@google.com.

da...@spotify.com <da...@spotify.com> #5Sep 11, 2017 08:13AM

It appears as if the mockableAndroidJar tasks are considering themselves UP-TO-DATE too easily, resulting in no mockable-android-*.jar in the ./build/generated folder. Using "--rerun-tasks" will force re-generation.

be...@google.com <be...@google.com> #6Sep 14, 2017 04:45PM

Reassigned to jo...@google.com.

Robolectric is using its own platforms jars, not the generated mockable jar (Jonathan, correct me if I'm wrong).

Do you have a way of reproducing this problem?
What version of Gradle (the build system, not our plugin) are you using?
What version of Robolectric?

jo...@google.com <jo...@google.com> #7Sep 14, 2017 08:09PM

Robolectric uses the framework jar (implementation of Android framework) at runtime, but via its own special classloader. This looks like the system classloader is unable to find the class. I think with AGP the mockable jar is placed on the system classpath, is that true for both compile time and runtime classpath?

be...@google.com <be...@google.com> #8Sep 15, 2017 09:13AM

The compile SDK android.jar is used at compile time and the mockable one at runtime. I thought you only used the framework classes through the Robolectric classloader but it seems Config.Builder relies on the one we provide, good to know.

Still - I've been unable to reproduce it, so would appreciate any tips on how to trigger this. As far as I see, the IDE makes sure to call the ":app:mockableAndroidJar" task and the task seems to have the correct annotations so that Gradle should run it (or not) as it should.

pe...@gmail.com <pe...@gmail.com> #9Sep 15, 2017 09:56AM

We've observed this relatively rarely (a couple of times per week? it's probably under-reported) in our team of ~80 Android developers. We don't know of any reliable repro steps, but if we do find something, we'll share it of course. Maybe there is some race between command-line and IDE gradle invocations that creates confusion or something similar.

be...@google.com <be...@google.com> Sep 18, 2017 08:28AM

Reassigned to be...@google.com.

be...@google.com <be...@google.com> #10Sep 26, 2017 06:28PM

Marked as fixed.

For 3.0 we'll start keeping a copy of the mockable JAR in every subproject, as the concept of sharing the output file between tasks in different subprojects doesn't seem to work well in Gradle. Moving forward we'll have a look at using Gradle's new ArtifactTransform API for this.