lightbulb_outline Please take our October 2018 developer survey. Start survey

Sugerencias y recetas de Gradle

Gradle y el complemento de Android para Gradle ofrecen una forma flexible de compilar, crear y empaquetar tu app o tu biblioteca de Android. En esta página, encontrarás algunas sugerencias y configuraciones útiles que te ayudarán a sacar el mayor provecho de cada compilación. Si deseas obtener más información sobre cómo agilizar tus compilaciones, lee Optimizar tu velocidad de compilación.

Si recién empiezas a usar Gradle, aprende los conceptos básicos leyendo Configurar tu compilación. También puedes consultar la Documentación de referencia de DSL del complemento de Android para obtener más información sobre las propiedades que se usan en esta página.

Administrar proyectos y orígenes

A continuación, te mostramos algunas configuraciones para administrar los módulos de tu proyecto y sus orígenes. Para obtener más información sobre cómo crear y administrar proyectos y módulos, lee Información general sobre proyectos.

Cambiar configuraciones predeterminadas de conjuntos de orígenes

Puedes usar el bloque sourceSets en el archivo build.gradle de nivel de módulo para cambiar la ubicación en la que Gradle buscará agrupar archivos para cada componente de un conjunto de orígenes.

android {
  ...
  sourceSets {
    // Encapsulates configurations for the main source set.
    main {
      // Changes the directory for Java sources. The default directory is
      // 'src/main/java'.
      java.srcDirs = ['other/java']

      // When you list multiple directories, Gradle uses all of them to collect
      // sources. You should avoid specifying a directory which is a parent to one
      // or more other directories you specify.
      res.srcDirs = ['other/res1', 'other/res2']

      // For each source set, you can specify only one Android manifest.
      // The following points Gradle to a different manifest for this source set.
      manifest.srcFile 'other/AndroidManifest.xml'
      ...
    }

    // Create additional blocks to configure other source sets.
    androidTest {

      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying
      // the configuration below for the androidTest source set, Gradle looks for
      // Java sources only in the src/tests/java/ directory.
      setRoot 'src/tests'
      ...
    }
  }
}
...

Configurar propiedades de todo un proyecto

Para los proyectos que incluyen varios módulos, puede ser útil definir propiedades en el nivel del proyecto y compartirlas en todos los módulos. Puedes hacerlo agregando propiedades adicionales al bloque ext en el archivo build.gradle de nivel superior.

buildscript {...}
allprojects {...}

// This block encapsulates custom properties and makes them available to all
// modules in the project.
ext {
    // The following are only a few examples of the types of properties you can define.
    compileSdkVersion = 26
    buildToolsVersion = "28.0.3"

    // You can also use this to specify versions for dependencies. Having consistent
    // versions between modules can avoid behavior conflicts.
    supportLibVersion = "28.0.0"
    ...
}
...

Para acceder a esas propiedades desde un módulo en el mismo proyecto, usa la siguiente sintaxis en el archivo build.gradle de nivel del módulo.

android {
  // Use the following syntax to access properties you defined at the project level:
  // rootProject.ext.property_name
  compileSdkVersion rootProject.ext.compileSdkVersion
  buildToolsVersion rootProject.ext.buildToolsVersion
  ...
}
...
dependencies {
    compile "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
    ...
}

Administrar bibliotecas y dependencias

Gradle ofrece un mecanismo sólido para administrar dependencias, así sean bibliotecas remotas o módulos de una biblioteca local.

Apuntar a compilaciones específicas con configuraciones de dependencias

Si deseas una dependencia solo para un conjunto de orígenes de una variante de compilación o un conjunto de orígenes de prueba específico, capitaliza el nombre de la configuración de dependencias y agrégale un prefijo con el nombre de la variante de compilación o el conjunto de orígenes de prueba.

android {...}

// Creates Gradle dependency configurations to use in the dependencies block.
configurations {
  // For variants that combine a product flavor and build type, you need to
  // intitialize a placeholder for its dependency configuration.
  freeDebugApk {}
  ...
}

