2014-09-02 18 views
9

Qual è la differenza tra "min sdk, target sdk e compile con" in Android?Qual è la differenza tra "min sdk, target sdk e compile con"? in Android

Qual è la differenza tra "sdk minimo, target sdk e compile con", che vengono visualizzati quando provo a creare un nuovo progetto di applicazione Android !! come questo ..

minimo SDK: API 14 target SDK: API 17 Compila Con: API 14

E sono le mie scelte buone ?? o quali dovrei scegliere? Mi dispiace, ho provato a mettere una foto, ma non posso ..

"Aspettando le tue risposte" plzzz = D!

+2

ho letto davvero ma non l'ho capito bene: ((!! –

risposta

12

Semplicemente,

minimo SDK: API 14

riferisce che che l'applicazione verrà eseguito solo su telefono cellulare con livello di API 14 vale a dire . (ICS 4.0) o versioni successive. La tua app non funzionerà su versioni precedenti di Android come il pan di zenzero & froyo.

target SDK: API 17

si riferisce alla versione di Android si vuole costruire per il, che è Jellybean sul vostro caso. Si raccomanda di tenere il più tardi possibile il più lontano possibile (api 20 Kitkat nel contesto attuale).

Compila Con: API 14

si riferisce alla versione di Andriod si sta testando su. Complile con API 14 significa che testerai la tua app su ICS.

si potrebbe anche guardare questo video:

https://www.youtube.com/watch?v=Sxo5zMcOCXM>

+0

thaaaaaanks .. questo è quello che voglio :))! –

7

android: minSdkVersion

Un numero intero che designa il livello minimo API richiesta per l'esecuzione dell'applicazione. Il sistema Android impedirà all'utente di installare l'applicazione se il livello API del sistema è inferiore al valore specificato in questo attributo. Devi sempre dichiarare questo attributo.

Android: targetSdkVersion

Un numero intero che designa il livello di API che gli obiettivi di applicazione. Se non impostato, il valore predefinito è uguale a minSdkVersion. Questo attributo informa il sistema che si è verificato con la versione di destinazione e il sistema non dovrebbe consentire l'adozione di comportamenti di compatibilità in avanti per mantenere la compatibilità della tua app con la versione di destinazione. L'applicazione è ancora in grado di funzionare su versioni precedenti (fino a minSdkVersion).

Mentre Android si evolve con ogni nuova versione, alcuni comportamenti e persino apparenze potrebbero cambiare. Tuttavia, se il livello API della piattaforma è superiore a quello dichiarato dalla targetSdkVersion della tua app, il sistema potrebbe abilitare i comportamenti di compatibilità per garantire che l'app continui a funzionare come previsto. È possibile disabilitare tali comportamenti di compatibilità specificando targetSdkVersion in modo che corrisponda al livello API della piattaforma su cui è in esecuzione. Ad esempio, impostando questo valore su "11" o superiore permette al sistema di applicare un nuovo tema di default (Holo) per la vostra applicazione durante l'esecuzione su Android 3.0 o superiore e disattiva anche la modalità di compatibilità dello schermo quando si esegue su schermi più grandi (perché il supporto per l'API livello 11 supporta implicitamente schermi più grandi).

Ci sono molti comportamenti di compatibilità che il sistema può abilitare in base al valore impostato per questo attributo. Molti di questi comportamenti sono descritti dalle corrispondenti versioni della piattaforma nel riferimento Build.VERSION_CODES.

per mantenere la vostra applicazione con ogni versione di Android, è necessario aumentare il valore di questo attributo per abbinare l'ultimo livello di API, quindi a fondo verificare l'applicazione sulla corrispondente versione della piattaforma. Introdotto in: Livello API 4

android: maxSdkVersion

Un numero intero che designa il livello massimo API su cui l'applicazione è progettata per funzionare. In Android 1.5, 1.6, 2.0 e 2.0.1, il sistema controlla il valore di questo attributo quando si installa un'applicazione e quando ri-convalida della domanda dopo un aggiornamento del sistema.In entrambi i casi, se l'attributo maxSdkVersion dell'applicazione è inferiore al livello API utilizzato dal sistema stesso, il sistema non consentirà l'installazione dell'applicazione. In caso di nuova convalida dopo l'aggiornamento del sistema, rimuove efficacemente l'applicazione dal dispositivo.

prega di passare attraverso questo link per maggiori dettagli

http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

+0

Non hai risposto alla "compilazione con". – Kidburla

1

In breve, qui è lo scopo di dichiarare un targetSDK diverso dal minSDK: Vuol dire che si sta utilizzando le caratteristiche di uno SDK livello più elevato rispetto minimo, ma hai assicurato compatibilità all'indietro. In altre parole, immagina di voler utilizzare una funzionalità introdotta solo di recente, ma che non è fondamentale per la tua applicazione. Dovresti quindi impostare il target SDK sulla versione in cui è stata introdotta questa nuova funzionalità e il minimo su qualcosa di inferiore in modo che tutti potessero continuare a utilizzare la tua app.

Per fare un esempio, diciamo che stai scrivendo un'app che fa ampio uso del rilevamento dei gesti. Tuttavia, ogni comando che può essere riconosciuto da un gesto può essere eseguito anche da un pulsante o dal menu. In questo caso, i gesti sono un "fantastico extra" ma non sono richiesti. Di conseguenza, devi impostare il target sdk su 7 ("Eclair" quando è stata introdotta la libreria GestureDetection) e il minimo SDK sul livello 3 ("Cupcake") in modo che anche le persone con telefoni molto vecchi potessero usare la tua app. Tutto quello che dovresti fare è assicurarti che la tua app abbia verificato la versione di Android su cui era in esecuzione prima di provare a utilizzare la libreria dei gesti, per evitare di provare a usarla se non esistesse. (Ammettiamo che questo è un esempio datato dato che quasi nessuno ha ancora un telefono v1.5, ma c'era un tempo in cui mantenere la compatibilità con v1.5 era davvero importante.)

