Android Un fichier de base build.gradle


Exemple

Voici un exemple de fichier build.gradle par défaut dans un module.

apply plugin: 'com.android.application'

android {
    compileSdkVersion 25
    buildToolsVersion '25.0.3'

    signingConfigs {
        applicationName {
            keyAlias 'applicationName'
            keyPassword 'password'
            storeFile file('../key/applicationName.jks')
            storePassword 'keystorePassword'
        }
    }
    defaultConfig {
        applicationId 'com.company.applicationName'
        minSdkVersion 14
        targetSdkVersion 25
        versionCode 1
        versionName '1.0'
        signingConfig signingConfigs.applicationName
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])

    compile 'com.android.support:appcompat-v7:25.3.1'
    compile 'com.android.support:design:25.3.1'

    testCompile 'junit:junit:4.12'
}

DSL (langage spécifique au domaine)

Chaque bloc du fichier ci-dessus est appelé un DSL (langage spécifique au domaine).


Plugins

La première ligne, apply plugin: 'com.android.application' , applique le plug-in Android pour Gradle à la construction et rend le bloc android {} disponible pour déclarer les options de construction spécifiques à Android.

Pour une application Android :

apply plugin: 'com.android.application'

Pour une bibliothèque Android :

apply plugin: 'com.android.library'

Comprendre les DSL dans l'exemple ci-dessus

La deuxième partie, Le bloc android {...} , est la DSL Android qui contient des informations sur votre projet.

Par exemple, vous pouvez définir le compileSdkVersion qui spécifie le niveau d'API Android, qui doit être utilisé par Gradle pour compiler votre application.
Le sous-bloc defaultConfig contient les valeurs par défaut pour votre manifeste. Vous pouvez les override par des saveurs de produit .

Vous pouvez trouver plus d'informations dans ces exemples:


Les dépendances

Le bloc de dependencies est défini en dehors du bloc android {...} : cela signifie qu'il n'est pas défini par le plugin Android mais qu'il est standard.
Le bloc de dependencies spécifie les bibliothèques externes (généralement les bibliothèques Android, mais les bibliothèques Java sont également valides) que vous souhaitez inclure dans votre application. Gradle téléchargera automatiquement ces dépendances pour vous (s'il n'y a pas de copie locale disponible), il vous suffit d'ajouter des lignes de compile similaires lorsque vous souhaitez ajouter une autre bibliothèque.

Regardons l'une des lignes présentes ici:

compile 'com.android.support:design:25.3.1'

Cette ligne dit essentiellement

Ajouter une dépendance sur la bibliothèque de conception du support Android à mon projet.

Gradle s'assurera que la bibliothèque est téléchargée et présente afin que vous puissiez l'utiliser dans votre application, et son code sera également inclus dans votre application.

Si vous êtes familier avec Maven, cette syntaxe est GroupId , deux points, ArtifactId , un autre deux-points, puis la version de la dépendance que vous souhaitez inclure, vous donnant un contrôle total sur le versionnage.

Bien qu'il soit possible de spécifier des versions d'artefacts en utilisant le signe plus (+), la meilleure pratique consiste à éviter de le faire; Cela peut entraîner des problèmes si la bibliothèque est mise à jour à votre insu à l'aide de modifications, ce qui pourrait entraîner des pannes dans votre application.

Vous pouvez ajouter différents types de dépendances:

Une attention particulière devrait être consacrée aux dépendances à plat .

Vous pouvez trouver plus de détails dans cette rubrique.

Note sur le -v7 dans appcompat-v7

compile 'com.android.support:appcompat-v7:25.3.1'

Cela signifie simplement que cette bibliothèque ( appcompat ) est compatible avec l'API Android de niveau 7 et ultérieur.

Note sur le junit: junit: 4.12

Ceci est la dépendance de test pour les tests unitaires.


Spécification des dépendances spécifiques aux différentes configurations de construction

Vous pouvez spécifier qu'une dépendance ne doit être utilisé pour une certaine configuration de construction ou vous pouvez définir des dépendances pour les types de construction ou les saveurs des produits (par exemple, le débogage, de test ou libération) en utilisant debugCompile , testCompile ou releaseCompile au lieu de l'habituel compile .

Ceci est utile pour garder les dépendances liées au test et au débogage hors de votre version, ce qui maintiendra votre version APK aussi mince que possible et vous assurera que les informations de débogage ne peuvent pas être utilisées pour obtenir des informations internes sur votre application.


signatureConfig

Le signingConfig vous permet de configurer votre Gradle pour inclure keystore informations et faire en sorte que l'APK construit en utilisant ces configurations sont signés et prêts à jouer la libération de magasin.

Ici vous pouvez trouver un sujet dédié .

Remarque : Il n'est pas recommandé de conserver les informations d'identification de signature dans votre fichier Gradle. Pour supprimer les configurations de signature, omettez simplement la partie signingConfigs .
Vous pouvez les spécifier de différentes manières:

Voir cette rubrique pour plus de détails: Signer APK sans exposer le mot de passe du fichier de clés .


Vous trouverez d'autres informations sur Gradle pour Android dans le sujet dédié à Gradle .