Archivi categoria: Mobile

Introduzione alla tecnologia iBeacon

Con grande orgoglio e con l’emozione di sempre, anche quest’anno sono stato invitato a parlare al Codemotion che si è svolto all’Università Roma3. Ho parlato della tecnologia iBeacon e della localizzazione indoor e a corto raggio.

codemotion2015_badge

Il tema ha attirato un pubblico numeroso e spero sia stato di interesse per tutti i partecipanti.

codemotion2015_me

Iniziato timidamente molti anni fa, il Codemotion si conferma l’evento italiano più importante per sviluppatori, hacker, maker, innovatori, aziende e appassionati. Averlo trasformato da evento gratuito ad evento a pagamento non ha ridotto l’affollamento ma solo sfrondato i partecipanti casuali e annoiati, che portano casino e si addormentano durante i talk.

È un evento notevole, bellissimo, che credo abbia ancora ampissimi spazi di miglioramento: questo è assolutamente positivo, perché significa che gli anni avvenire porteranno novità e nuovi stimoli. Qualche nota: sarebbe molto utile che TUTTI i talk venissero registrati, per creare un mega archivio di tutto quanto prodotto dagli speaker; dovrebbe essere possibile (in qualche modo) segnalare la necessità di replicare un talk (magari perché due molto interessanti sono in sovrapposizione); i talk dovrebbero durare un po’ di più (40 minuti sono pochi).

Per me è stata anche una occasione per rivedere tanti amici che non vedevo da tempo (uno per tutti: Edoardo Schepis, che forse non vedevo da 10 anni! Ma anche Ugo, Giorgio, Guido, Daniela…): è stato molto bello constatare che, malgrado i capelli bianchi, qualche chilo in più, le chiacchierate più a parlare dei bambini che dei viaggi, siamo sempre gli stessi, sempre “hungry & foolish” anche prima dell’esortazione di Steve Jobs.

Ancora, durante il Codemotion si è creata una incredibile coincidenza: io e il mio Amico storico Massimo Farina (che si occupa di Diritto dell’Informatica) ci siamo trovati nella stessa aula, uno di seguito all’altro, a presentare un seminario. Insomma, dopo anni passati sui banchi di scuola e anni di avventure, la vita continua a farci incontrare e lavorare assieme.

codemotion_panel

Infine, vorrei ancora una volta ringraziare Mara Marzocchi (e Marco Casario, e Chiara, e Massimo, e Viviana, e Gosia, e…. tutti) perché ha avuto l’intuizione del Codemotion e la tenacia per realizzarla.

Sviluppare applicazioni per Android in 7 giorni

Una delle domande che mi viene posta più di frequente è quale sia il modo migliore di approcciare lo sviluppo su Android.

Solitamente la risposta è semplice: “prendi i tutorial ufficiali e uno smartphone con cui giocare, lascia perdere le bibbie e gli emulatori”. Ritengo, infatti, che i tutorial ufficiali siano ben fatti e che toccare con mano il risultato del proprio lavoro sia gratificante e sfidante allo stesso tempo.

Mi rendo conto, però, che oggi Android è davvero tropo grande per partire da là (nel 2008, quando ho iniziato a giocarci, era decisamente molto più piccolo… seppur enorme rispetto a JME!). Anche i tutorial cominciano ad essere tanti e spesso diventa difficile orientarsi. Fermo restando il consiglio sull’uso di uno smartphone fisico, credo che un ottimo aiuto per avvicinarsi alla programmazione Android sia il libro recentemente pubblicato da Matteo Bonifazi per l’editore LSWR. “Sviluppare applicazioni per Android in 7 giorni” è un libro onesto: in poco meno di 200 pagine e senza la pretesa di candidarsi a onniscenza di Android, questo volume insegna le basi per tradurre le idee in app funzionanti e pubblicabili. Un passo per volta, un tema al giorno, appunto, per una settimana, dal setup dell’ambiente di sviluppo alla pubblicazione sul Play Store. Compresi tracciamenti e pubblicità. Senza paroloni, senza trucchi (tipo traduzioni 1:1 di altri testi, ndr). Un libro onesto, appunto, scritto da chi il codice lo scrive tutti i giorni. Il titolo non deve tranne in inganno: non è una guida imprecisa o all’acqua di rose, ma è evidente che l’autore ha faticato non poco per essere conciso (e già Pascal dice che essere brevi è molto più faticoso che essere prolissi: “Questa lettera è più lunga delle altre perché non ho avuto agio di farla più breve.”). Ovviamente il lettore deve conoscere i concetti base della programmazione in linguaggio Java e deve possedere i fondamenti della programmazione ad oggetti.

