Nel precedente articolo abbiamo parlato della Dalvik Virtual Machine DVM, oggi vogliamo parlare su com’è fatta l’architettura di Android descrivendo i vari servizi.
Vi consigliamo prima di leggere gli articoli precedenti per chi non l’avesse già fatto.
Cosa è, e come è fatta l’architettura di Android?
Come abbiamo già detto Android comprende tutto lo stack degli strumenti per la creazione di applicazioni, tra cui un sistema operativo, un insieme di librerie native per le funzionalità core della piattaforma, una implementazione della VM e un insieme di librerie Java.
L’ architettura Android è un architettura a strati dove i livelli inferiori offrono servizi ai livelli superiori offrendo un più alto grado di astrazione, che verranno analizzati nei vari articoli.
Iniziamo a vedere i vari livelli partendo dal piu basso fino ad arrivare al più alto.
Il kernel di Linux
Il layer di più basso livello è rappresentato dal kernel Linux. La necessità era infatti quella di disporre di un vero e proprio sistema operativo che fornisse gli strumenti di basso livello per la virtualizzazione dell’hardware sottostante attraverso la definizione di diversi driver, il cui nome è completamente esplicativo.
In particolare, possiamo notare la presenza di driver per la gestione delle periferiche multimediali, del display, della connessione Wi-Fi e dell’alimentazione.
È da notare anche la presenza di un driver dedicato alla gestione della comunicazione tra processi diversi (IPC); la sua importanza è fondamentale per far comunicare componenti diversi in un ambiente in cui ciascuna applicazione viene eseguita all’interno di un proprio processo.
Perchè usare il kernel di linux?
La scelta verso l’utilizzo di un kernel Linux è stata conseguenza della necessità di avere un SO che fornisse tutte le feature di sicurezza, gestione della memoria, gestione dei processi, power management e che fosse affidabile e testato.
Il vendor che vorrà utilizzare Android sui propri dispositivi non dovrà quindi fare altro che installare il kernel di Linux implementando i driver per il proprio hardware.
Librerie native
Sopra al kernel di Linux abbiamo un livello che contiene un insieme di librerie native realizzate in C e C++, che rappresentano il core vero e proprio di Android.
Si tratta di librerie che fanno riferimento a un insieme di progetti Open Source; li descriveremo brevemente uno a uno, per poi approfondire nel dettaglio per quello che riguarda le API. In questa fase sarà importante assegnare a ciascun elemento le proprie responsabilità. Per aiutarci cercheremo di far sempre riferimento a concetti che già conosciamo in ambito Java standard.
Surface Manager
Il Surface Manager (SM) è un componente fondamentale in quanto ha la responsabilità di gestire le view, ovvero ciò da cui un’interfaccia grafica è composta. Il compito del SM è infatti di coordinare le diverse finestre che le applicazioni vogliono visualizzare sullo schermo. Ciascuna applicazione è in esecuzione in un processo diverso e disegna quindi la propria interfaccia in tempi diversi.
Il compito del SM è di prendere le diverse finestre e di disegnarle sul buffer da visualizzare poi attraverso la tecnica del double buffering. In
questo modo non si avranno finestre che si accavallano in modo scoordinato sul display.
Il Surface Manager avrà quindi accesso alle funzionalità del display e permetterà la visualizzazione contemporanea di grafica 2D e 3D dalle diverse applicazioni.
Open GL ES
Un’importante caratteristica di Android che vedremo dettagliatamente quando inizieremo a sviluppare è la possibilità di utilizzare sia grafica 3D sia grafica 2D all’interno di una stessa applicazione.
La libreria utilizzata per la grafica 3D è quella che va sotto il nome di OpenGL ES (http://www.khronos.org/opengles), la quale permette di accedere alle funzionalità di un eventuale acceleratore grafico hardware. Si tratta di una versione ridotta di OpenGL specializzata per dispositivi mobili.
Ma che cos’è l’OpenGL ES?
Si tratta di un insieme di API multipiattaforma che forniscono l’accesso a funzionalità 2D e 3D in dispositivi embedded. Come avvenuto per
le J2ME di Java, anche in relazione alla grafica su dispositivi con risorse relativamente ridotte, si è deciso di creare un sottoinsieme delle API dell’OpenGL, da cui appunto l’OpenGL ES.
SGL
La Scalable Graphics Library (SGL) è una libreria in C++ che insieme alle OpenGL costituisce il motore grafico di Android. Mentre per la grafica 3D ci si appoggia all’Open GL, per quella 2D viene utilizzato un motore ottimizzato chiamato appunto SGL.
Si tratta di una libreria utilizzata principalmente dal Window Manager e dal Surface Manager all’interno del processo di renderizzazione grafica.
Media Framework
Per gestire la multimedialità vi è la necessità di un componente in grado di gestire i diversi CODEC per i vari formati di acquisizione
e riproduzione audio e video, che nell’architettura di Android si chiama Media Framework.
FreeType
La gestione dei font è un altro aspetto molto importante nella definizione di un’interfaccia.
A tale proposito per Android si è scelto di utilizzare il motore di rendering dei font FreeType (http://freetype.sourceforge.net). Si è deciso di utilizzare questo motore perché è di piccole dimensioni, molto efficiente, altamente customizzabile e soprattutto portabile. Attraverso FreeType, le applicazioni di Android saranno in grado di visualizzare immagini di alta qualità.
SQLite
Chi sviluppa con le MIDP conoscerà molto bene il Record Management System (RMS), ovvero quel sistema che permette di memorizzare in modo persistente sul dispositivo un certo insieme di informazioni.
Con Android si è deciso di utilizzare un qualcosa di efficiente e piccolo ma che avesse per quanto possibile le caratteristiche di un DBMS relazionale. Da qui la decisione di utilizzare SQLite (http://www.sqlite.org), una libreria in-process che implementa un DBMS relazionale caratterizzato dal fatto di essere molto compatto, diretto, di non necessitare alcuna configurazione e soprattutto essere transazionale.
WebKit
Nell’era del Web 2.0 non poteva certo mancare un browser integrato nella piattaforma. A tale proposito la scelta è andata sul framework WebKit (http://webkit.org) utilizzato anche dai browser Safari e Chrome.
Si tratta di un browser engine open source basato sulle tecnologie HTML, CSS, JavaScript e DOM. Un aspetto da sottolineare è che WebKit non è un browser ma un browser engine, quindi andrà integrato in diversi tipi di applicazioni.
SSL
Si tratta della ormai famosa libreria per la gestione dei Secure Socket Layer. Anche gli aspetti legati alla sicurezza non potevano di certo essere trascurati da Android.
Libc
Si tratta di un’implementazione della libreria standard C libc ottimizzata per i dispositivi basati su Linux embedded come Android.
Le core library
Come sappiamo, per eseguire un’applicazione in Java non serve solamente l’applicazione in sé, ma anche tutte le classi relative all’ambiente nella quale la stessa viene eseguita.
Per le applicazioni Android in fase di compilazione avremo bisogno del jar (di nome android.jar) per la creazione del bytecode Java, mentre in esecuzione il device metterà a disposizione la versione dex del runtime che costituisce appunto la core library.
Nel dispositivo non c’e’ infatti codice Java, in quanto non potrebbe essere interpretato da una JVM, ma solamente codice dex eseguito dalla DVM.
Application Framework
Tutte le librerie viste finora vengono poi utilizzate da un insieme di componenti di più alto livello che costituiscono l’Application Framework (AF). Si tratta di un insieme di API e componenti per l’esecuzione di funzionalità ben precise e di fondamentale importanza in ciascuna applicazione Android.
Tutte le applicazioni per Android utilizzano lo stesso AF e come tali possono essere estese, modificate o sostituite. Da qui il motto che possiamo trovare sul sito di Android, ovvero: “All applications are equals”.
Activity Manager
Quando inizieremo lo sviluppo delle applicazioni per Android, vedremo come assuma fondamentale importanza il concetto di activity.
Si tratta di un qualcosa che possiamo associare inizialmente a una schermata, che quindi permette non solo la visualizzazione o la raccolta di informazioni ma, in modo più generico, è lo strumento fondamentale attraverso il quale l’utente interagisce con l’applicazione.
Successivamente vedremo come sia fondamentale capire nel dettaglio il ciclo di vita, gestito dall’Activity Manager, di ciascuna activity. Responsabilità di questo componente sarà quindi l’organizzazione delle varie schermate di un’applicazione in uno stack a seconda dell’ordine di visualizzazione delle stesse sullo schermo dei diversi dispositivi.
Comprendere quindi a fondo il funzionamento di questo componente è fondamentale per riuscire a realizzare delle applicazioni. Per questo motivo dedicheremo un capitolo intero all’argomento.
Package Manager
Un aspetto non trascurabile di un sistema come Android è la gestione del processo di installazione delle applicazioni nei dispositivi.
Come vedremo, ciascuna applicazione dovrà fornire, al dispositivo che le andrà a eseguire, un determinato insieme di informazioni che descriveremo attraverso un opportuno file XML di configurazione; tale file prende il nome di AndroidManifest.
Si tratta di informazioni di vario genere, per esempio relative agli aspetti grafici (il layout) dell’applicazione, alle diverse activity, o ad aspetti di sicurezza. La responsabilità del Package Manager sarà quindi di gestire il ciclo di vita delle applicazioni nei dispositivi.
Window Manager
Un componente molto importante è dunque il Window Manager, che permette di gestire le finestre delle diverse applicazioni, gestite da processi diversi, sullo schermo del dispositivo.
Telephony Manager
Il Telephony Manager permette una maggiore interazione con le funzionalità caratteristiche di un telefono come la semplice possibilità di iniziare una chiamata o di verificare lo stato della chiamata stessa.
Content Provider
Il Content Provider (CP) è un componente fondamentale nella realizzazione delle applicazioni per Android, poiché ha la responsabilità di gestire la condivisione di informazioni tra i vari processi.
Il funzionamento è simile a quello di un repository condiviso con cui le diverse applicazioni possono interagire inserendo o leggendo informazioni.
Resource Manager
Come vedremo nel dettaglio, un’applicazione è composta, oltre che da codice, anche da un insieme di file di tipo diverso, per esempio immagini, file di configurazione o di properties per la internazionalizzazione (I18N), file di definizione del layout e così via. La responsabilità di gestire questo tipo di informazioni è stata affidata al Resource Manager, che metterà a disposizione una serie di API di semplice utilizzo.
Si tratta di un componente con responsabilità di ottimizzazione delle risorse.
View System
La gestione della renderizzazione dei componenti nonché della gestione degli eventi associati è di responsabilità di un componente che si chiama View System (VS). Potremmo quindi fare un’analogia tra il VS e il meccanismo di gestione delle GUI della J2SE quali AWT o Swing.
Location Manager
Le applicazioni che gestiscono, tra le informazioni disponibili, quelle relative alla localizzazione si chiamano Location Based Application (LBA) e possono essere realizzate utilizzando le API messe a disposizione dal Location Manager.
Notification Manager
Un altro servizio molto utile è quello fornito dal Notification Manager, mette a disposizione un insieme di strumenti che l’applicazione può utilizzare per inviare una particolare notifica al dispositivo, il quale la dovrà presentare all’utente con i meccanismi che conosce. La notifica potrà essere un segnale attraverso la vibrazione, un LED, o un’icona.
