Quando imposti targetSdkVersion = "xx", stai certificando che la tua app funziona correttamente (ad esempio, è stata accuratamente e correttamente testata) a livello di API xx.
Una versione di Android in esecuzione a un livello API superiore a xx applicherà automaticamente il codice di compatibilità per supportare tutte le funzionalità su cui potresti fare affidamento che erano disponibili al precedente livello API xx, ma che sono ora obsolete al livello superiore di quella versione Android.
Al contrario, se si sta utilizzando tutte le funzioni che sono diventati obsoleti in o prima a livello di xx, il codice di compatibilità sarà non essere applicata automaticamente da versioni del sistema operativo a livelli più alti di API (che non comprendono più quelle caratteristiche) per supportare tali usi. In tale situazione, il proprio codice deve avere clausole speciali di casi che prova il livello di API e, se il livello di sistema operativo rilevato è uno superiore che non ha più la funzione API data, il codice deve utilizzare funzioni alternative che sono disponibili presso i esecuzione del sistema operativo Livello API.
Se non riesce a farlo, alcune funzioni dell'interfaccia potrebbero semplicemente non apparire che normalmente attiverebbero eventi all'interno del tuo codice e potresti non avere una funzionalità di interfaccia critica di cui l'utente ha bisogno per attivare quegli eventi e accedere alle loro funzionalità (come nel esempio sotto).
Come indicato in altre risposte, è possibile impostare targetSdkVersion su un valore superiore a minSdkVersion se si desidera utilizzare alcune funzioni API inizialmente definite a livelli API superiori rispetto a minSdkVersion e si sono presi provvedimenti per assicurarsi che il codice sia in grado di rilevare e gestire l'assenza di tali funzionalità in livelli inferiori rispetto a targetSdkVersion.
Per avvertire gli sviluppatori di testare in modo specifico il livello minimo di API richiesto per utilizzare una funzione, il compilatore genererà un errore (non solo un avviso) se il codice contiene una chiamata a qualsiasi metodo definito a un livello API successivo rispetto a minSdkVersion, anche se targetSdkVersion è maggiore o uguale al livello API in cui il metodo è stato reso disponibile per la prima volta. Per rimuovere questo errore, la direttiva del compilatore
@TargetApi(nn)
dice al compilatore che il codice che rientra nell'ambito di applicazione di tale direttiva (che precederà un metodo o una classe) è stato scritto per testare un livello API di almeno nn prima di chiamare qualsiasi metodo che dipende dal fatto di avere almeno quel livello API . Ad esempio, il codice seguente definisce un metodo che può essere chiamato dal codice all'interno di un'app che ha una minSdkVersion inferiore a 11 e una targetSdkVersion di 11 o superiore:
@TargetApi(11)
public void refreshActionBarIfApi11OrHigher() {
//If the API is 11 or higher, set up the actionBar and display it
if(Build.VERSION.SDK_INT >= 11) {
//ActionBar only exists at API level 11 or higher
ActionBar actionBar = getActionBar();
//This should cause onPrepareOptionsMenu() to be called.
// In versions of the API prior to 11, this only occurred when the user pressed
// the dedicated menu button, but at level 11 and above, the action bar is
// typically displayed continuously and so you will need to call this
// each time the options on your menu change.
invalidateOptionsMenu();
//Show the bar
actionBar.show();
}
}
Si potrebbe anche voler dichiarare un targetSdkVersion più elevato se si fosse provato a quel livello più elevato e tutto ha funzionato, anche se sono stati non utilizzano tutte le funzioni da un livello di API superiore al vostro minSdkVersion. Questo sarebbe solo per evitare il sovraccarico di accedere al codice di compatibilità destinato ad adattarsi dal livello target fino al livello minimo, dal momento che si sarebbe confermato (attraverso i test) che tale adattamento non era richiesto.
Un esempio di una funzionalità dell'interfaccia utente che dipende dalla destinazione targetSdkVersion sarebbe il pulsante del menu a tre punti verticali che appare sulla barra di stato delle app con targetSdkVersion inferiore a 11, quando tali app sono in esecuzione con API 11 e successive. Se la tua app ha una targetSdkVersion di 10 o inferiore, si presume che l'interfaccia della tua app dipenda dall'esistenza di un pulsante di menu dedicato, quindi il pulsante a tre punti sembra prendere il posto dell'hardware dedicato precedente e / o delle versioni su schermo di quel pulsante (ad esempio, come si vede in Gingerbread) quando il sistema operativo ha un livello API più elevato per il quale non è più previsto un pulsante di menu dedicato sul dispositivo. Tuttavia, se imposti targetSdkVersion della tua app su 11 o superiore, si presume che tu abbia sfruttato le funzionalità introdotte a quel livello che sostituiscono il pulsante di menu dedicato (e. g., la barra delle azioni) o che hai altrimenti eluso la necessità di avere un pulsante del menu di sistema; di conseguenza, il "pulsante di compatibilità" del menu a tre punti verticali scompare. In tal caso, se l'utente non riesce a trovare un pulsante di menu, non può premerlo e ciò, a sua volta, significa che il comando onCreateOptionsMenu (menu) della tua attività potrebbe non essere mai richiamato, il che, a sua volta, significa che una parte significativa della funzionalità della tua app potrebbe essere privata della sua interfaccia utente. A meno che, naturalmente, non sia stata implementata la barra delle azioni o altri mezzi alternativi per consentire all'utente di accedere a queste funzionalità. non trova un pulsante menu, non può premerlo e ciò, a sua volta, significa che la sostituzione della tua attività onCreateOptionsMenu (menu) potrebbe non essere mai invocata, il che, a sua volta, significa che una parte significativa della funzionalità della tua app potrebbe essere privato della sua interfaccia utente. A meno che, naturalmente, non sia stata implementata la barra delle azioni o altri mezzi alternativi per consentire all'utente di accedere a queste funzionalità. non trova un pulsante menu, non può premerlo e ciò, a sua volta, significa che la sostituzione della tua attività onCreateOptionsMenu (menu) potrebbe non essere mai invocata, il che, a sua volta, significa che una parte significativa della funzionalità della tua app potrebbe essere privato della sua interfaccia utente. A meno che, naturalmente, non sia stata implementata la barra delle azioni o altri mezzi alternativi per consentire all'utente di accedere a queste funzionalità.
minSdkVersion, al contrario, afferma che la versione del sistema operativo di un dispositivo deve avere almeno quel livello API per eseguire la tua app. Ciò influisce su quali dispositivi sono in grado di vedere e scaricare la tua app quando si trova nell'app store di Google Play (e possibilmente anche in altri store di app). È un modo per affermare che l'app si basa su funzionalità del sistema operativo (API o altro) stabilite a quel livello e non ha un modo accettabile per gestire l'assenza di tali funzionalità.
Un esempio di utilizzo di minSdkVersion per garantire la presenza di una funzionalità non correlata all'API potrebbe essere l'impostazione di minSdkVersion su 8 per garantire che l'app venga eseguita solo su una versione abilitata per JIT dell'interprete Dalvik (dall'introduzione di JIT all'interprete Android a livello di API 8). Poiché le prestazioni di un interprete abilitato per JIT possono essere fino a cinque volte superiori a quelle che mancano di tale funzionalità, se l'app fa un uso intensivo del processore, potrebbe essere necessario richiedere il livello API 8 o superiore per garantire prestazioni adeguate.
