AndroidManifest.xml e le capabilities

26 novembre 2014

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.

Tutte le lezioni

1 ... 66 67 68 ... 81

Se vuoi aggiornamenti su AndroidManifest.xml e le capabilities inserisci la tua e-mail nel box qui sotto:
Tags:
 
X
Se vuoi aggiornamenti su AndroidManifest.xml e le capabilities

inserisci la tua e-mail nel box qui sotto:

Ho letto e acconsento l'informativa sulla privacy

Acconsento al trattamento di cui al punto 3 dell'informativa sulla privacy