[info][pareri] thl w200

Quote:

---

Originariamente inviato da davideowl

sto valutando l'acquisto del telefono ragazzi, la cosa che mi preme di più è il segnale in primis, ho avuto molti samsung, ed è un continuo perdere e recuperare il segnale 3g nella mia zona, una vera rogna, questo cellulare come funziona sotto questo aspetto? col mio ace devo sempre andare offline/online per recuperare il segnale :( non trovo inoltre le specifiche della modalità UMTS, quanto va in download e upload? secondo punto cruciale, la fotocamera... se qualcuno potesse farmi vedere foto fatte col dispositivo... è una parte molto importante per me... grzie a tutti quelli che mi aiuteranno :)

---

Allora io ho sia tim che tre....la tim fa davvero schifo(e dico poco)...per non utilizzare altri termini... sembra l'albero di natale cambia da E ad H ad H+ e va solo se è in H+ senno prima di aprire una pagina ti cadono le braccia. la tre dipende dalla copertura ma mantiene molto di più la H+
Se leggi comunque solo uno slot (indistintamente) può essere attivato in 3g l'altro no...io che mi sono sempre lamentato del segnale dei telefoni questo lo posso reputare buono.

Per le dogane se potete evitate quella del nord (BG).

Sempre parlando di tweaks (istruzioni da aggiungere alla build.prop)...ce ne sono a decine ma non significa che funzionino tutti o che sia opportuno metterli. Ogni modifica può avere pro e contro...o solo contro. E' facile lasciarsi andare a facili entusiasmi alla prima raccomandazione che si trova in rete: più difficle invece è andare a fondo e trovare dei test reali per i processori MT...o testarli da se.
Ludolo per esempio ha selezionato con grande cura una serie di tweaks che condivido e che ha inserito nella sua ultima ROM.
Non me ne voglia se prima di parlare degli altri, indicherò i due tweaks che non mi convincono, ovvero:
ro.kernel.android.checkjni=0
ro.kernel.checkjni=0
Questi due tweaks influiscono sulla JNI (Java Native Interface) la quale fornisce l'interfaccia che permette al codice Java (delle app) di interagire con il codice in C/C++. La JNI (di default) opera una serie di verifiche (checks) continue su eventuali bug dei software e li blocca oppure li corregge. Questo rallenta il sistema (con il tweak si va più veloci) ma al contempo assicura che un bug non causi danni.
Questo è possibile per diversi motivi fra cui:
A) i bug sono fisiologici nella programmazione
B) gli sviluppatori possono anche essere pigri sapendo che c'è la JNI che protegge gli utenti
C) se un cell è rootato e gira un programma che ha accesso ai livelli più bassi, allora potrebbe esserci un pericolo

Il tweak elimina tutti i checks! Alla fine, nel tempo la probabilità di incappare in un bug è alta (specie se si installano molte app) e magari si risolve tutto con un reboot o un restore. Ma se il bug provoca un danno hardware...

Insomma, non sono del tutto convinto che sia sano eliminare i checks in cambio di una migliore performance...specie se non è significativa.
Se ho puntato il dito è solo per sentire anche le vostre opinioni, specialmente quella di Ludolo!

Sto pensando di prenderlo da ******* dato che fanno l'assicurazione sulla dogana e sono affidabili. La fotocamera è buona perché l'ho provata personalmente, un mio amico l'ha già preso. L'ho provato per qualche minuto e mi è sembrato molto fluido e veloce..

Quote:

---

Originariamente inviato da Bokonon

Non me ne voglia se prima di parlare degli altri, indicherò i due tweaks che non mi convincono, ovvero:
ro.kernel.android.checkjni=0
ro.kernel.checkjni=0

---

Grazie della spiegazione dettagliata, che sinceramente è più chiara di come avrei potuto spiegarla io. :)

Condivido in pieno, vedo di aggiornare il post della ROM riportando la tua spiegazione se non hai niente in contrario in modo che chi volesse andare sul sicuro sappia che vanno tolte quelle due righe.

