Sezione Android

Beh... coi computer forse non è la stessa cosa. Io ho un MB late 2009 e gira benissimo oggi con Maveriks dopo 5 anni.

Fai girare un iPhone 3gs con iOS 7 (ammesso che si possa installare, cosa che non credo).... o un Nexus One del 2010 con android 4.4.4...

 

[video=youtube;SM-LuRGI5z0]


PS. Non si sente più [MENTION=17830]Scrondo[/MENTION]... Che cosa starà combinando col suo N4 ?

 

R: Sezione Android

Galaxy Nexus credo si fermi a JB....

Sicuramente lo saranno i vari HTC m8, m7 etc..

 

A me ha crashato ingloriosamente...

Qualche malalingua (@Harakid ) sostiene per le infestazioni da demoni che saltuariamente affliggono i miei cell ma credo si possa essere trattato anche di una malinstallazione....

Al momento però avendo rootato mi godo i moduli di Xposed e poi quando sarà (autunno si dice) ritornerò stock con android L, più che altro perchè credo uscirà solo in ART che non è supportato da Xposed. Pazienza...

Un OS che ha 5000 API nuove magari offre anche qualche altra emozione che non sia un orologio al centro della barra notifiche o la navigation bar custom....

Il tuo Nexus 4 avrà lunga vita...

 

No è bastato un po' di Erbaluce di Caluso, 4.4.4 e un po' di root...

Intanto un po' di articoli interessanti di Androidworld.it sul futuro di Xposed in merito all'avvento definitivo di ART, sulle performance attese da quest'ultimo.. e sui vari file odex e deodex...

Una nota : L'affermazione che ho evidenziato grassettata in rosso mi stupisce un po' dato che non ho mai riscontrato in android delle pecche di fluidità o lentezza delle applicazioni. Era fluido e veloce l'HTC con gingerbread 2.3.7 come lo è oggi il Nexus 5, le cui caratteristiche sono state elogiate persino da un " talebano iPhone" come mio figlio (4s).

Ovviamente data la frammentazione di android queste caratteristiche possono essere più o meno presenti nei vari devices specie quelli di gamma medio bassa, ma se dobbiamo confrontare android con iOS è altrettanto ovvio che ad essere presi in considerazione debbano essere i top di gamma, dato che l'iPhone per caratteristiche e prezzo appartiene a quella categoria, ed io tutte queste differenze a sfavore di android proprio non le vedo....

Xposed e ART: quando e come arriverà il supporto ufficiale?

Dopo che Google ha annunciato che Android L adotterà solo e soltanto la runtime ART, in molti hanno tempestato di domande in merito Rovo89, sviluppatore del celebre framework Xposed, reo di non aver mai supportato ART finora.

Rovo ha per la verità rilasciato vari commenti qua e là, e ora che il blog di XDA li ha un po’ raccolti assieme, sicuramente ne sentirete parlare. Vediamo quindi di fare rapidamente chiarezza in merito, per capire come stanno e come andranno le cose.

In realtà, il discorso è abbastanza semplice. Finora Xposed non ha mai supportato ART perché incompleto. Inoltre, come già abbiamo avuto modo di osservare, la versione di ART presente nella preview di Android L non è la stessa che troviamo su KitKat, ed in ogni caso non è definitiva.

Il supporto ad ART arriverà in futuro quindi(forse già con la preview di L) ma al momento non è possibile fare previsioni esatte su quando ciò avverrà (“se ci vorranno settimane, ci vorranno settimane”), perché Google sta continuando a migliorare la nuova runtime, ed affrettarsi ora a modificare Xposed potrebbe voler dire rifare nuovamente il lavoro al momento del rilascio finale di Android L. Lo scopo non è “farlo funzionare”, ma “farlo funzionare al meglio”: c’è una bella differenza.

In ogni caso, il supporto futuro ad ART in Android L non implica che Xposed funzionerà con ART suKitKat. Le due implementazioni di ART sono troppo diverse, e non sarà facile mantenere il supporto ad entrambe, tanto più che la prima sarà definitiva, mentre la seconda, salvo cambiamenti da parte di Google, non lo sarà. In ogni caso la decisione in merito non è definitiva né irrevocabile, quindi incrociamo pure le dita, e riponiamo la nostra fiducia in Rovo89, che in fondo, finora, non l’ha mai delusa.

 




Android L: ART e Project volta cambieranno davvero prestazioni e autonomia?

 


ART non sarà la panacea a tutti i mali, ma di certo ci prova. AnandTech ha infatti analizzato a fondo la nuova runtime che si trova nella preview di Android L (diversa da quella presente in KitKat) e, senza scendere troppo nel dettaglio tecnico, ha concluso che, in prospettiva, Android sarà finalmente in grado di competere del tutto con iOS in termini di fluidità e performance delle applicazioni,risolvendo al contempo tanti problemi per gli sviluppatori, che non dovranno più ricorrere ad “esercizi ginnici” per far girare velocemente il proprio lavoro.

È comunque importante sottolineare che l’ART di adesso non è quello che debutterà con la versione definitiva di Android L, e non è nemmeno lo stesso di sei mesi fa, il che già di per sé è molto incoraggiante.