dependencies {
    // Adds a compile dependency only to the "free" product flavor.
    freeCompile 'com.google.firebase:firebase-ads:9.8.0'
    // Adds an apk dependency only to the "freeDebug" build variant.
    freeDebugApk fileTree(dir: 'libs', include: ['*.jar'])
    // Adds a remote binary dependency only for local tests.
    testCompile 'junit:junit:4.12'
    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestCompile 'com.android.support.test.espresso:espresso-core:3.0.2'
}

Publicar variantes no predeterminadas de tu biblioteca

Puedes modificar la variante de biblioteca predeterminada que Gradle publica en otros módulos agregando lo siguiente al archivo build.gradle de la biblioteca:

android {
  ...
  // If the library configures product flavors, you must specify
  // a build variant by its full configuration name. The following
  // sets the "demoDebug" build variant as the default version
  // of the library that Gradle should publish.
  defaultPublishConfig "demoDebug"
}

También puedes indicar a Gradle que publique todas las variantes disponibles de la biblioteca.

android {
  ...
  // Note that this might increase build times because Gradle must
  // build multiple AARs, instead of only one.
  publishNonDefault true
}

Al establecer publishNonDefault true, puedes configurar el archivo build.gradle de un módulo de la app de modo que cada una de sus variantes use solo la versión de la biblioteca que necesite.

android {...}
...

// Creates Gradle dependency configurations to use in the dependencies block.
configurations {
  // Initializes placeholders for the demoDebugCompile and fullReleaseCompile
  // dependency configurations.
  demoDebugCompile {}
  fullReleaseCompile {}
  ...
}

dependencies {
  // If the library configures multiple build variants using product flavors,
  // you must target one of the library's variants using its full configuration name.
  demoDebugCompile project(path: ':my-library-module', configuration: 'demoDebug')
  fullReleaseCompile project(path: ':my-library-module', configuration: 'fullRelease')
  ...
}

Crear diferentes versiones de tu app

Gradle y el complemento de Android te permiten crear diferentes versiones de tu app a partir de un solo módulo configurando variantes de compilación.

Configurar compatibilidad con varios APK

Con el complemento de Android, puedes compilar varios APK orientados a la densidad de pantalla o la ABI y aprovechar la compatibilidad con varios APK de Google Play.

Configurar APK independientes según la densidad de la pantalla

Para crear APK independientes para diferentes densidades de pantalla, agrega el bloque android.splits.density al archivo build.gradle de tu módulo.

android {
  ...
  splits {

    // Configures multiple APKs based on screen density.
    density {

      // Enables building multiple APKs.
      enable true

      // Specifies a list of screen densities Gradle should not create APKs for.
      exclude "ldpi", "mdpi"

      // Alternatively, you can use the following to clear the default list of
      // screen densities and specify only the screen densities you want to build
      // APKs for:
      // reset()
      // include "hdpi", "xhdpi", "xxhdpi", "xxxhdpi"

      // Specifies a list of compatible screen size settings. This property
      // configures the <compatible-screens> element in the manifest. You
      // typically don't need to configure this manifest property, but it's
      // important when building multiple APKs based on screen density.
      compatibleScreens 'normal', 'large', 'xlarge'
    }
  }
}

Configurar APK independientes según el tipo de ABI

Para crear APK independientes para cada ABI, agrega el bloque android.splits.abi al archivo build.gradle de tu módulo.

android {
  ...
  splits {

    // Configures multiple APKs based on ABI.
    abi {

      // Enables building multiple APKs.
      enable true

      // By default all ABIs are included, so use reset() and include to specify that we only
      // want APKs for x86, armeabi-v7a, and mips.
      reset()

      // Specifies a list of ABIs that Gradle should create APKs for.
      include "x86", "armeabi-v7a", "mips"

      // Specify that we want to also generate a universal APK that includes all ABIs.
      universalApk true
    }
  }
}

Configurar códigos de versión dinámicos

De forma predeterminada, cuando Gradle genera APK para tu proyecto, cada APK tiene la misma información de versión, tal como se especifica en el archivo build.gradle de nivel de módulo. Debido a que Google Play Store no permite para la misma app varios APK con la misma información de versión, debes asegurarte de que cada APK tenga su propio versionCode único antes de cargarlo en Play Store.

