example - No se puede encontrar un Java Runtime Android Studio Robolectric

robolectric android example

Question

He añadido Robolectric a un proyecto de Android. Estoy usando Android Studio con Build Tools en 19.0.1.

Puedo realizar las pruebas con:

$./gradlew test

Que se ejecutan bien.

Si lo intento

$ gradle installDebug

Se ejecuta bien también:

$ ./gradlew installDebug
WARNING: Dependency commons-logging:commons-logging:1.1.1 is ignored for debugTest as it may be conflicting with the internal version provided by Android.
         In case of problem, please repackage it with jarjar to change the class packages
WARNING: Dependency org.apache.httpcomponents:httpclient:4.0.3 is ignored for debugTest as it may be conflicting with the internal version provided by Android.
         In case of problem, please repackage it with jarjar to change the class packages
The Test.testReportDir property has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the Test.getReports().getHtml().getDestination() property instead.
:app:compileDebugNdk
:app:preBuild
:app:preDebugBuild
:app:checkDebugManifest
:app:prepareDebugDependencies
:app:compileDebugAidl
:app:compileDebugRenderscript
:app:generateDebugBuildConfig
:app:mergeDebugAssets
:app:generateDebugResValues UP-TO-DATE
:app:generateDebugResources
:app:mergeDebugResources
:app:processDebugManifest
:app:processDebugResources
:app:generateDebugSources
:app:compileDebugJava
:app:preDexDebug
:app:dexDebug
:app:processDebugJavaRes UP-TO-DATE
:app:validateDebugSigning
:app:packageDebug
:app:installDebug
8266 KB/s (46166 bytes in 0.005s)
 pkg: /data/local/tmp/app-debug-unaligned.apk
Success

BUILD SUCCESSFUL

Total time: 4.291 secs

Sin embargo, cuando intento ejecutar mi proyecto en un dispositivo o emulador de Android Studio, obtengo lo siguiente:

Execution failed for task '':app:dexDebug''.
> com.android.ide.common.internal.LoggedErrorException: Failed to run command:
/Applications/Android Studio.app/sdk/build-tools/19.0.1/dx --dex --output /Users/fstephany/Code/android/RoboElectricTestingProject/app/build/dex/debug /Users/fstephany/Code/android/RoboElectricTestingProject/app/build/classes/debug /Users/fstephany/Code/android/RoboElectricTestingProject/app/build/dependency-cache/debug
Error Code:
  1
Output:
  Unable to locate a Java Runtime to invoke.

¿Alguna pista sobre dónde buscar este problema? Siempre puedo installDebug luego iniciar la aplicación desde CLI o Studio, pero se está interponiendo.

Answer 1

Cambiarme a Gradle 1.10 me funcionó (en OS-X). Puede editar las propiedades de gradle-wrapper o configurar una distribución local de gradle en Android-Studio

Answer 2

Intente configurar sourceCompatibility y targetCompatibility en su archivo build.gradle. Para Java 1.7 debería verse como:

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_7
        targetCompatibility JavaVersion.VERSION_1_7
    }
}

Answer 3

Para mí, agregar JAVA_HOME a sus Variables de ruta (Android Studio -> Preferencias -> Variables de ruta), luego reiniciando el demonio de Gradle, como se mencionó anteriormente ( ./gradlew --stop ) funcionó.

En una Mac, puede encontrar su directorio Java (versión 6) con /usr/libexec/java_home -v 1.6

Answer 4

Un daemon Gradle caducado puede estar causando algunos problemas de rendimiento en segundo plano. Pensé que Gradle lo limpiaría después de 3 horas de inactividad, pero parece que ese no es el caso. Vaya a su terminal, vaya a la carpeta raíz de su proyecto donde se encuentran los archivos de gradle y escriba el comando

./gradlew --stop

e intenta ejecutar tu compilación de nuevo. Esperemos que eso resuelva tu problema como lo hizo el mío.

Estoy tratando de entender por qué esto causó un problema, pero aún no he encontrado una razón lo suficientemente buena. Voy a editar la respuesta si encuentro algo.

ACTUALIZAR

Desde la página de Gradle Design Github :

Actualmente, el demonio tiene serios problemas cuando se produce presión de memoria. Cuando está bajo presión, el proceso del demonio exhibe GC thrash.

Una hipótesis para esto es el uso de cachés de referencia débiles, particularmente en el sistema de metaclase Groovy, donde las instancias de la meta clase se mantienen en un caché de referencia débil. Tenga en cuenta que esto no es necesariamente un problema con el daemon, ya que también se aplicaría al caso no daemon. Sin embargo, se ve agravada por la pérdida de memoria del daemon, lo que aumenta la posibilidad de que se produzca una situación de presión de memoria.

Esto no da una respuesta definitiva, pero da la impresión de que el demonio puede ser el culpable de lo que está viendo (junto con otras cosas). He visto que algunas tareas de Gradle se demoran 10 veces, y la ejecución --stop alivia esos problemas también.