A seconda del periodo dell’anno, potrebbe essere solo pochi mesi dopo il rilascio di un’app che viene annunciata una nuova versione di Android. Cosa significa questo per la tua app – si romperà tutto?

Sarà felice di sapere che la compatibilità in avanti è un forte obiettivo di Android – le app esistenti costruite con SDK precedenti non dovrebbero rompersi quando l’utente si aggiorna a una nuova versione di Android. È qui che entrano in gioco compileSdkVersion, minSdkVersion e targetSdkVersion: controllano quali API sono disponibili, qual è il livello API richiesto e quali modalità di compatibilità vengono applicate, rispettivamente.

compileSdkVersion è il tuo modo di dire a Gradle con quale versione dell’SDK Android compilare la tua app. Usare il nuovo Android SDK è un requisito per usare qualsiasi delle nuove API aggiunte in quel livello.

Si dovrebbe sottolineare che cambiare la tua compileSdkVersion non cambia il comportamento di runtime. Mentre nuovi avvertimenti/errori del compilatore possono essere presenti quando si cambia la tua compileSdkVersion, la tua compileSdkVersion non è inclusa nel tuo APK: è puramente usata in fase di compilazione. (Dovresti davvero sistemare quegli avvertimenti però – sono stati aggiunti per un motivo!)

Perciò è fortemente raccomandato che tu compili sempre con l’ultimo SDK. Avrai tutti i benefici dei nuovi controlli di compilazione sul codice esistente, eviterai le nuove API deprecate e sarai pronto ad usare le nuove API.

Nota che se usi la Support Library, compilare con l’ultimo SDK è un requisito per usare le ultime versioni della Support Library. Per esempio, per usare la Support Library 23.1.1, devi avere una compileSdkVersion di almeno 23 (i primi numeri devono coincidere!). In generale, una nuova versione della Support Library viene rilasciata insieme a una nuova versione della piattaforma, fornendo spessori di compatibilità per le nuove API aggiunte così come nuove funzionalità.

minSdkVersion

Se compileSdkVersion imposta le più recenti API disponibili per te, minSdkVersion è il limite inferiore per la tua applicazione. La minSdkVersion è uno dei segnali che il Google Play Store usa per determinare su quali dispositivi di un utente può essere installata un’applicazione.

Ha anche un ruolo importante durante lo sviluppo: per default lint viene eseguito sul vostro progetto, avvertendovi quando usate qualsiasi API al di sopra della minSdkVersion, aiutandovi ad evitare il problema di runtime del tentativo di chiamare un’API che non esiste. Controllare la versione del sistema in fase di runtime è una tecnica comune quando si usano API solo su versioni più recenti della piattaforma.

Tieni presente che le librerie che usi, come le librerie di supporto o i servizi Google Play, possono avere la loro minSdkVersion – la minSdkVersion della tua app deve essere almeno pari alla minSdkVersion delle tue dipendenze – se hai librerie che richiedono 4, 7, e 9, la tua minSdkVersion deve essere almeno 9. Nei rari casi in cui vuoi continuare ad usare una libreria con una minSdkVersion più alta della tua app (e affrontare tutti i casi limite/assicurarti che la libreria sia usata solo su versioni più recenti della piattaforma), puoi usare il marcatore tools:overrideLibrary, ma assicurati di testare accuratamente!

Quando si decide su una minSdkVersion, si dovrebbero considerare le statistiche sulle Dashboard, che ti danno uno sguardo globale su tutti i dispositivi che hanno visitato il Google Play Store nei 7 giorni precedenti – questo è il tuo potenziale pubblico quando metti un’app su Google Play. In ultima analisi, è una decisione aziendale se supportare un ulteriore 3% di dispositivi vale il tempo di sviluppo e di test necessario per garantire la migliore esperienza.

Naturalmente, se una nuova API è la chiave per la vostra intera applicazione, allora questo rende la discussione minSdkVersion un po’ più facile. Ricordate solo che anche lo 0,7% di 1,4 miliardi di dispositivi è un sacco di dispositivi.

