Android Un file build.gradle di base


Esempio

Questo è un esempio di un file build.gradle predefinito in un modulo.

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 (linguaggio specifico del dominio)

Ogni blocco nel file sopra è chiamato DSL (linguaggio specifico del dominio).


plugin

La prima riga, apply plugin: 'com.android.application' , applica il plug-in Android per Gradle alla build e rende disponibile il blocco android {} per dichiarare le opzioni di generazione specifiche per Android.

Per un'applicazione Android :

apply plugin: 'com.android.application'

Per una libreria Android :

apply plugin: 'com.android.library'

Comprendere i DSL nell'esempio sopra

La seconda parte, il blocco android {...} , è il DSL Android che contiene informazioni sul tuo progetto.

Ad esempio, puoi impostare compileSdkVersion che specifica il livello dell'API Android, che dovrebbe essere usato da Gradle per compilare la tua app.
Il sub-blocco defaultConfig contiene i valori predefiniti per il manifest. Puoi override con gli aromi del prodotto .

Puoi trovare maggiori informazioni in questi esempi:


dipendenze

Il blocco delle dependencies è definito al di fuori del blocco android {...} : ciò significa che non è definito dal plug-in Android ma è Gradle standard.
Il blocco delle dependencies specifica quali librerie esterne (tipicamente le librerie Android, ma anche le librerie Java sono valide) che desideri includere nella tua app. Gradle scaricherà automaticamente queste dipendenze per te (se non è disponibile una copia locale), devi semplicemente aggiungere linee di compile simili quando desideri aggiungere un'altra libreria.

Diamo un'occhiata a una delle righe qui presenti:

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

Questa linea dice fondamentalmente

aggiungi una dipendenza dalla libreria di progettazione del supporto Android al mio progetto.

Gradle farà in modo che la libreria sia scaricata e presente in modo che tu possa usarla nella tua app e il suo codice sarà incluso anche nella tua app.

Se hai familiarità con Maven, questa sintassi è GroupId , due punti, ArtifactId , un altro punto, quindi la versione della dipendenza che desideri includere, dandoti il ​​pieno controllo sul controllo delle versioni.

Mentre è possibile specificare le versioni di artefatto usando il segno più (+), la migliore pratica è evitare di farlo; può portare a problemi se la libreria viene aggiornata con interruzioni di modifica a tua insaputa, il che probabilmente causerebbe arresti anomali nella tua app.

Puoi aggiungere diversi tipi di dipendenze:

Un'attenzione particolare dovrebbe essere dedicata alle dipendenze piatte .

Puoi trovare maggiori dettagli in questo argomento.

Nota su -v7 in appcompat-v7

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

Ciò significa semplicemente che questa libreria ( appcompat ) è compatibile con il livello API Android 7 e versioni successive.

Nota sulla junit: junit: 4.12

Questa è la dipendenza del test per il test dell'unità.


Specifica delle dipendenze specifiche per diverse configurazioni di build

È possibile specificare che una dipendenza deve essere utilizzato solo per un determinato configurazione di generazione oppure è possibile definire diverse dipendenze per i tipi di compilazione o dei sapori di prodotti (ad esempio, eseguire il debug, test o di rilascio) utilizzando debugCompile , testCompile o releaseCompile al posto della solita compile .

Questo è utile per mantenere le dipendenze test-debug-correlate fuori dalla build di rilascio, che manterrà il tuo APK release il più sottile possibile e ti aiuterà a garantire che qualsiasi informazione di debug non possa essere utilizzata per ottenere informazioni interne sulla tua app.


signingConfig

signingConfig consente di configurare Gradle in modo da includere le informazioni sul keystore e garantire che l'APK creato utilizzando queste configurazioni sia firmato e pronto per la versione Play Store.

Qui puoi trovare un argomento dedicato .

Nota : non è tuttavia consigliabile mantenere le credenziali di firma all'interno del file Gradle. Per rimuovere le configurazioni di firma, basta omettere la porzione signingConfigs .
Puoi specificarli in diversi modi:

Vedi questo argomento per maggiori dettagli: Firma APK senza esporre la password del keystore .


Puoi trovare ulteriori informazioni su Gradle per Android nell'argomento dedicato di Gradle .