Puedes hacer esto con lógica de compilación personalizada que asigne un código de versión diferente a cada APK en el momento de la compilación. Por ejemplo, al crear APK independientes para cada ABI, la generación automática de versiones para los APK tendrá el siguiente aspecto:

android {
  ...
  defaultConfig {
    ...
    versionCode 4
  }
  splits {
    ...
  }
}

// Map for the version code that gives each ABI a value.
ext.abiCodes = ['armeabi-v7a':1, mips:2, x86:3]

// For per-density APKs, create a similar map like this:
// ext.densityCodes = ['hdpi': 1, 'xhdpi': 2, 'xxhdpi': 3, 'xxxhdpi': 4]

import com.android.build.OutputFile

// For each APK output variant, override versionCode with a combination of
// ext.abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode
// is equal to defaultConfig.versionCode. If you configure product flavors that
// define their own versionCode, variant.versionCode uses that value instead.
android.applicationVariants.all { variant ->

  // Assigns a different version code for each output APK
  // other than the universal APK.
  variant.outputs.each { output ->

    // Stores the value of ext.abiCodes that is associated with the ABI for this variant.
    def baseAbiVersionCode =
            // Determines the ABI for this variant and returns the mapped value.
            project.ext.abiCodes.get(output.getFilter(OutputFile.ABI))

    // Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes,
    // the following code does not override the version code for universal APKs.
    // However, because we want universal APKs to have the lowest version code,
    // this outcome is desirable.
    if (baseAbiVersionCode != null) {

      // Assigns the new version code to versionCodeOverride, which changes the version code
      // for only the output APK, not for the variant itself. Skipping this step simply
      // causes Gradle to use the value of variant.versionCode for the APK.
      output.versionCodeOverride =
              baseAbiVersionCode * 1000 + variant.versionCode
    }
  }
}

Combinar varios tipos de productos

En algunos casos, es posible que desees combinar configuraciones de varios tipos de productos. Para hacerlo, el complemento de Android para Gradle te permite crear grupos de tipos de productos llamados dimensiones de tipos.

En el siguiente ejemplo de código, se usa la propiedad flavorDimensions a fin de crear una dimensión de tipo “mode” para agrupar los tipos de productos “full” y “demo”, y una de tipo “api” para agrupar configuraciones de tipos de productos en función del nivel de API. Luego, Gradle combina los tipos de productos de la dimensión “mode” con los de la dimensión “api”.

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list each dimension determines its priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property above--the first dimension has a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion '24'
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level. To learn more about assigning version codes to
      // support app updates and uploading to Google Play, read Multiple APK Support
      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion '23'
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion '21'
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

Filtrar variantes

Puedes filtrar variantes de compilación que no desees usando el bloque variantFilter del archivo build.gradle del módulo. En el siguiente ejemplo de código, se indica a Gradle no compilar variantes que combinen los tipos de productos “minApi21” y “demo”:

android {
 ...
 buildTypes {...}

 flavorDimensions "api", "mode"
 productFlavors {
    demo {...}
    full {...}
    minApi24 {...}
    minApi23 {...}
    minApi21 {...}
  }

  variantFilter { variant ->
    def names = variant.flavors*.name
    // To check for a build type instead, use variant.buildType.name == "buildType"
    if (names.contains("minApi21") && names.contains("demo")) {
      // Gradle ignores any variants that satisfy the conditions above.
      setIgnore(true)
    }
  }
}
...

Probar tu app

Para obtener más información sobre cómo ejecutar pruebas de unidades locales e integradas, lee Probar tu app.

Configurar opciones de lint

Puedes configurar algunas opciones de lint usando el bloque lintOptions de tu archivo build.gradle de nivel de módulo. Para obtener más información sobre cómo usar lint para tu proyecto de Android, lee Mejorar tu código con Lint.