Per quanto mi riguarda, la ROM è fatta "a mia misura", nel senso che flashando spesso se ogni volta che lo riporto in condizione normale devo mettermi ad aggiungere o togliere qualcosa in /system perdo un sacco di tempo. E installando poche app e tutte collaudate (non uso giochi, non uso social a parte G+, ecc.) preferisco un pelino di ottimizzazione in più anche a discapito di qualche problema in caso di bug.

Per quanto riguarda le altre ottimizzazioni in build.prop, ho semplicemente letto un po' di thread su xda e scelto quelle su cui mi sembrava ci fosse più accordo. In fin dei conti, con una 15ina e più di anni di esperienza su Linux alle spalle in ambito professionale, sulle magie con una riga di configurazione sono d'accordo con te e non ci credo nemmeno io. :)

Quali differenze ci sono tra le due versioni della rom di ludolo la 130806 e la 130815.
Grazie

magie no di sicuro ma spesso e volentieri si trovano delle configurazioni di default fatte con lo stampino copiando quelle che andavano sul dispositivo precedente con hardware completamente diverso per la serie se andava su quello deve andare pure su questo, in quel caso una configurazione fatta bene puo' davvero cambiarti la vita.

Quote:

---

Originariamente inviato da davant71

Quali differenze ci sono tra le due versioni della rom di ludolo la 130806 e la 130815.
Grazie

---

la prima supporta soltanto il touchpad "vecchio", la seconda pure il nuovo modello - per il resto thl non rilascia changelogs quindi difficile dirlo.

Quote:

---

Originariamente inviato da ludolo

Grazie della spiegazione dettagliata, che sinceramente è più chiara di come avrei potuto spiegarla io. :)

Condivido in pieno, vedo di aggiornare il post della ROM riportando la tua spiegazione se non hai niente in contrario in modo che chi volesse andare sul sicuro sappia che vanno tolte quelle due righe.

Per quanto mi riguarda, la ROM è fatta "a mia misura", nel senso che flashando spesso se ogni volta che lo riporto in condizione normale devo mettermi ad aggiungere o togliere qualcosa in /system perdo un sacco di tempo. E installando poche app e tutte collaudate (non uso giochi, non uso social a parte G+, ecc.) preferisco un pelino di ottimizzazione in più anche a discapito di qualche problema in caso di bug.

Per quanto riguarda le altre ottimizzazioni in build.prop, ho semplicemente letto un po' di thread su xda e scelto quelle su cui mi sembrava ci fosse più accordo. In fin dei conti, con una 15ina e più di anni di esperienza su Linux alle spalle in ambito professionale, sulle magie con una riga di configurazione sono d'accordo con te e non ci credo nemmeno io. :)

---

E' quasi un mese oramai che ho preso il w200 e sono passato ad Android (di cui non sapevo nulla). Adoro rovistare e comprendere il funzionamento dei sistemi operativi ma non ho più il tempo di una volta. Oggi però pioveva e ho dedicato l'intero pomeriggio a letture. Sono partito proprio analizzando la tua ROM e, dopo le app, sono arrivato a studiare il build.prop. Da la, sono partito ad analizzare ogni singola riga facendo ricerche con Google. Così facendo il materiale di partenza e gli argomenti che volevo approfondire si sono allargati esponenzialmente. Ma il punto è che ho apprezzato moltissimo le tue scelte sobrie (si vede che lo fai per te) e ragionate (per esempio il ro.ril.disable.power.collapse=0 quando quasi tutti lo mettono ad 1 acriticamente). Anzi avrei una serie di domande ma prima sarebbe giusto che testassi qualcosa invece di limitarmi a leggere.