Le performance che ART promette in confronto alla Dalvik sono piuttosto significative: si parla di unavelocità circa doppia, ma Google afferma che nella release finale di Android L potremmo spingerci fino al triplo.

L’unico effetto negativo, è dovuto al fatto che la compilazione ahead of time (AOT) porta via più tempo: ovvero il primo avvio del dispositivo e la prima esecuzione di un’app saranno più lunghi di quanto avvenga adesso. Google afferma che non è niente di drammatico, soprattutto quando ART sarà completo, e per ora possiamo solo prendere per buona la sua parola.

Un altro aspetto negativo è il maggiore spazio di memoria di massa occupato dalle applicazioni, ma non è facile quantizzare di preciso quanto sia, tanto che anche AnandTech non approfondisce questo passaggio più di tanto.

 

 

 




Android dalla A alla Z: cos’è la ART?

Con Android 4.4 KitKat è stata introdotta la possibilità di utilizzare un’alternativa alla Dalvik Virtual Machine, chiamata ART, acronimo per AndroidRunTime. si tratta di un supporto ancora sperimentale, tant’è che non tutte le applicazioni funzionano se utilizzerete ART adesso: il suo inserimento è evidentemente rivolto a quegli sviluppatori che vogliano appunto testare la compatibilità e le performance delle proprie applicazioni, con quello che diventerà uno standard in una futura versione di Android.

La Dalvik utilizza un compilatore di tipo JIT (just in time), ovvero che interpreta l’applicazione al momento della sua esecuzione, inserendo poi le informazioni necessarie in un file di cache apposito chiamato Dalvik Executable (.dex), a sua volta affiancato da un altro file (.odex) che memorizza tali informazioni a fianco dell’apk dell’app stessa per un più veloce accesso futuro. ART usa invece un approccio diverso, chiamato AOT (ahead of time), compilandole in codice nativo al momento della loro installazione, e velocizzandone quindi l’esecuzione, dato che in pratica le app saranno “già pronte”.

Dal punto di vista dello sviluppatore non dovrebbe quindi cambiare nulla: le app continueranno sempre ad essere scritte nello stesso linguaggio, cambierà solo il modo in cui sarà il sistema ad interpretarle. Questo può comunque portare a delle possibili incompatibilità, ed è una delle ragioni per cui ART è stato introdotto come opzione in Android KitKat.

L’uso di ART dovrebbe, oltre ad aumentare le performance, ridurre anche il consumo di batteria, dato che l’app non verrà interpretata ad ogni sua esecuzione (anche se in realtà questo non avviene nemmeno nella Dalvik grazie all’impiego dei file .dex e .odex).

Il quadro generale è quindi molto ottimistico in materia, ma prima di gridare al miracolo sarà opportuno aspettare la versione definitiva di questa nuova e promettente runtime che, insieme al nuovo sistema di compilazione Gradle (ancora in fase di test, ne parleremo in un prossimo appuntamento), dovrebbe rendere i nostri dispositivi molto più prestanti e con lag meno frequenti.

 




Android dalla A alla Z: cosa sono odexed/deodexed?

Solitamente in una ROM ufficiale ogni apk o jar ha degli omonimi file .odex (per questo si dice che il firmware è odexed) che contengono parti dell’applicazione che vengono precaricate, in modo da accelerare i tempi di boot: la procedura nota come deodexing consiste nel convertire tali file inclasses.dex, che saranno poi compressi all’interno dei rispettivi apk o jar.

Un file deodexed (.dex) contiene in pratica la cache usata dalla Dalvik Virtual Machine (nota appunto come Dalvik-cache) per ciascuna app; un file odexed (.odex) è invece una versione ottimizzata dello stesso file .dex ed è memorizzata a fianco dell’APK, in un file separato anziché al suo interno, permettendo così un boot più rapido perché il sistema sa subito quali applicazioni precaricare.

Il deodexing è dunque un po’ come rimettere insieme tutti i pezzi dell’applicazione che prima erano invece sparpagliati, consentendo così modificare un’app senza preoccuparsi che questa vada in conflitto con la sua parte .odex caricata altrove: lo scopo principale per cui le custom ROM ricorrono al deodexing è dunque per la personalizzazione (sia grafica che dei contenuti) e l’integrità del firmware stesso; in questo modo è ad esempio possibile supportare i temi di terze parti di cui molte ROM amano adornarsi.

D’altro canto la rimozione dei file .odex rallenterà la costruzione della Dalvik-cache, allungando i tempi di boot; in ogni caso, dato che la cache verrà comunque costruita via via che le applicazioni sono utilizzate, il rallentamento è particolarmente evidente solo la prima volta che una ROM viene avviata dopo il deodexing (oppure ogni volta che la Dalvik-cache viene cancellata manualmente da recovery).

 

 

Questo vale anche per l'iPhone però.

Esce iOS 7 e non va più, che so, sul 4 e tutti a prendere il 4s...o il 5.

Che vi sia sempre stata la corsa all'ultimo device perchè di qualche msec più performante o perchè è status symbol è purtroppo vero...

Sull'affermazione riportata negli articoli "finalmente competerà con iOS" mi sono già espresso.