Il controllo delle versioni è un componente fondamentale per l'upgrade e la manutenzione delle tue app strategia. Il controllo delle versioni è importante perché:
- Gli utenti devono avere informazioni specifiche sulla versione dell'app che sia installato sui suoi dispositivi e le versioni di upgrade disponibili dell'installazione.
- Altre app, incluse altre app pubblicate come una suite: devi chiedere al sistema la versione dell'app per determinare la compatibilità e identificare le dipendenze.
- Anche i servizi in cui pubblichi le tue app potrebbero dover inviare una query all'app per conoscerne la versione, in modo che possano visualizzare la versione utenti. Un servizio di pubblicazione potrebbe anche dover controllare la versione dell'app per Stabilire la compatibilità e stabilire relazioni di upgrade/downgrade.
Il sistema Android utilizza le informazioni sulla versione dell'app per proteggere rispetto ai downgrade. La sistema non utilizza le informazioni sulla versione dell'app per applicare limitazioni upgrade o compatibilità di app di terze parti. L'app deve applicare in modo forzato limitazioni di versione e informare gli utenti in merito.
Il sistema Android applica la compatibilità della versione del sistema, come
in base all'impostazione minSdk
nei file di build. Questa impostazione
consente a un'app di specificare l'API minima di sistema con cui è compatibile.
Per ulteriori informazioni sui requisiti API,
consulta Specificare i requisiti relativi ai livelli API.
I requisiti di controllo delle versioni variano a seconda del progetto. Tuttavia, molti sviluppatori considerano Il controllo delle versioni semantico è una buona base per di controllo delle versioni.
Impostare le informazioni sulla versione dell'app
Per definire le informazioni sulla versione dell'app, imposta i valori per la versione nei file di build Gradle:
Alla moda
android { namespace 'com.example.testapp' compileSdk 33 defaultConfig { applicationId "com.example.testapp" minSdk 24 targetSdk 33 versionCode 1 versionName "1.0" ... } ... } ...
Kotlin
android { namespace = "com.example.testapp" compileSdk = 33 defaultConfig { applicationId = "com.example.testapp" minSdk = 24 targetSdk = 33 versionCode = 1 versionName = "1.0" ... } ... } ...
Impostazioni della versione
Definisci i valori per entrambe le impostazioni della versione disponibili: versionCode
e
versionName
.
versionCode
- Un numero intero positivo utilizzato come numero di versione interna.
Questo numero consente di determinare se una versione è più recente
rispetto a un'altra, con numeri più alti che indicano versioni più recenti. Questo è
non il numero di versione mostrato agli utenti; questo numero viene impostato
Impostazione
versionName
. Il sistema Android utilizzaversionCode
di valore per proteggerlo dai downgrade impedendo agli utenti di installare un APK con un valore inferiore aversionCode
la versione attualmente installata sul dispositivo.Il valore è un numero intero positivo che consente ad altre app di effettuare la valutazione programmatica per controllare una relazione di upgrade o downgrade, ad esempio. Puoi imposta il valore su un qualsiasi numero intero positivo. Tuttavia, assicurati che ogni release successiva della tua app utilizza un valore maggiore.
Nota: il più grande valore consentito da Google Play
versionCode
è 2100000000.Non puoi caricare un APK sul Play Store con un
versionCode
che hai è già in uso per una versione precedente.Nota: in alcune situazioni, è consigliabile carica una versione della tua app con un valore di
versionCode
inferiore rispetto alla versione più recente alla versione più recente. Ad esempio, se pubblichi più APK, potresti avere intervalliversionCode
preimpostati per APK specifici. Per ulteriori informazioni su assegnando valoriversionCode
per più APK, consulta Assegnazione dei codici di versione:In genere, rilasci la prima versione dell'app con
versionCode
impostato su 1, poi aumenta il valore in modo monotonico con ogni release, indipendentemente dal fatto che rappresenti una release principale minore uscita. Ciò significa che il valoreversionCode
necessariamente la versione di release dell'app è visibile all'utente. Questa versione non deve essere visualizzata per le app e i servizi di pubblicazione e un valore aggiunto per gli utenti. versionName
Una stringa utilizzata come numero di versione mostrato a utenti. Questa impostazione può essere specificata come stringa non elaborata o come riferimento a una della stringa.
Il valore è una stringa per consentirti di descrivere la versione dell'app come <maggiore>.<minore>.<punto> stringa o come qualsiasi altro tipo l'identificatore della versione assoluta o relativa.
versionName
è l'unico valore mostrati agli utenti.
Definisci i valori della versione
Puoi definire i valori predefiniti per queste impostazioni includendole nel
Blocco defaultConfig {}
, nidificato all'interno del android {}
blocco del file build.gradle
o build.gradle.kts
del modulo. Puoi
poi sostituisci questi valori predefiniti per le diverse versioni dell'app definendo
per singoli tipi di build o versioni di prodotti. Il file seguente mostra
Impostazioni versionCode
e versionName
in
defaultConfig {}
, oltre al blocco productFlavors {}
.
Questi valori vengono poi uniti nel file manifest dell'app durante il processo di compilazione.
Alla moda
android { ... defaultConfig { ... versionCode 2 versionName "1.1" } productFlavors { demo { ... versionName "1.1-demo" } full { ... } } }
Kotlin
android { ... defaultConfig { ... versionCode = 2 versionName = "1.1" } productFlavors { create("demo") { ... versionName = "1.1-demo" } create("full") { ... } } }
Nel blocco defaultConfig {}
di questo esempio,
Il valore versionCode
indica che l'APK corrente contiene
seconda release dell'app e la stringa versionName
specifica
che verrà mostrata agli utenti come versione 1.1. Questo file definisce anche due versioni di prodotto:
"demo" e "piena". Dal momento che la categoria "demo" sapore di prodotto definisce versionName
come
"1.1-demo", "demo" build usa questo versionName
al posto del valore predefinito.
Il "completo" blocco flavor del prodotto non definisce versionName
, quindi
utilizza il valore predefinito "1.1".
Nota: se la tua app definisce la versione dell'app direttamente nel
<manifest>
elemento, i valori della versione nella build Gradle
le impostazioni del file manifest. Inoltre, la definizione di queste
nei file di build Gradle consente di specificare diversi valori per
diverse versioni dell'app. Per una maggiore flessibilità e per evitare
la potenziale sovrascrittura quando il file manifest viene unito, rimuovili
attributi dell'elemento <manifest>
e definisci
le impostazioni della versione nei file di build Gradle.
Il framework Android fornisce un'API che ti consente di eseguire query sul sistema
per informazioni sulla versione della tua app. Per ottenere informazioni sulla versione,
utilizza la
PackageManager.getPackageInfo(java.lang.String, int)
.
Specifica i requisiti relativi ai livelli API
Se la tua app richiede una versione minima specifica di Android
piattaforma, puoi specificare il requisito di versione come impostazioni a livello di API
nel file build.gradle
o build.gradle.kts
dell'app. Durante la creazione
queste impostazioni vengono unite nel file manifest dell'app. Specifica del livello API
assicura che la tua app possa essere installata solo su dispositivi che:
con una versione compatibile della piattaforma Android.
Nota: se specifichi i requisiti relativi ai livelli API direttamente nel
manifest dell'app, le impostazioni corrispondenti nei file di build
le impostazioni nel file manifest. Inoltre, la definizione di queste
nei file di build Gradle consente di specificare diversi valori per
diverse versioni dell'app. Per una maggiore flessibilità e per evitare
la potenziale sovrascrittura quando il file manifest viene unito, rimuovili
attributi dell'elemento <uses-sdk>
e definisci la tua API
impostazioni di livello nei file di build Gradle.
Sono disponibili due impostazioni di livello API:
minSdk
: la versione minima della piattaforma Android su cui verrà eseguita l'app, specificato dall'identificatore del livello API della piattaforma.targetSdk
: il livello API su cui è progettata l'app. In alcuni casi, questo consente per utilizzare elementi manifest o comportamenti definiti nell'app A livello di API, invece di essere limitato all'utilizzo solo di quelli definiti per il livello API minimo.
Per specificare requisiti predefiniti per i livelli API in un build.gradle
o
build.gradle.kts
, aggiungi una o più impostazioni a livello di API al
Blocco defaultConfig{}
, nidificato all'interno del blocco android {}
. Puoi
anche questi valori predefiniti per diversi
delle tue app aggiungendo le impostazioni ai tipi di build o alle versioni dei prodotti.
Il seguente file specifica i valori predefiniti
Impostazioni minSdk
e targetSdk
in
Blocco defaultConfig {}
con override minSdk
per una versione di prodotto:
Alla moda
android { ... defaultConfig { ... minSdk 21 targetSdk 33 } productFlavors { main { ... } afterNougat { ... minSdk 24 } } }
Kotlin
android { ... defaultConfig { ... minSdk = 21 targetSdk = 33 } productFlavors { create("main") { ... } create("afterNougat") { ... minSdk = 24 } } }
Quando ti prepari a installare l'app, il sistema controlla il valore
queste impostazioni e le confronta con la versione del sistema. Se
Il valore di minSdk
è maggiore della versione di sistema, il valore
impedisce l'installazione dell'app.
Se non specifichi queste impostazioni, il sistema presuppone che la tua app sia
compatibili con tutte le versioni della piattaforma. Equivale a impostare minSdk
su
1
.
Per ulteriori informazioni, consulta la sezione Che cos'è il livello API?. Per le impostazioni di build Gradle, consulta Configurare le varianti di build.