android {
  ...
  lintOptions {
    // Turns off checks for the issue IDs you specify.
    disable 'TypographyFractions','TypographyQuotes'
    // Turns on checks for the issue IDs you specify. These checks are in
    // addition to the default lint checks.
    enable 'RtlHardcoded', 'RtlCompat', 'RtlEnabled'
    // To enable checks for only a subset of issue IDs and ignore all others,
    // list the issue IDs with the 'check' property instead. This property overrides
    // any issue IDs you enable or disable using the properties above.
    check 'NewApi', 'InlinedApi'
    // If set to true, turns off analysis progress reporting by lint.
    quiet true
    // if set to true (default), stops the build if errors are found.
    abortOnError false
    // if true, only report errors.
    ignoreWarnings true
  }
}
...

Configurar ajustes del manifest de instrumentación

Cuando Gradle compila tu APK de prueba, genera automáticamente el archivo AndroidManifest.xml y lo configura con el nodo <instrumentation>. Puedes cambiar algunas configuraciones para este nodo creando otro archivo de manifest en el conjunto de orígenes de prueba o configurando tu archivo build.gradle de nivel de módulo, como se muestra en el siguiente ejemplo de código.

android {
  ...
  // Each product flavor you configure can override properties in the
  // defaultConfig block. To learn more, go to Configure Product Flavors.
  defaultConfig {
    ...
    // Specifies the application ID for the test APK.
    testApplicationId "com.test.foo"
    // Specifies the fully-qualified class name of the test instrumentation runner.
    testInstrumentationRunner "android.test.InstrumentationTestRunner"
    // If set to 'true', enables the instrumentation class to start and stop profiling.
    // If set to false (default), profiling occurs the entire time the instrumentation
    // class is running.
    testHandleProfiling true
    // If set to 'true', indicates that the Android system should run the instrumentation
    // class as a functional test. The default value is 'false'
    testFunctionalTest true
  }
}
...

Cambiar el tipo de compilación de pruebas

De forma predeterminada, todas las pruebas se ejecutan en el tipo de compilación de depuración. Puedes cambiar esto a otro tipo de compilación usando la propiedad testBuildType en tu archivo de nivel de módulo build.gradle. Por ejemplo, si deseas ejecutar tus pruebas en tu tipo de compilación “staging”, edita el archivo como se muestra en el siguiente fragmento.

android {
    ...
    testBuildType "staging"
}

Configurar opciones de prueba de Gradle

Para especificar opciones que modifiquen el modo en que Gradle ejecuta todas tus pruebas, configura el bloque testOptions del archivo build.gradle de nivel de módulo.

android {
  ...
  // Encapsulates options for running tests.
  testOptions {
    // Changes the directory where Gradle saves test reports. By default, Gradle saves test reports
    // in the path_to_your_project/module_name/build/outputs/reports/ directory.
    // '$rootDir' sets the path relative to the root directory of the current project.
    reportDir "$rootDir/test-reports"
    // Changes the directory where Gradle saves test results. By default, Gradle saves test results
    // in the path_to_your_project/module_name/build/outputs/test-results/ directory.
    // '$rootDir' sets the path relative to the root directory of the current project.
    resultsDir "$rootDir/test-results"
  }
}

Si deseas especificar opciones para pruebas de unidades locales únicamente, configura el bloque testOptions.unitTests.

android {
  ...
  testOptions {
    ...
    // Encapsulates options for local unit tests.
    unitTests {
      // By default, local unit tests throw an exception any time the code you are testing tries to access
      // Android platform APIs (unless you mock Android dependencies yourself or with a testing
      // framework like Mockito). However, you can enable the following property so that the test
      // returns either null or zero when accessing platform APIs, rather than throwing an exception.
      returnDefaultValues true

      // Encapsulates options for controlling how Gradle executes local unit tests. For a list
      // of all the options you can specify, read Gradle's reference documentation.
      all {
        // Sets JVM argument(s) for the test JVM(s).
        jvmArgs '-XX:MaxPermSize=256m'

        // You can also check the task name to apply options to only the tests you specify.
        if (it.name == 'testDebugUnitTest') {
          systemProperty 'debug', 'true'
        }
      }
    }
  }
}