Per quanto riguarda il mio post..a dire la verità si potrebbe scrivere molto meglio. Il materiale l'ho trovato su un sito abbandonato di una ex-azienda cinese (la Netmite) Index of /android/mydroid
Praticamente hanno lasciato l'accesso a tutta la documentazione che avevano raccolto su Android e all'interno ci sono documenti risalenti al 2007/2009 con le note argomentate di chi ha progettato il sistema (molto affascinanti anzichenò).
In particolare ci sono questi due documenti.
Dalvik Optimization and Verification
JNI Tips
Che spiegano la natura della DelvikVM, la natura della JNI e le ragioni delle scelte che furono fatte: mai vista una pippa mentale del genere...e tutto per ottimizzare assai artigianalmente le prestazioni sui vecchi telefonini lenti e con poca RAM (tempo un anno e sarà tutto obsoleto e inutile con la potenza di calcolo e la RAM dei futuri telefonini).
All'interno dei documenti (specialmente il primo) ci sono tre link ad altri documenti che approfondiscono come funziona la Verification attraverso l'Extended Checking della JNI e perchè è necessaria.
La DalvikVM è stata ottimizzata per ridurre al minimo il carico di RAM e di CPU: e lo fa creando i DEX file (diventano ODEX quando sono stati OttimizzatiDEX). I DEX non vengono creati in modo univoco ma bensì in tre modi diversi:

A) The VM does it "just in time". The output goes into a special dalvik-cache directory. This works on the desktop and engineering-only device builds where the permissions on the dalvik-cache directory are not restricted. On production devices, this is not allowed.
B) The system installer does it when an application is first added. It has the privileges required to write to dalvik-cache.
C) The build system does it ahead of time. The relevant jar / apk files are present, but the classes.dex is stripped out. The optimized DEX is stored next to the original zip archive, not in dalvik-cache, and is part of the system image.

Mentre gli ultimi due sono fatti prima di far girare un programma (e sono anche laragione per cui dopo il flash di una ROM il boot è più lungo), è il primo che può essere pericoloso. In pratica tutto il codice di un'applicazione che non è stato possibile dexizzare in una fase precedente (classes that failed to pre-verify), viene dexizzato al volo dall'interprete JIN della DalvikVM...e questo include anche possibili porzioni di codice che vengano inviati via internet mentre gira la app!
Why verify? If an app wants to download bits of interpreted code over the network and execute them, it can safely do so using well-established security mechanisms.
Chi ha scritto i documenti, fa notare (in punti diversi) che la verifica dei DEX (al volo o preventivi) è necessaria perchè the Linux access permissions are expected to prevent tampering; if you can get around those, installing faulty bytecode is far from the easiest line of attack..
Ma vabbè, nessuno programmerebbe codice malevolo se non sapesse che una grossa fetta di user ha rootato il telefono e disabilitato i checks della JNI (che vengono elencati nel secondo documento).
The extended JNI checks will cause the system to run more slowly, but they can spot a variety of nasty bugs before they have a chance to cause problems.
Il vero problema IMHO è dettato dal fatto che il dexing crea un file ottimizzato (riordinando fra l'altro i puntatori ed evitando errate allocazioni di memoria) eliminando alla radice possibili conflitti che durante un'operazione delicata quale una scrittura su rom potrebbero fare danni. Anche un gioco che si impalla e manda segnali fuori dal range di sicurezza all'hardware potrebbe rompere il dispositivo.

Quote:

---

Originariamente inviato da poweris

Sto pensando di prenderlo da ******* dato che fanno l'assicurazione sulla dogana e sono affidabili. La fotocamera è buona perché l'ho provata personalmente, un mio amico l'ha già preso. L'ho provato per qualche minuto e mi è sembrato molto fluido e veloce..

---

Al buio la fotocamera arranca. Dovrai installarne un'altra.



@Bokon: Ma chi sei tu? Svelaci la tua identità segreta! Ahahahahah


Inviato dal mio GT-S5830 usando Androidiani App

Spedizione in consegna MILAN - ITALY 09:16
arrivato!!!! 27 euro circa di dogana