App-Android-7-giorni

C’è tutto? No, assolutamente no. C’è quello che occorre per iniziare? Sì, assolutamente sì. Matteo ha sapientemente tolto dettagli inutili, lasciando quelli che servono a comprendere con rigore i meccanismi base del sistema. Insomma, il libro vale quel che costa e il tempo che si passa a leggerlo. Per molti aspetti, ha un approccio da maker, con la coscienza che puntare ad oltre un miliardo di device richiede comunque metodo.

Il libro è disponibile in formato cartaceo e ebook su Amazon e altri bookstore.

C’è anche un sito ufficiale a supporto: https://androidinsettegiorni.wordpress.com/

Una preview dell’iPad nel 2004?

Gli Incredibili e’ un film di animazione prodotto dalla Pixar nel 2004; e’ stato un film di grande successo commerciale (oltre 260 milioni di dollari di incassi!) e buon riscontro della critica. Come tante realizzazioni di Pixar e di Dreamworks, anche Gli Incredibili fa parte della tipica videoteca per bambini. E non solo bambini: a me lo ha regalato una cara amica per il compleanno e qualche giorno fa ho avuto modo di riguardarlo e scoprire… qualcosa di veramente incredibile.

Tutti sappiamo che la Pixar e’ stata resa cio’ che e’ oggi grazie al sostegno economico (e non solo) di Steve Jobs, che la compro’ nel 1986; il successo arrivo’ con Toy Story nel 1995, quasi dieci anni dopo l’acquisto di Jobs e circa 10 anni prima della pubblicazione de Gli Incredibili.

Guardiamo le cose da un altro punto di vista. Nel 2007 Apple lancia l’iPhone e nel 2010 arriva l’iPad. La leggenda (?) vuole che l’iPhone abbia avuto una gestazione di circa 5 anni (ovvero, i lavori sono iniziati due anni prima della pubblicazione de Gli Incredibili), ma pare che il lavoro originale di Apple su schermi touch sia iniziato su qualcosa riconducibile all’iPad piu’ che all’iPhone, ma che poi si decise di optare per il mercato della telefonia mobile, piu’ effervescente e reattivo in quel periodo. Comunque stiano le cose, e’ molto probabile che nel 2004 l’idea di “iPad” fosse nell’aria da quelle parti. E la cosa incredibile è che… Bob, il capofamiglia de Gli Incredibili, riceve un messaggio con qualcosa che ricorda PARECCHIO un iPad.

Si tratta di una tavoletta, evidentemente metallica, molto sottile e soprattutto con un unico (per quanto grosso) pulsante alla base.

Nel 2004 e’ passato inosservato come qualcosa di fantascientifico (mica banale a quei tempi avere un oggetto del genere, cosi’ sottile e con immagini in movimento ad alta definizione!), oggi passarebbe inosservato perche’ scontato. Nel mezzo, pero’, ci sono iPhone e iPad.

Chissa’ se in quei fotogrammi c’e’ un “assaggio” del futuro che Apple stava preparando…

Le tante (troppe) risoluzioni dei device Android

Qualche mese fa l’ottimo sito Melablog ha pubblicato una infografica realizzata da Chris Koerner mentre si attendeva il lancio dell’iPad 3 (poi svelato come New iPad). L’infografica, che qui sotto riporto per semplicità, mostrava le (allora potenziali) 4 risoluzioni diverse nel mondo iOS (in realtà due, ciascuna con il suo doppio):

E’ immediato constatare che su Android le risoluzioni sono MOLTE DI PIU’; ho pensato,dunque, di rappresentare le dimensioni in scala di tutte le risoluzioni dei terminali Android che conosco finora. Alcune figurano due volte, ad esempio la 600×1024 (portrait) del primo Samsung Galaxy Tab 7″ e la 1024×600 (landscape) del nuovo Samsung Galaxy Tab 7″ Plus, poiché effettivamente mentre i tablet Android più recenti sono pensati per un accesso al 99% in landscape (si pensi, ad esempio, al fatto che la stessa applicazione Android Market funziona solo in lanscape!), mentre i primi tablet e altri oggetti ibridi come il Galaxy Note sono esplicitamente pensati per un utilizzo in modalità verticale.