Optimizar tu compilación

En esta sección se proporcionan algunas configuraciones que ayudan a acelerar tus compilaciones completas e incrementales.

Reducir tu código

Android Studio usa ProGuard para reducir tu código. Para proyectos nuevos, Android Studio usa un archivo de configuración predeterminado (proguard-android.txt) de tools/proguard/folder de Android SDK. Para reducir el código aún más, prueba el archivo proguard-android-optimize.txt que se encuentra en la misma ubicación.

android {
  buildTypes {
    release {
      minifyEnabled true
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                                           'proguard-rules.pro'
    }
  }
  ...
}
...

Si deseas agregar reglas de ProGuard específicas para cada variante de compilación, configura la propiedad adicional proguardFiles para cada tipo. En el siguiente ejemplo, se agrega flavor2-rules.pro a "flavor2". La versión de lanzamiento de “flavor2” usa las tres reglas de ProGuard ya que también se aplican las del bloque de lanzamiento.

android {
  ...
  buildTypes {
    release {
      minifyEnabled true
      proguardFiles getDefaultProguardFile('proguard-android.txt'),
             'proguard-rules.pro'
    }
  }
  productFlavors {
    flavor1 {
      ...
    }
    flavor2 {
      proguardFile 'flavor2-rules.pro'
    }
  }
}
...

Habilitar la reducción de código con Instant Run

Para habilitar la reducción de código con Instant Run, simplemente fija useProguard en false (y mantén minifyEnabled establecido en true). Esto usa un reductor de código experimental que no oculta ni optimiza tu código (de modo que debes habilitar este reductor solo para el tipo de compilación “debug”).

android {
  buildTypes {
    debug {
      minifyEnabled true
      useProguard false
      proguardFiles getDefaultProguardFile('proguard-android.txt'),
              'proguard-rules.pro'
    }
    release {
      minifyEnabled true
      proguardFiles getDefaultProguardFile('proguard-android.txt'),
              'proguard-rules.pro'
    }
  }
}

Configurar opciones de DEX

Usa las siguientes propiedades para mejorar los tiempos de compilación cuando Gradle compile tu código en archivos DEX.

android {
  ...
  dexOptions {
    // Sets the maximum number of DEX processes
    // that can be started concurrently.
    maxProcessCount 8
    // Sets the maximum memory allocation pool size
    // for the dex operation.
    javaMaxHeapSize "2g"
    // Enables Gradle to pre-dex library dependencies.
    preDexLibraries true
  }
}

Publicar tu app

Para obtener más información sobre cómo publicar tu app en Google Play, lee Publicar tu app.

Firmar tu app

Si bien Android Studio ofrece una forma fácil de configurar la firma de compilaciones de versión desde la IU, puedes configurar manualmente el bloque signingConfigs del archivo build.gradle de tu módulo:

android {
  ...
  defaultConfig { ... }

  // Encapsulates signing configurations.
  signingConfigs {
    // Creates a signing configuration called "release".
    release {
      // Specifies the path to your keystore file.
      storeFile file("my-release-key.jks")
      // Specifies the password for your keystore.
      storePassword "password"
      // Specifies the identifying name for your key.
      keyAlias "my-alias"
      // Specifies the password for your key.
      keyPassword "password"
    }
  }
  buildTypes {
    release {
      // Adds the "release" signing configuration to the release build type.
      signingConfig signingConfigs.release
      ...
    }
  }
}
...

Quitar información de firma privada de tu proyecto