targetSdkVersion

Il più interessante dei tre, tuttavia, è targetSdkVersion. targetSdkVersion è il modo principale in cui Android fornisce compatibilità in avanti, non applicando modifiche al comportamento a meno che la targetSdkVersion sia aggiornata. Questo ti permette di usare le nuove API (dato che hai aggiornato la tua compileSdkVersion, giusto?) prima di lavorare attraverso le modifiche al comportamento.

Molte delle modifiche al comportamento che targetSdkVersion implica sono documentate direttamente nel VERSION_CODES, ma tutti i dettagli cruenti sono anche elencati nei platform highlights di ogni release, ben collegati nella tabella API Levels.

Per esempio, le modifiche di Android 6.0 parla di come il targeting dell’API 23 fa passare la tua app al modello di permessi di runtime e i cambiamenti di comportamento di Android 4.4 spiegano in dettaglio come il targeting dell’API 19 o superiore cambia il modo in cui funzionano gli allarmi impostati con set() e setRepeating().

Con alcuni dei cambiamenti di comportamento che sono molto visibili agli utenti (la deprecazione del pulsante del menu, i permessi di runtime, ecc), l’aggiornamento al target dell’ultimo SDK dovrebbe essere una priorità assoluta per ogni app. Questo non significa che devi usare ogni nuova caratteristica introdotta, né dovresti aggiornare alla cieca la tua targetSdkVersion senza testare – per favore, per favore testa prima di aggiornare la tua targetSdkVersion! I tuoi utenti ti ringrazieranno.

Gradle e le versioni dell’SDK

Quindi impostare la corretta compileSdkVersion, minSdkVersion e targetSdkVersion è importante. Come potreste immaginare in un mondo con Gradle e Android Studio, questi valori sono integrati nel sistema degli strumenti attraverso l’inclusione nel file build.gradle del vostro modulo (disponibile anche attraverso l’opzione Struttura del progetto in Android Studio):

android {
compileSdkVersion 23
buildToolsVersion "23.0.1"
defaultConfig {
applicationId "com.example.checkyourtargetsdk"
minSdkVersion 7
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
}

La compileSdkVersion, essendo una cosa del tempo di compilazione (chi l’avrebbe mai detto!), è una delle impostazioni android insieme alla versione degli strumenti di compilazione. Gli altri due sono leggermente diversi in quanto sono dichiarati a livello di variante di build – il defaultConfig è la base per tutte le varianti di build e dove metteresti i valori predefiniti per questi, ma potresti immaginare un sistema più complicato in cui versioni specifiche della tua app hanno un minSdkVersion diverso per esempio.

minSdkVersion e targetSdkVersion differiscono anche da compileSdkVersion in quanto sono inclusi nel tuo APK finale – se dovessi guardare l’AndroidManifest.xml generato, vedresti un tag come:

<uses-sdk android:targetSdkVersion="23" android:minSdkVersion="7" />

Troverai che se metti manualmente questo nel tuo manifest, sarà ignorato quando costruisci con Gradle (anche se altri sistemi di compilazione potrebbero certamente fare affidamento sulla sua presenza).

Mettendo tutto insieme

Se sei arrivato fino alle note in grassetto, noterai una relazione tra i tre valori:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

Questo intuitivamente ha senso – se compileSdkVersion è il tuo “massimo” e minSdkVersion è il tuo “minimo” allora il tuo massimo deve essere almeno uguale al tuo minimo e l’obiettivo deve essere da qualche parte nel mezzo.

Idealmente, la relazione sarebbe più simile a questa in uno stato costante:

minSdkVersion (lowest possible) <= 
targetSdkVersion == compileSdkVersion (latest SDK)

Colpirai il pubblico più grande con una minSdkVersion bassa e avrai l’aspetto e l’azione migliore puntando e compilando con l’ultimo SDK – un ottimo modo per #BuildBetters.

Unisciti alla discussione sul post di Google+ e segui la raccolta di modelli di sviluppo Android per saperne di più!