Per dare un altro esempio, è possibile utilizzare questo se si volevo utilizzare una funzione di Gingerbread o Honeycomb. Alcune persone riceveranno presto gli aggiornamenti, ma molte altre, in particolare con hardware più vecchio, potrebbero rimanere bloccate con Eclair fino a quando non acquisteranno un nuovo dispositivo. Questo ti permetterebbe di utilizzare alcune delle nuove fantastiche funzionalità, ma senza escludere parte del tuo possibile mercato.

C'è un articolo davvero buono da Android developer's blog su come utilizzare questa funzione, e in particolare, come progettare il codice "verifica la funzionalità prima di utilizzarlo" di cui sopra.

All'OP: l'ho scritto principalmente a beneficio di chiunque capiti di imbattermi in questa domanda in futuro, poiché mi rendo conto che la tua domanda è stata posta molto tempo fa. here is the Post

0

android: minSdkVersion Un numero intero che designa il livello minimo API richiesta per l'esecuzione dell'applicazione. Il sistema Android impedirà all'utente di installare l'applicazione se il livello API del sistema è inferiore al valore specificato in questo attributo. Devi sempre dichiarare questo attributo. Attenzione: Se non si dichiara questo attributo, il sistema assume un valore predefinito di "1", che indica che l'applicazione è compatibile con tutte le versioni di Android. Se la tua applicazione non è compatibile con tutte le versioni (ad esempio, usa le API introdotte nel livello API 3) e non hai dichiarato la corretta minSdkVersion, allora quando viene installata su un sistema con un livello API inferiore a 3, l'applicazione si blocca durante runtime quando si tenta di accedere alle API non disponibili. Per questo motivo, assicurarsi di dichiarare il livello API appropriato nell'attributo minSdkVersion.

Android: targetSdkVersion Un numero intero che designa il livello di API che gli obiettivi di applicazione.Se non impostato, il valore predefinito è uguale a minSdkVersion. Questo attributo informa il sistema che si è verificato con la versione di destinazione e il sistema non dovrebbe consentire l'adozione di comportamenti di compatibilità in avanti per mantenere la compatibilità della tua app con la versione di destinazione. L'applicazione è ancora in grado di funzionare su versioni precedenti (fino a minSdkVersion).

