AndroidManifest.xml e le capabilities

Abbiamo già discusso ed utilizzato il file AndroidManifest.xml durante questa guida. È chiaro che programmare applicazioni Android senza saperlo
configurare è impossibile. L'uso che ne abbiamo fatto finora ha riguardato per lo più la definizione delle componenti da inserire nell'applicazione.
Abbiamo visto che se si vogliono utilizzare le quattro componenti fondamentali – Activity, ContentProvider, Service, BroadcastReceiver – è necessario,
oltre ad estendere l'opportuna classe Java, inserire un adeguato elemento XML nel manifest, in particolare all'interno del nodo <application>:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="..."
android:versionCode="1"
android:versionName="1.0" >
. . .
. . .
<application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<activity
android:name="..."
android:label="@string/app_name" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<receiver android:name="...">
<intent-filter>
<action android:name="..." />
</intent-filter>
</receiver>
<provider
android:name="..."
android:authorities="..."/>
<service android:name="..."/>
</application>
</manifest>

In questo capitolo ci interesseranno altri particolari relativi al file manifest, ma che saranno inseriti esternamente al nodo <application>. Ci occuperemo di tutti
quegli aspetti che descrivono i requisiti che un dispositivo deve possedere affinchè la nostra applicazione possa esservi installata.

Si tratta di un preambolo indispensabile per pensare alla pubblicazione della nostra app.

L'elemento <uses-sdk> è molto importante per specificare il range di versioni Android in cui l'applicazione può funzionare. La finalità principale di questo nodo è
garantire la retrocompatibilità dell'applicazione. Tramite questo elemento è possibile specificare l'API level, ovvero la versione delle API utilizzate, espressa con
un numero intero. Non è necessario conoscere a memoria tutte (anche perchè l'elenco completo è sempre disponibile su Internet); tuttavia bisogna tenere presente che le
"pietre miliari" della storia di Android non sono molte. I principali API level sono i seguenti:

• 7 e 8: corrispondono ad Android 2.1 e 2.2 e costituiscono la soglia minima che ormai ha senso supportare nelle proprie applicazioni;
• 11: Android 3 (Honeycomb), che ha rappresentato una piccola rivoluzione, in cui sono state integrate alcune caratteristiche basilari nel framework (per esempio Fragments e
  Loaders);
• 14: inizia Android 4 (Ice Cream Sandwich), l'alba della versione attuale del sistema operativo.

Gli attributi di <uses-sdk> sono:

• minSdkVersion: indica la minima versione supportata. Può andare bene, ormai, che sia 7 o 8 ma se è inferiore
  alla 11 sarà importante acquisire confidenza con la libreria di supporto per integrare, nelle versioni più datate, le novità di Honeycomb. È importante che questo attributo
  sia esplicitamente dichiarato perchè, se non lo fosse, la minima versione supportata sarà l'API level 1 (e ciò, oggi come oggi, ha poco senso);
• targetSdkVersion: rappresenta la versione principale per la quale è stata pensata l'applicazione;
• maxSdkVersion: molto poco utilizzato, anche perchè sconsigliato dalla stessa documentazione, questo attributo rappresenta il massimo API level supportato.
  Dal momento che lo scopo di <uses-sdk> è la gestione della retrocompatibilità, maxSdkVersion rischia di
  impedire l'installazione dell'applicazione su dispositivi più recenti.

Il tag <permission> è stato già incontrato parecchio nel corso di questa guida.
Necessario ogni volta che la nostra applicazione deve avviare comunicazioni o accessi particolari, richiede almeno
che la definizione dell'attributo android:name, che specifica esattamente il tipo di permission richiesta. Finora l'abbiamo incontrato in:

• accesso alla Rete: android.permission.INTERNET;
• localizzazione: android.permission.ACCESS_FINE_LOCATION e android.permission.ACCESS_COARSE_LOCATION;
• storage esterno: android.permission.WRITE_EXTERNAL_STORAGE;
• comunicazioni telefoniche: android.permission.CALL_PHONE e android.permission.READ_PHONE_STATE;
• Content Providers: vari casi (contatti, calendario, chiamate, etc...).

Infine, <uses-feature>
è la risposta alla frammentazione hardware e software del sistema Android. Permette di specificare di quali caratteristiche hardware o software
l'applicazione ha bisogno per funzionare.

Gli attributi di cui dispone sono:

• android:name: una stringa che definisce quale dotazione del dispositivo è necessaria affinchè l'applicazione funzioni correttamente. A livello hardware, si
  potrebbe avere bisogno di verificare se l'equipaggiamento elettronico del device comprende tecnologie come Bluetooth o NFC, nonchè dispositivi come la videocamera o lo schermo multitouch;
• android:required: è un valore booleano. Se impostato a true indica che la caratteristica è assolutamente obbligatoria per il funzionamento dell'app; altrimenti
  indica che la feature è fortemente consigliata ma non obbligatoria;
• android:glEsVersion: indica la versione delle librerie OpenGL ES richiesta dall'app.