(cliccare per vedere ingrandito)

Nel dettaglio:

  1. 240×320 del piccolo Huawei Ideos
  2. 240×400 del Samsung Galaxy Mini di qualche tempo fa
  3. 320×480 del primo HTC Dream (come il primo iPhone)
  4. 480×800 del Nexus One
  5. 480×854 del Motorola Milestone
  6. 540×960 del HTC Sensation
  7. 600×1024 del Samsung Galaxy Tab 7″
  8. 720×1280 del Samsung Galaxy Nexus
  9. 1280×800 di tutti i primi tablet Honeycomb, ad esempio il Motorola Xoom e il Samsung Galaxy Tab 10.1

Emerge cosi’ che ci sono 9 risoluzioni diverse, che diventano 11 se si considerano separate le due modalità portrait e landscape delle risoluzioni 600×1024 e 800×1280. Malgrado l’API di Android consenta di scrivere con una certa agilità UI scalabili, è innegabile che supportare una così grande varietà di risoluzioni e densità richieda più di una accortezza da parte di sviluppatori e designer. Ne è prova il fatto che, a partire dalla release 3.2, è finalmente arrivato il modo di specificare esattamente per quale display è progettato un layout, uscendo dalla logica “troppo sempliciotta” degli screen small, normal, large… Questo proliferare di risoluzioni è forse uno degli aspetti più controversi dell’evoluzione di Android e, per certi versi, sembra che a Mountain View abbiano sottovalutato il problema o semplicemente gli è sfuggito di mano.

Libro Android Programmazione Avanzata

Dopo tanti mesi di lavoro, tanto codice, tanti device, tanta revisione è finalmente arrivato il libro scritto a quattro mani con Emanuele Di Saverio: Android – Programmazione Avanzata.

Il libro, pubblicato dalle Edizioni FAG di Milano e realizzato con la partecipazione di Samsung Italia, è dedicato a chi già conosce la programmazione su Android e vuole approfondire alcune tematiche avanzate. Niente “Hello World”, niente introduzione ai componenti grafici e alle Activity: solo tecniche avanzate o approfondimenti su argomenti solitamente poco trattati (ad esempio, il testing o la tecnologia NFC).

Il testo è, in un certo senso, la summa dell’esperienza maturata in diversi anni di lavoro sulla piattaforma Android. Nasce dal pratico (progetti industriali) e dall’esperienza concreta degli autori (da Android 1.x ad Android 4!). Mancano, pertanto, quegli argomenti su cui né io né Emanuele abbiamo mai lavorato intensamente (ad esempio, giochi e grafica 3D). Per chi fosse interessato, in questa presentazione sono descritti nel dettaglio i nove capitoli che lo compongono:

Il libro è già acquistabile presso:

Chi preferisse acquistare l’e-book può farlo qui:

Prime impressioni su Honeycomb

Ho avuto la possibilita’ di toccare con mano le qualita’ di Honeycomb, la release 3.0 di Android dedicata ai tablet, su un Motorola XOOM WiFi arrivato dagli Stati Uniti (ci vorra’ ancora un po’ per vederlo in Italia).

Non sono solito fare recensioni di hardware (le lascio agli specialisti, quali TuttoAndroid o Androidiani), ma vorrei comunque raccontare le mie impressioni. Vorrei anche sorvolare molti degli aspetti positivi: anche questi sono piu’ che celebrati da Google e Motorola 🙂 In generale, Honeycomb e’ un ambiente di buona qualita’, molto potente e con una buona usabilita’; non e’ certo un prodotto rivoluzionario ne’, credo, il punto di riferimento per la user experience, ma sono convinto che ci siano basi solide e valide per creare dell’ottimo software per i tablet Android.

E’ inevitabile il confronto con il leader: l’iPad. Che piaccia o che non piaccia, prima dell’iPad i tablet erano un mero esercizio tecnologico; con l’arrivo dell’iPad, il mondo s’e’ messo ad inseguire Apple, borbottando, criticando, deridendo, ma comunque copiando. A quanto pare Apple ha fatto molte scelte giuste e neppure tanto scontate, se la concorrenza fatica anche a copiarle.

