Gradle Basics Flashcards
BUILD & TOOLING › Gradle
- What is the difference between the implementation and api dependency configurations?
- Both put the dependency on the compile and runtime classpath, but api exposes it transitively to consumers of your module, while implementation keeps it internal. Changing an implementation dependency only recompiles that module; changing an api dependency recompiles downstream consumers too.
- Why does api 'leak' a dependency transitively and when is that justified?
- api places the dependency on the consumer's compile classpath, so modules depending on yours can use that library's types directly. It is justified only when those types appear in your module's public API (return types, parameters); otherwise prefer implementation to keep boundaries clean and builds faster.
- What does the compileOnly configuration do and give an example?
- compileOnly puts a dependency on the compile classpath only, not the runtime classpath, and it is not packaged in the APK. Use it for annotation/processor APIs or libraries provided at runtime by the host environment, such as javax.annotation annotations or a provided container dependency.
- Where do testImplementation and androidTestImplementation dependencies end up?
- testImplementation is only on the classpath for local JVM unit tests (src/test), and androidTestImplementation is only for instrumented tests (src/androidTest). Neither leaks into the production app or the other test source set, keeping test libraries like JUnit, MockK, or Espresso out of the shipped APK.
- What is a Gradle version catalog and where does the file live?
- A version catalog is a central, type-safe registry of dependency and plugin coordinates and versions, defined in gradle/libs.versions.toml. Modules reference entries via accessors like libs.androidx.ktx, so versions are declared once and Android Studio provides autocomplete.
- What are the main sections of a libs.versions.toml file?
- [versions] holds named version variables, [libraries] declares dependencies (group/name plus a version or version.ref), [plugins] declares plugins by id, and [bundles] groups multiple library aliases into one accessor. A kebab-case alias like androidx-core-ktx becomes the accessor libs.androidx.core.ktx.
- How do you apply a plugin defined in a version catalog versus one that is not?
- Use alias(libs.plugins.android.application) for plugins declared in the catalog, and id("...") for plugins not in the catalog such as local convention plugins. In the top-level build file add apply false so the plugin is resolved but not applied to the root project.
- What is the difference between the Gradle build cache and the configuration cache?
- The build cache reuses task outputs (compiled classes, etc.) across builds and machines, skipping the execution phase when inputs are unchanged. The configuration cache caches the result of the configuration phase, so Gradle skips re-running build scripts when the build configuration has not changed, speeding up subsequent invocations.
- What is the purpose of settings.gradle.kts and the apply false keyword in the root build file?
- settings.gradle.kts declares the included modules (via include) and configures plugin and dependency repositories. apply false in the top-level plugins{} block declares a plugin version as a build dependency for subprojects without applying it to the root project itself.