Tag Archive: Android


I made it!

Speaking of the AR.Drone, I managed to compile the Android application putting the video feed in asynchronous mode, now it works as a charm as a remote control, while the video feed is amazingly slow…

Definitely the G1 (Dream) is not a suitable device to be receiving raw video from wifi.

My latest purchase, something that I really shouldn’t have bought, the Parrot AR.Drone:

A pretty sturdy, programmable, wi-fi controlled, quad-propeller flying object with cameras and sensors on board.

I had to borrow an iPod to try out the thing, since my Android-powered HTC Dream is a little slow to handle the example application, which is not optimized, and my Linux laptop didn’t want to connect to the drone (Closed wireless NIC drivers being the primary reason), but it flies very nicely, stable and easy, a eleven years old kid could pilot it without crashing… Actually an eleven years old boy (my brother) did fly it; and he – unlike me – avoided crashing…

Android e Open Source

C’è stata una vera e propria doccia fredda sulla community di Android questo fine settimana; uno dei più conosciuti sviluppatori di versioni modificate (MODs) dell’ultimo sistema operativo mobile ha ricevuto una lettera di Cease & Desist da parte dei legali di Google, azienda molto legata allo stesso Android; vicenda gonfiata e diventata in breve tempo un caso eclatante a causa di due fattori secondo me: da una parte c’è l’eccessivo zelo dei legali di Google, che IMHO poteva raggiungere lo stesso risultato senza dover inviare alcunchè, considerando che il modder (Steve, AKA Cyanogen) produce le sue versioni di MOD in stretto contatto con gli stessi sviluppatori di Android; e l’altro fattore è l’abissale ignoranza e la colossale arroganza della maggior parte degli end-users, che hanno gonfiato e mal riportato quello che in realtà era una cosa che Cyanogen stava già chiarendo con Google.

La vicenda si svolge intorno ad un punto chiave: le applicazioni del pacchetto GE (Google Experience), che sarebbero in particolare: Google Search, Google Maps, Youtube e Android Market; tenendo conto di questo, passo a spiegare

La piattaforma Android è distribuita sotto licenza Apache 2.0, quindi Free & Open Source, mentre le applicazioni sono proprietarie e distribuite secondo i termini stabiliti dal produttore; nel caso specifico, Google ha limitato la distribuzione delle proprie applicazioni ai dispositivi certificati GE, che al momento attuale sono tutti gli smartphone venduti con Android preinstallato.

Ora, la licenza e la distribuzione di Android ne permette la compilazione e l’installazione anche su altri smartphone, a patto di riuscire a trovare drivers compatibili con l’hardware specifico, questo però rende la distribuzione delle applicazioni GE su tali dispositivi non conforme alle specifiche del produttore. In più, uno sviluppatore di terze parti non è autorizzato a ridistribuire le applicazioni proprietarie insieme al suo lavoro.

Questo è quello che Google contesta a Cyanogen, la distribuzione delle applicazioni GE insieme alle sue MOD, non la produzione e la distribuzione delle MOD.

L’ignoranza e la prepotenza della community, invece, ha tirato su un caso enorme sull’incomprensione che Google volesse impedire di fatto la distribuzione di MOD basate sul progetto Android, non è questo il caso, tanto che AOSP (Android Open Source Project) è liberamente scaricabile e compilabile da chiunque, e tale resterà, ha solo delle parti che per forza di cose non vengono distribuite se non sotto licenza proprietaria, ad esempio i drivers dei chip radio dei vari smartphone, decisione che spetta ai produttori di hardware e non a Google, le applicazioni Google Experience, a cui AOSP si è dovuto appoggiare per poter uscire in tempi brevi, e da cui lentamente si sta staccando, pur mantenendole nella principale integrazione.

Fonti:
Notizia della lettera C&D
Spiegazione degli sviluppatori di Android e Google alla community
Reazione del modder, Cyanogen

So che a nessuno interessa, ma ho trovato il modo per far riconoscere al caro amico pinguino la periferica corretta quando ci si collega un HTC Dream, si tratta di aggiungere un paio di regole ad hoc nella configurazione di udev:

E’ sufficiente creare un file nella directory /etc/udev/rules.d chiamato ad esempio 51-android.rules (ho messo il 51 per seguire i consigli di un forum, che dava il 50 come “standard” per non so che programma, non ricordo), e scriverci dentro queste righe:

SUBSYSTEM==”usb|usb_device”, SYSFS{idVendor}==”0bb4″, MODE=”0660″, GROUP=”plugdev”
SUBSYSTEM==”usb|usb_device”, ATTR{idVendor}==”0bb4″, ATTR{idProduct}==”0c02″, SYMLINK+=”android_adb”
SUBSYSTEM==”usb|usb_device”, ATTR{idVendor}==”0bb4″, ATTR{idProduct}==”0c01″, SYMLINK+=”android_fastboot”

i valori 0bb4 e 0c02 si possono recuperare attraverso un “lsusb” cercando la riga effettiva del dispositivo, sono il campo “ID” concatenati da “:” ad esempio:

[root@xviluppo]~$ lsusb
Bus 001 Device 004: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse
Bus 001 Device 003: ID 413c:2003 Dell Computer Corp. Keyboard
Bus 001 Device 002: ID 04cc:1520 Philips Semiconductors
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 0bb4:0c02 High Tech Computer Corp.
[root@xviluppo]~$

E successivamente riavviare udev con un ben piazzato

[root@xviluppo]~$ /etc/rc.d/rc.udev restart

EDIT: Aggiunta una riga che avevo tralasciato, guarda caso l’unica importante…