Io sono palesemente entusiasta del mondo Android e di questa piattaforma ho fatto il mio futuro professionale dei prossimi anni; nonostante questo, non posso non trovarne le lacune e, anzi, credo che evidenziare i punti deboli sia il modo migliore per trovare spunti di miglioramento.

Ecco qualche commento sparso:

– UI. Credo che Google abbia fatto un bel lavoro: l’interfaccia utente di Honeycomb e’ piacevole, abbastanza originale in se’ e sufficientemente coerente con quanto esiste su smartphone. Me la aspettavo piu’ bella, ma questo e’ un giudizio del tutto soggettivo. Ci sono nuove animazioni, ci sono nuovi menu’ della ActionBar e nuovi tab per navigare tra i Fragment di una Activity. Questa, in realta’, e’ una degli aspetti che mi lasciano perplesso: le applicazioni esistenti utilizzano i menu’ “classici” di Android (che qui non sono piu’ accessibili attraverso tasto fisico, ma per mezzo di un pulsante virtuale che compare nella System Bar immediatamente a destra del tasto di navigazione tra le applicazioni aperte), mentre le nuove si possono avvantaggiare del nuovo menu’: l’utente, dunque, si trova di fronte due user-experience diverse e deve necessariamente verificare, per ogni applicazione, dove sia stato messo il menu’. I nuovi tab, inoltre, sono sicuramente una bella novita’ e rinfrescata rispetto ai TabWidget della versione smartphone, ma quest’ultima continuera’ a soffrire di arretratezza e soprattutto costringera’ gli sviluppatori a fare due versioni delle applicazioni. E considerato che Android non offre un meccanismo simile all’Universal Binary di iOS, il processo complessivo si complica un po’ (si, lo so, giocando con risorse e codice si puo’ avere qualcosa di molto piu’ potente dell’Universal Binary, ma – ripeto – si tratta di qualcosa di piuttosto laborioso e decisamente non lineare). Qui sotto potete vedere il rendering dei menu’ nuovi (sul browser) e di quelli vecchi (sull’ottima Bluetooth Fine Transfer di Medieval Software).

– Hardware. Il Motorola XOOM e’ “un grosso tablet”. Non voglio ripetere qui le misure pubblicate in ovunque sul web, ma al tocco sembra piu’ corposo dell’iPad di prima generazione, decisamente enorme se paragonato all’iPad 2. Anzi, quello che stona e’ proprio il fatto che XOOM e iPad 2 siano praticamente coevi (hanno due mesi di differenza) ma lo XOOM sembra di una o due generazioni precedenti. Piu’ grosso, plasticoso e con la superficie touch decisamente meno cristallina di quella dell’iPad. Direi, pero’, che spessore, peso e alluminio siano gli aspetti che rendono l’iPad migliore. Curiosamente, lo XOOM nasce come dispositivo landscape: la videocamera, infatti, e’ posta sul lato lungo anziche’ su quello corto, come avviene sull’iPad. Anche il marchio Motorola leggibile solo in landscape suggerisce di impugnare il tablet in posizione orizzontale. Direi che per vedere un tablet figo dal punto di vista hardware dovremo aspettare i nuovi modelli Samsung.

– Prestazioni. Molto veloce. Merito del sistema operativo, merito del dual-core, merito della grafica, merito della fata turchina. Non lo so, ma e’ molto veloce. Unica grave pecca e’ una inspiegabile lentezza del browser. Scrollando le pagine (ad esempio verso l’alto) la porzione che era a schermo scorre velocemente mentre la nuova appare bianca e si aggiorna dopo una frazione di secondo. Questo e’ piu’ evidente su pagine complesse ma in generale si manifesta con qualsiasi sito. Capisco che il numero di pixel da gestire e’ grande rispetto ad uno smartphone, ma e’ anche vero che la potenza di calcolo a disposizione non e’ poca e soprattutto il browser diventa un componente indispensabile su un oggetto di questa categoria e, dunque, dovrebbe essere quello meglio curato. Qui sotto ho riportato il grafico del benchmark di Quadrant eseguito sullo XOOM:

– Applicazioni. Detto senza mezzi termini: quelle non ottimizzate per Honeycomb fanno proprio schifo! Un’applicazione semplice in ambiente smartphone, fatta con componenti standard e niente fronzoli, che puo’ essere definia “passabile” sul cellulare, vista sullo XOOM diventa davvero brutta. Il problema piu’ grosso (ne parlo nel prossimo punto) e’ che il Market non consente di filtrare le app fatte esclusivamente per Honeycomb: bisogna affidarsi al titolo assegnato dal publisher (“HD”, “for Honeycomb”, “tablet”). Il tema di default di Honeycomb, poi, e’ con fondo bianco, in leggera “controtendenza” rispetto al nero degli smartphone. Insomma, per sfruttare bene i tablet ci vogliono applicazioni ad hoc.

– Market. Da quanto e’ uscito l’Android Market ha collezionato piu’ lacune che traguardi di download. Classifiche non localizzate, prezzi delle applicazioni nella valuta del publisher (mai viste le applicazioni con il prezzo espresso in Yen? 😀 ), mancanza delle statistiche per gli sviluppatori: queste sono solo alcune delle mancanze dell’Android Market che con il tempo sono state risolte. Ora, con l’arrivo di Honeycomb, molte di quelle mancanze sono piu’ o meno colmate (resta quella delle classifiche localizzate) ma se ne presenta una nuova, che accennavo sopra: non c’e’ (o, se preferite, non ho trovato) un modo automatico per vedere SOLO per applicazioni sviluppate per Honeycomb. Il Market consente di sfogliare tutta la lista delle applicazioni disponibili e non c’e’ quella bella suddivisione dello store che troviamo su iPad.

– Manufacturer. L’ho twittato una marea di volte e non ho timore di scriverlo nuovamente qui: malgrado Motorola produca dell’hardware di ottima qualita’, ha una politica pessima di supporto all’aggiornamento software. Detto in parole povere, comprare un terminale Motorola significa potenzialmente mettersi in casa un oggetto che sara’ obsoleto con il prossimo rilascio del sistema operativo, perche’ verosimilmente Motorola lo aggiornera’ dopo molti mesi o non lo aggiornera’ per niente. In passato, vedere il mio HTC Magic del giugno 2009 ufficialmente aggiornato a Froyo entro il 2010 e contemporaneamente vedere il Motorola Milestone comprato a gennaio 2010 ricevere quello stesso aggiornamento ad aprile 2011 mi ha fatto arrabbiare non poco. Ho dunque il ragionevole dubbio che Motorola abbandoni lo XOOM (primo device al mondo con Honeycomb) cosi’ come ha di fatto abbandonato il Milestone (primo device al mondo con Eclair, nella sua declinazione americana Droid). Arrivera’ lo XOOM 2 o qualcos’altro che distarra’ il manufacturer dai clienti che le hanno dato fiducia al primo lancio. Insomma, grandi annunci, grandi fanfare, ma poi l’acquirente e’ lasciato a se’ stesso. Inutile dire che se i manufacturer non supporteranno per almeno DUE anni i terminali Android in commercio, Apple restera’ l’unica garanzia di avere un oggetto che diventa obsoleto piu’ lentamente. Qualcuno dice che Apple lo fa perche’ ha pochi modelli in circolazione: questo e’ vero, ma se un manufacturer decide di vendere 10 modelli DEVE attrezzarsi per supportarli tutt’e 10. Inoltre – lo sappiamo bene – su 10 modelli che escono difficilmente abbiamo 10 hw diversi: cambiano poche cose, giusto per catturare l’attenzione di diverse fasce di clientela.

