Android Open Source Project quanto basta.

Pubblicato: ottobre 8, 2015 in Android, Programmazione
Tag:, , ,

android

Android è il sistema operativo sviluppato da Google che negli ultimi anni si è diffuso su milioni di device e dispositivi elettronici probabilmente grazie alle sue indiscusse ottime funzionalità ma anche alla sua natura di progetto Open Sources.

Quando si parla di progetto Open Source si pensa sempre ad un progetto aperto, di cui si conosce ogni aspetto o in cui ogni modifica e ogni cambio di direzione sia stato condiviso e discusso da una comunità di sviluppo secondo lo schema classico e già collaudato da anni dagli sviluppatori di Linux o di uno dei tanti altri progetti Open relativi al mondo dell’ IT.

Android però differisce in molte parti da questo “schema classico di sviluppo” sia per le modalità di creazione ( Android è ed è stato sviluppato a porte chiuse dal team di Google che poi successivamente ha rilasciato e rilascia il lavoro svolto sotto forma di sorgente) sia per il modello interno dei componenti software e delle funzionalità e delle loro relative licenze di utilizzo.

Quando si legge la documentazione relativa ad Android compare sempre l’acronimo AOSP il quale stà ad indicare l’insieme del Progetto Open Source, che Google ha creato nel mettere insieme il sistema operativo Android.
Ma con quale licenza d’uso vengono rilasciati i componenti dell’AOSP e quali sono i componenti principali di Android?

Nelle righe seguente cercherò di spiegare questa complessa questione, almeno per quanto ne sono riuscito a capire io,  nella speranza di poter fare un po di chiarezza su questa spinosa materia.
Qualora nel corso della lettura rilevate delle inesattezze o delle mancanze, siete veramente pregati di segnalarmelo.

Nota per gli utilizzatori “quotidiani” di Android: la lettura di questo articolo non vi aiuterà a far funzionare meglio il vostro telefonino, al massimo può risultare interessante per gli smanettoni e per coloro che si occupano di adattare Android per i propri prodotti embedded.
Lettore avvisato, mezzo salvato!

Com’è fatto internamente Android?

Android è internamente costituito da due parti, un kernel Linux Android compatibile o una AOSP, ovvero un’insieme di tools, librerie e componenti software sulla quale si basa l’intera operatività del sistema.

 

android1

 

Il Kernel anche se è stato modificato per girare nell’AOSP continua ad essere soggetto alle stesse licenze GNU GPLv2 che da sempre regolano la sula modifica e distribuzione.

Cosa significa questo?

Significa che non è possibile distribuire alcun kernel “modificato” senza rilasciare pubblicamente le modifiche effettuate.

Il altre parole, per esser ancora più chiari, se si parte da una versione del kernel presa da http://android.googlesource.com o anche fornita dal produttore sei SoC ( i micropocessori per capirci) e la si modifica per adattarla al proprio sistema, è permesso distribuire l’immagine del kernel ed il prodotto relativo, solo fino a quando si rispettano le licenze GPL.

Questo significa che si deve rilasciare le modifiche ed il codice fatto in quanto il vostro kernel derivato ed adattato per il vostro prodotto è un “worked derived” e quindi è necessario rilasciare il codice sorgente con tutte le modifiche apportate.

Solo il kernel è soggetto a questa limitazione, le applicazioni che ci girano sopra non sono considerate “lavoro derivato”, quindi per tutto quello che gira sopra al kernel, non c’è alcun vincolo e non è necessario rilasciare niente a nessuno.

Google ha plasmato Android seguendo questa logica:

Si usa il kernel Linux con tutte le limitazioni GPL probabilmente in quanto è una parte ben delineata e separata dal resto del framework e perchè il kernel Linux  a differenza di altre soluzioni possibili, era ed è già molto utilizzato e conosciuto nell’industria e nel mondo informatico.

Per il resto del sistema si utilizzano oggetti e componenti che non dovono rispettare i vincoli della licenza GPL;
ecco spiegato perché ad esempio non è stato incluso le glib, le uClibc, il Busybox, e molti altri componenti tipici dei sistemi Linux tradizionali.

Tutti i componenti Android aggiuntivi rispetto al kernel, come ad esempio le Bionic che rimpiazzano le glib, e gli altri componenti realizzati direttamente da Google sono rilasciati con licenze tipo Apache License 2.0 (ASL) la quale non prevede, nel caso di “lavoro derivato”, che le modifiche effettuate debbano essere rilasciate pubblicamente.

L’AOSP non contiene infatti componenti che hanno una licenza d’uso GPL o LGPL.

Nei sistemi tipici Linux l’esposizione dei delle funzionalità del kernel o l’accesso alle periferiche o ai device del sistema avvengono per mezzo di driver specifici ( moduli del kernel ) che normalmente popolano la directory /dev del filesystem.

In Android l’esposizione delle funzionalità del basso livello verso lo “user space” viene effettuato attraverso delle librerie, l’Hardware Abstraction Layer (HAL), che definisce una serie di API con le quali accedere all’hardware e alle relative funzioni. Alla fine della catena però c’è sempre un modulo Linux che viene comunque chiamato dalle suddette API al momento del bisogno.

Perchè questo “rimpallo” di chiamate?

Il problema è sempre nella gestione delle licenze.

Generalmente un modulo Linux è contenuto nel kernel e deve ( o dovrebbe ) essere distribuito con il kernel stesso con licenza GPL.

In Android si preferisce fare un modulo kernel “elementare” che espone l’hardware allo user-space attraverso mmap() o ioctl() ed integrare il grosso del lavoro e tutte l’intelligenza necessaria all’interno della shared library ( libreria e relative API ) che usa queste funzioni per accedere alle funzionalità specifiche del sistema.

Il modulo Linux può essere rilasciato in licenza GPL senza problemi, la libreria può essere rilasciata con la licenza che si vuole ( quindi anche chiusa ) e nessuno può vedere quali trucchi siano stati utilizzate per far funzionare la meglio quella funzionalità del sistema.

Furbi no?

Per i piu curiosi:

http://elinux.org/images/f/ff/Porting_Android_4.0_to_a_Custom_Board.pdf

http://events.linuxfoundation.org/sites/events/files/slides/Android-non-mobile.pdf

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...