¿Por qué Android cambia la tarea de compilación a la tarea de implementación en la compilación de gradle?

Como se ve en Android Studio 3.0 (canary 3.0), ahora agregamos depedencies declarando implementation tareas de implementation lugar de compile .

 // Before compile 'com.android.support:appcompat-v7:25.3.1' // Currently implementation 'com.android.support:appcompat-v7:25.3.1' 

Todavía podemos usar la tarea de compile , pero me gustaría entender:

  • ¿Cuál es la diferencia entre la implementation y la tarea de compile ?
  • ¿Por qué Android gradle construir cambio para utilizar la implementation como predeterminado?

Parece que compile ha sido obsoleto y api o implementation debe ser utilizado en su lugar. Según The Java Library Plugin – Guía del usuario de Gradle Versión 3.5 :

La configuración de compile todavía existe, pero no debe utilizarse ya que no ofrecerá las garantías que proporcionan las configuraciones de api y de implementation .

Gracias a un enlace útil de @petter, me gustaría añadir un resumen.

Esto significa que la compilación de Android Gradle empieza a usar el complemento java-library lugar del plugin java anterior. Este plugin introduce el concepto de exposed API con dos configuration para declarar dependencias.

  1. Api

Debe utilizarse para declarar las dependencias que son exportadas por la biblioteca API

Por ejemplo, en un caso que está construyendo una biblioteca de Java (o Android) que es utilizada por otras aplicaciones. Si utiliza cualquier biblioteca de terceros y desea exponer su API al consumidor de su biblioteca también, debe declarar así.

 api 'commons-httpclient:commons-httpclient:3.1' 
  1. implementación

Debe utilizarse para declarar las dependencias que son internas al componente.

Al desarrollar la aplicación para Android, nuestro módulo de app es el punto final que no necesita exponer ninguna parte externa. implementation .

 implementation 'org.apache.commons:commons-lang3:3.5' 

Antes de que la compile funcione como la misma api , los beneficios de la implementation son:

  • Las dependencias no se filtran en el classpath de compilación de los consumidores, por lo que nunca dependerá de una dependencia transitiva
  • Una compilación más rápida gracias al tamaño reducido de classpath
  • Menos recompilaciones cuando las dependencias de implementación cambian: los consumidores no tendrían que ser recompilados
  • Cleaner publishing: cuando se utiliza junto con el nuevo complemento maven-publish, las librerías Java producen archivos POM que
    Distinguir exactamente entre lo que se requiere para compilar
    Biblioteca y lo que se requiere para usar la biblioteca en tiempo de ejecución (en otras palabras, no mezcle lo que se necesita para compilar la propia biblioteca y
    Lo que se necesita para compilar contra la biblioteca).
  • Dagger 2 con Android Studio 3.0 Preview (Canary 2) usando annotationProcessor en lugar de android-apt
  • Error: (81, 0) getMainOutputFile ya no es compatible. Utilice getOutputFileName si necesita determinar el nombre de archivo de la salida.
  • Cómo utilizar Data Binding y Kotlin en Android Studio 3.0.0
  • Java.lang.NoSuchMethodError: Ningún método virtual keySet ()
  • Error: Error al convertir bytecode a dex: Causa: no encontrado: Ljava / lang / Object;
  • Android Studio Preview 3.0 - Error en la instalación de la aplicación al ejecutar una aplicación instantánea
  • Vista previa de Android Studio 3.0: Studio no tiene acceso de escritura
  • RxJavaPlugins Error No encontró la clase "com.google.devtools.build.android.desugar.runtime.ThrowableExtension"
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.