– USB. Una nota a parte merita l’interfacciamento via USB; la cosa potra’ apparire strana e di poca importanza, ma secondo me cambia parecchio la user experience su Android. Finora gli smartphone equipaggiati con Android sono stati caratterizzati da pochissima memoria flash interna (da 256MB al giga, circa), lasciando alla SD card il compito di memorizzare immagini, musica ed eventualmente i dati voluminosi delle applicazioni piu’ esigenti. Poiche’, pero’, le applicazioni si installano della memoria interna, era facile saturarla in breve tempo, costringendo l’utente a rimuovere delle applicazioni per installarne di nuove. Prima con delle utility di terze parti (utilizzabili sono con terminali rooted), poi con l’arrivo di Froyo, e’ stato possibile installare le applicazioni su SD. Anche questa e’ stata una soluzione tampone: la memoria a disposizione del sistema operativo restava comunque ridotta e comunque la rimozione della SD rendeva invisibili le applicazioni su di essa installate. Stesso discorso per terminali quali l’ottimo Nexus S, che pur dichiarando 16GB di memoria, offre tutto questo spazio come storage USB (esterno) e, dunque, soggetto alle stesse limitazioni di cui sopra (e’ pur vero che lo spazio a disposizione del sistema e’ di 1GB, dunque ben oltre la media dei terminali Android). In sintesi: per poter esportare la SD (o porzioni della memoria interna) questa deve essere “staccabile” e condivisibile sia USB. Finora questo e’ avvenuto grazie al profilo MSC (Mass-Storage Class), che consente al computer host il controllo diretto e a basso livello della periferica di memorizzazione (sino al livello del filesystem fisico). Honeycomb sostituisce MSC con il profilo MTP (Media Transfer Protocol), che condivide un filesystem logico accessibile contemporaneamente dal device e al computer host. In pratica, il controllo a basso livello resta ad Android, mentre il computer accede al filesystem attraverso un demone che lo virtualizza (come se fosse un server FTP o WebDAV). Il computer host, dunque, non puo’ effettuare operazioni come formattazione o partizionamento del filesystem. Il vantaggio e’ immediato: i 32GB del device sono sempre accessibili e tutti a disposizione del sistema operativo e delle applicazioni. Finalmente si lavora senza quelle odiose limitazioni in mente. E anche il pannello di controllo di dice che c’e’ un’unica memoria, piu’ che abbondante:

Vi e’, ovviamente, il rovescio della medaglia: mentre MSC e’ universalmente supportato, per MTP occorre un driver. Su Windows e’ integrato con il sistema operativo: il protocollo e’ stato progettato da Microsoft per i suoi player mp3! Su Linux ci si appoggia alla libmtp (usata da molti software), mentre su Mac OS X l’unica possibilita’ e’ rappresentata dall’utility XNJB. Dubito fortemente che vedremo MTP integrato nel finder in tempi brevi (ce la vedete Apple a supportare contemporaneamente un protocollo di Microsoft per i tablet di Google? 🙂 ).

In sintesi: benvenuto Honeycomb, c’era bisogno di questo slancio nel mondo Android. Ora aspettiamo il merge con la piattaforma smartphone, un Market piu’ intelligente, una UI piu’ coerente, una maggiore serieta’ dei manufacturer per l’aggiornamento dei terminali.

Anche i migliori sbagliano

Anche i migliori sbagliano. Ne e’ prova lo screenshot qui sotto, catturatu su un iPhone. Se non c’e’ “niente da annullare”:

1) perche’ e’ mostrata quella dialog?

2) perche’ il pulsante mi invita ad… annullare?

Centinaia di anni/uomo di design, test e sviluppo non hanno salvato iOS dal proporre all’utente una informazione ambigua e inutile. A voler essere pignoli (e magari un po’ stupidi) non si dovrebbe mai premere il pulsante “Annulla” proprio perche’ non c’e’ “niente da annullare”. 🙂

Mi ricorda una finestra di OS/2, di tanti anni fa: all’utente veniva posta una domanda e i tre pulsanti alla base della finestra avevano come etichette “SI”, “NO”, “REGREDISCI”. Evidentemente il traduttore in IBM aveva pensato di tradurre “CANCEL” con “REGREDISCI”. Tremendo! Peccato (per il traduttore) che la regressione non sia quasi mai un fenomeno auspicabile, a meno che non si tratti di una malattia (e allora ben venga!). E cosi’, per anni ho temuto che clickando “REGREDISCI” mi sarei trasformato in scimmia oppure sarei tornato nel brodo primordiale. Accetto i rischi del “SI” e le conseguenze del “NO”, ma, per favore!, non chiedetemi di regredire!

Android Stack

Spesso amici e colleghi mi chiedono quali terminali Android uso per fare i test… giusto qualche giorno fa li ho messi tutti assieme e ho fatto questa “foto di famiglia”:

IMG_7813

Se volete conoscere quali terminali sono, guardate la foto su Flickr oppure guardate lo stack partendo dal basso (Archos 7 Home Tablet, Zii EGG, Motorola Milestone, Geeksphone One, HTC Dream, HTC Magic, LG Optimus One, Samsung Galaxy Mini, ZTE Blade, Huawei U8220, Samsung Nexus S, Huawei Ideos).