De forma predeterminada, las configuraciones de firma se registran en texto sin formato en el archivo build.gradle del módulo. Si trabajas con un equipo o un proyecto de código abierto, puedes quitar esa información confidencial de los archivos de compilación como se indica a continuación.

  1. Crea un archivo llamado keystore.properties en el directorio raíz de tu proyecto e incluye la siguiente información:
    storePassword=myStorePassword
    keyPassword=myKeyPassword
    keyAlias=myKeyAlias
    storeFile=myStoreFileLocation
    
  2. En tu archivo build.gradle, carga el archivo keystore.properties de la siguiente manera (debes hacerlo antes del bloque Android):
    // Creates a variable called keystorePropertiesFile, and initializes it to the
    // keystore.properties file.
    def keystorePropertiesFile = rootProject.file("keystore.properties")
    
    // Initializes a new Properties() object called keystoreProperties.
    def keystoreProperties = new Properties()
    
    // Loads the keystore.properties file into the keystoreProperties object.
    keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
    
    android {
      ...
    }
    ...
    
  3. Ingresa la información de firma guardada en el objeto keystoreProperties:
    android {
      signingConfigs {
        config {
          keyAlias keystoreProperties['keyAlias']
          keyPassword keystoreProperties['keyPassword']
          storeFile file(keystoreProperties['storeFile'])
          storePassword keystoreProperties['storePassword']
        }
      }
      ...
    }
    ...
    
  4. Haz clic en Sync Now en la barra de notificaciones.

Para obtener más información sobre cómo firmar una app, lee Firmar tu app.

Simplificar el desarrollo de apps

Las siguientes sugerencias ayudan a facilitar el desarrollo de tu app para Android.

Compartir campos personalizados y valores de recursos con el código de tu app

En el momento de la compilación, Gradle genera la clase BuildConfig de modo que el código de tu app pueda explorar información sobre la compilación actual. También puedes agregar campos personalizados a la clase BuildConfig desde tu archivo de configuración de la compilación de Gradle, usando el método buildConfigField(), y acceder a esos valores en el código de tiempo de ejecución de tu app. Del mismo modo, puedes agregar valores de recursos de la app con resValue().

android {
  ...
  buildTypes {
    release {
      // These values are defined only for the release build, which
      // is typically used for full builds and continuous builds.
      buildConfigField("String", "BUILD_TIME", "\"${minutesSinceEpoch}\"")
      resValue("string", "build_time", "${minutesSinceEpoch}")
      ...
    }
    debug {
      // Use static values for incremental builds to ensure that
      // resource files and BuildConfig aren't rebuilt with each run.
      // If they were dynamic, they would prevent certain benefits of
      // Instant Run as well as Gradle UP-TO-DATE checks.
      buildConfigField("String", "BUILD_TIME", "\"0\"")
      resValue("string", "build_time", "0")
    }
  }
}
...

En el código de tu app, puedes acceder a las propiedades de la siguiente manera:

...
Log.i(TAG, BuildConfig.BUILD_TIME);
Log.i(TAG, getString(R.string.build_time));

Compartir propiedades con el manifest

En algunos casos, es posible que debas declarar la misma propiedad en tu manifest y en tu código (por ejemplo, al declarar autoridades para FileProvider). En lugar de actualizar la misma propiedad en varias ubicaciones para reflejar un cambio, define una sola propiedad en el archivo build.gradle de tu módulo a fin de que esté disponible para el manifest y tu código, como se muestra en el siguiente ejemplo. Para obtener más información, lee Incluir variables de compilación en el manifiesto.

android {
  // For settings specific to a product flavor, configure these properties
  // for each flavor in the productFlavors block.
  defaultConfig {
    // Creates a property for the FileProvider authority.
    def filesAuthorityValue = applicationId + ".files"
    // Creates a placeholder property to use in the manifest.
    manifestPlaceholders =
      [filesAuthority: filesAuthorityValue]
      // Adds a new field for the authority to the BuildConfig class.
      buildConfigField("String",
                       "FILES_AUTHORITY",
                       "\"${filesAuthorityValue}\"")
  }
  ...
}
...

En tu manifest, accede al marcador de posición de la siguiente manera:

<manifest>
  ...
  <application>
    ...
    <provider
      android:name="android.support.v4.content.FileProvider"
      android:authorities="${filesAuthority}"
      android:exported="false"
      android:grantUriPermissions="true">
      ...
    </provider>
  </application>
</manifest>

El acceso al campo FILES_AUTHORITY en el código de tu app se verá así:

...
Uri contentUri = FileProvider.getUriForFile(getContext(),
  BuildConfig.FILES_AUTHORITY,
  myFile);