Mentre Android si evolve con ogni nuova versione, alcuni comportamenti e persino apparenze potrebbero cambiare. Tuttavia, se il livello API della piattaforma è superiore a quello dichiarato dalla targetSdkVersion della tua app, il sistema potrebbe abilitare i comportamenti di compatibilità per garantire che l'app continui a funzionare come previsto. È possibile disabilitare tali comportamenti di compatibilità specificando targetSdkVersion in modo che corrisponda al livello API della piattaforma su cui è in esecuzione. Ad esempio, impostando questo valore su "11" o superiore permette al sistema di applicare un nuovo tema di default (Holo) per la vostra applicazione durante l'esecuzione su Android 3.0 o superiore e disattiva anche la modalità di compatibilità dello schermo quando si esegue su schermi più grandi (perché il supporto per l'API livello 11 supporta implicitamente schermi più grandi).

Ci sono molti comportamenti di compatibilità che il sistema può abilitare in base al valore impostato per questo attributo. Molti di questi comportamenti sono descritti dalle corrispondenti versioni della piattaforma nel riferimento Build.VERSION_CODES.

per mantenere la vostra applicazione con ogni versione di Android, è necessario aumentare il valore di questo attributo per abbinare l'ultimo livello di API, quindi a fondo verificare l'applicazione sulla corrispondente versione della piattaforma.

Introdotto in: Livello API 4

android: maxSdkVersion Un numero intero che designa il livello massimo API su cui l'applicazione è progettata per funzionare. In Android 1.5, 1.6, 2.0 e 2.0.1, il sistema controlla il valore di questo attributo quando si installa un'applicazione e quando ri-convalida della domanda dopo un aggiornamento del sistema. In entrambi i casi, se l'attributo maxSdkVersion dell'applicazione è inferiore al livello API utilizzato dal sistema stesso, il sistema non consentirà l'installazione dell'applicazione. In caso di nuova convalida dopo l'aggiornamento del sistema, rimuove efficacemente l'applicazione dal dispositivo.

per illustrare come questo attributo può influenzare l'applicazione dopo gli aggiornamenti di sistema, si consideri il seguente esempio:

Un'applicazione dichiarando maxSdkVersion = "5" nel suo manifesto è pubblicato su Google Play. Un utente il cui dispositivo esegue Android 1.6 (Livello API 4) scarica e installa l'app. Dopo alcune settimane, l'utente riceve un aggiornamento del sistema over-the-air ad Android 2.0 (livello API 5). Dopo l'installazione dell'aggiornamento, il sistema controlla la maxSdkVersion dell'applicazione e la riconvalida con successo. L'applicazione funziona normalmente. Tuttavia, qualche tempo dopo, il dispositivo riceve un altro aggiornamento di sistema, questa volta su Android 2.0.1 (Livello API 6). Dopo l'aggiornamento, il sistema non può più riconvalidare l'applicazione perché il livello API (6) del sistema è ora superiore al massimo supportato dall'applicazione (5). Il sistema impedisce all'applicazione di essere visibile all'utente, in pratica rimuovendola dal dispositivo.

Avvertenza: la dichiarazione di questo attributo non è consigliata. Innanzitutto, non è necessario impostare l'attributo come mezzo per bloccare la distribuzione della propria applicazione sulle nuove versioni della piattaforma Android non appena vengono rilasciati. In base alla progettazione, le nuove versioni della piattaforma sono completamente compatibili con le versioni precedenti. La tua applicazione dovrebbe funzionare correttamente con le nuove versioni, purché utilizzi solo API standard e segua le best practice di sviluppo. In secondo luogo, si noti che in alcuni casi, la dichiarazione dell'attributo può comportare la rimozione dell'applicazione dai dispositivi degli utenti dopo un aggiornamento del sistema a un livello API più elevato.La maggior parte dei dispositivi su cui è probabile che la tua applicazione sia installata riceverà aggiornamenti periodici del sistema via etere, quindi dovresti considerare i loro effetti sull'applicazione prima di impostare questo attributo.

Introdotto in: Livello API 4

Le future versioni di Android (oltre Android 2.0.1) non sarà più controllare o far rispettare l'attributo maxSdkVersion durante l'installazione o ri-convalida. Google Play continuerà a utilizzare l'attributo come filtro, tuttavia, quando presenta agli utenti applicazioni disponibili per il download.

vedere di più su questo, clicca qui: use sdk

3

cercando di tenerlo semplice possibile riesco a spiegare i tre termini nel modo seguente:

Min richiesto SDK: spettacoli il dispositivo con la versione Android minima che desideri supportare con la tua app. Ad esempio, se selezioni API 11: Honey Comb nell'elenco a discesa. Questo mostrerà che la tua app non supporterà/non funzionerà su nessun dispositivo Android con versione Android inferiore a Honey Comb.

SDK di destinazione: Questo deve essere sempre mantenuto il più alto possibile in quanto indica la versione di Android che è stata destinata o testata alla tua app. Quindi, se mantieni il tuo minReqSDK >> 11 (honey comb) e targetSDK >> 21 (Lollipop), questo mostra che la tua app funzionerà su tutte le versioni di Android da honeycomb a Lollipop senza problemi di compatibilità, come hai impostato l'SDK di destinazione> > 21 versione Lollipop.

Compila con: Questo non ha nulla a che fare con Android che supporta qualsiasi dispositivo. Puoi scegliere qualsiasi versione di Android che hai installato usando il tuo gestore di SDK per compilare ed eseguire la tua app a scopo di sviluppo.

Nel tuo caso: min versione SDK: 14 bersaglio sdk: 17 compilare con: 14

Il dispositivo supporterà tutte le versioni di Android avendo livello di API 14 (Ice Cream Sandwich) a livello di API 17 (Jelly Bean 4.2). E hai utilizzato api livello 14 (ICS) per compilare ed eseguire la tua app per lo sviluppo.

Spero che questo aiuti.

Problemi correlati