Come rendere il mio progetto compatibile con diverse versioni di sdk utilizzando le funzionalità per una versione specifica

Question

Sto sviluppando un progetto che utilizza un video Flash all'interno di una visualizzazione Web. Ho risolto tutti i miei problemi relativi al codice, ma ho lavorato solo sotto Honeycomb.

Lettura this Ho scoperto come risolvere i problemi per Android 3.0 e versioni successive (incluso ICS), ma ora è la grande domanda ... Se faccio il mio progetto compatibile con ICS devo usare la direttiva, ma poi non vorrei correre su Gingerbread.

Per fornire qualche informazione in più ... il pezzo problematica del codice è questo:

android:hardwareAccelerated="true" 

che è una proprietà che è stato incluso in Android 3.0.

Quindi, c'è qualcosa che posso fare per evitare di creare due apk diversi (un po 'come un apk pre-HoneyComb e un apk post-HoneyComb)?

Questo è un pezzo della mia manifesta Android:

<application android:label="@string/app_name" 
      android:icon="@drawable/elabora" 
      android:theme="@android:style/Theme.NoTitleBar"> 
    <activity android:name="es.fundacionvodafone.elabora.android.controlador.InicioElaboraTest" 
       android:label="@string/app_name" 
       android:noHistory="true"> 
     <intent-filter> 
      <action android:name="android.intent.action.MAIN" /> 
      <category android:name="android.intent.category.LAUNCHER" /> 
     </intent-filter> 
    </activity> 
    <activity android:name="es.fundacionvodafone.elabora.android.controlador.InicioElabora" 
       android:configChanges="orientation|keyboardHidden" 
       android:label="@string/app_name" 
       android:hardwareAccelerated="true"> 
      <!--    
      <intent-filter> 
       <action android:name="android.intent.action.MAIN" /> 
       <category android:name="android.intent.category.LAUNCHER" /> 
      </intent-filter> 
      --> 
    </activity> 

Grazie in anticipo.

Aggiornamento: Stavo già utilizzando ciò che Mike ha spiegato, vale a dire, definendo minSdk e targetSdk correttamente, ma sono stato confuso dal fatto seguente. Con tale configurazione di progetto, quando si esegue il progetto in eclissi, viene visualizzata la seguente finestra: La croce rossa indica che il livello targetSdk del progetto è superiore al livello dell'API del dispositivo. Quindi ho pensato che non funzionasse in questo dispositivo, ma il fatto è che puoi eseguirlo e funziona come previsto.

Answer 1

Il commento pubblicato dall'OP al di sotto della sua domanda (in pratica si afferma che il target SDK non influisce sulla compilazione di un'app) è completamente sbagliato! Mi dispiace essere sincero.

In breve, ecco lo scopo di dichiarare un targetSDK diverso da minSDK: Significa che si stanno utilizzando le funzionalità di un SDK di livello superiore rispetto al minimo, ma si è garantita la compatibilità con le versioni precedenti. 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 usarlo" di cui sopra.

All'OP: l'ho scritto principalmente a beneficio di chiunque si imbatta in questa domanda in futuro.

Answer 2

Ho un problema simile con la versione di Android manifest. Per i telefoni più vecchi voglio avere widget in alcune dimensioni predefinite, per i telefoni più recenti che supportano il ridimensionamento voglio avere un singolo widget ridimensionabile. Non ho trovato ancora un modo per farlo. Forse è per questo che Google è arrivato con multiple APK support.

L'articolo di Adam's Powell sopra menzionato non affronta questo tipo di controllo delle versioni. (ottimo articolo a proposito).

Modifica: ottenuto una soluzione. La definizione dei widget nel manifest Android ha un attributo booleano abilitato che può essere impostato dai valori delle risorse booleane. I valori delle risorse possono avere valori per versione utilizzando i nomi delle directory delle risorse qualificate della versione standard. Problema risolto.