[Info][Pareri] Thl T100

[cybermod]

we ragazzi, su needrom è uscito da poche ore un tentativo di fix per la bussola....... ma direi molto interessante, che ne dite?

[reddog]

Il problema di pazzokli è che ha flashato un po' a capocchia questo e quello...spesso senza fare dei wipe quando servivano (ecco perché i bootloop). Nel frattempo ha perso gli IMEI e non ha mai fatto un backup.
Le droid tools possono aiutarlo a rimettere gli imei e a riattivare le sim.

Si può usare anche mobileuncle per il ripristino degli imei, ci sono un sacco di guide che spiegano dettagliatamente come procedere. L'ho imparato a mie spese perchè anche io ho dovuto usarle per sistemare il mio t100 dopo aver perso gli imei e ip del modulo wifi......

Piccola aggiunta, da 2 gg sto usando la miui 4.5 presa da needrom e devo dire che mi sto trovando da dio. E' vero che non è localizzata ma tanto anche in inglese è usabilissima. Davvero molto ben realizzata!!!

[Bokonon]

Si può usare anche mobileuncle per il ripristino degli imei, ci sono un sacco di guide che spiegano dettagliatamente come procedere. L'ho imparato a mie spese perchè anche io ho dovuto usarle per sistemare il mio t100 dopo aver perso gli imei e ip del modulo wifi......

Non uso MobileUncle da mesi: a suo tempo aveva solo una funzione per inserire gli IMEI ma solo se prima uno li aveva salvati con MobileUncle.
Se hanno inserito una funzione per creare i file necessari a ripristinare a nuovo gli IMEI nella NVRAM, allora potresti aiutare Pazzokli!

[reddog]

Non uso MobileUncle da mesi: a suo tempo aveva solo una funzione per inserire gli IMEI ma solo se prima uno li aveva salvati con MobileUncle.
Se hanno inserito una funzione per creare i file necessari a ripristinare a nuovo gli IMEI nella NVRAM, allora potresti aiutare Pazzokli!

Presto fatto, questa è la guida passo passo per il recupero degli imei senza backup postata su androidworld da un utente "scafato":

"Perdita Codici IMEI
Puo' capitare a volte che installando una nuova ROM vengano cancellati i codici IMEI (questo succede quando per installare una nuova rom è necessaria la formattazione del cellulare).
In rete ci sono numerose guide su quali programmi utilizzare, ma è possibile intervenire anche senza programmi specifici.
Ricordate che gli IMEI sono contrassegnati dentro il vano batteria.


Un metodo molto veloce per ripristinare gli Imei è quello di fare un Backup imei con MobileUncle e successivamente alla installazione della nuova rom fare un restore Imei.


Se non si è fatto il backup si può lo stesso ripristinare gli imei dal menu engeenering:
Entrare in menù engeenering con MobileUncle
Entrare in scheda "Connectivity"
Cliccare su CDS Information
Cliccare su Radio Information
Cliccare su Phone 1
Troverete scritto AT+, cancellate il + e poi lo riscrivete, vi apparirà una serie di codici, scegliete il primo: AT+EGMR=1,7,""
Ora in mezzo agli apici dopo 1,7, scrivete il codice Imei, esempio: AT+EGMR=1,7,"335577889911223" (15 numeri)
Cliccate su "send a command" (se avete il telefono rootato dovrebbe scrivervi "sent"
Riavviate e controllate col codice *#06# se il codice imei numero 1 è presente.
Se è presente passate a fare il 2. Fate la stessa procedura ma ovviamente invece di cliccare su Phone 1 cliccherete su Phone 2, e invece di cliccare su AT+EGMR=1,7,"" cliccherete su AT+EGMR=1,10,""

Naturalmente per poter usare questa funzione serve il root. Inoltre se in futuro si volesse installare sul telefono una nuova rom e di conseguenza si dovesse fare il wipe completo del telefono si perdono gli imei che dovranno essere ripristinati, sempre da mobileuncle, con un precedente backup.

Se avessi necessità di ulteriori chiarimenti sono qua

[Bokonon]

Se non si è fatto il backup si può lo stesso ripristinare gli imei dal menu engeenering:

E allora è rimasto tutto come prima. MobileUncle ripristina solo l'IMEI salvato.
Il menù engineering non è parte di MobileUncle, ma bensì un'app di sistema.
Conosco il metodo e conosco anche l'alternativa, ovvero usare il factory menù al boot, che sarebbe anche meglio visto che scrive addirittura sulla partizione NVRAM (invece di creare solo la directory NVRAM della system).
Ho consigliato le Droid Tools perchè sono molto più semplici. Chi non ha un processore MTK deve necessariamente usare un altro metodo...ma visto che Pazzokli ha almeno questo vantaggio rispetto al prossimo, tanto vale non complicargli la vita!

P.S. Inoltre non sia mai che Pazzokli abbia imparato la lezione e che voglia avere un bel backup d'ora in poi
P.S.2 Anzi, quanti di voi non hanno fatto un backup con le Droid Tools? Giuro che tiro fuori il gatto a nove code se scopro che non avete mai usato le droid tools...

[Bokonon]

we ragazzi, su needrom è uscito da poche ore un tentativo di fix per la bussola....... ma direi molto interessante, che ne dite?

Farebbe prima a spiegare cosa ha fatto. Solo allora uno può giudicare ed eventualmente inserire il fix anche nella ROM che utilizza.
Fondamentalmente la cosa è molto semplice: esiste un chip hardware che si occupa del sensore magnetico e di altri sensori.
Le impostazioni software dei sensori stanno nella ramdisk, quindi nel kernel. Se il codice è buggato, allora non c'è nulla da fare senza il codice sorgente della MTK.
Se invece è solo un problema di impostazioni allora uno potrebbe smontare il kernel, estrarre la ramdisk e cambiare qualche file di impostazione che si trova nella sys/devices/platform. Oppure potrebbe usare uno script init.d per ridefinirli.

NOTA: VI INVITO A DARE UN'OCCHIATA A QUELLE DIRECTORY E A QUEI FILE. MAGARI APRITE PURE IN SOLA LETTURA I FILE DI CONFIGURAZIONE COSI' VI FATE UN'IDEA DI COME FUNZIONA ANDROID. METTETE IN PRATICA QUANTO LEGGETE, AIUTA A COMPRENDERE MEGLIO.

L'alternativa è che il kernel utlizzi dei file di configurazione nella system/etc ma la escludo perchè la MTK non ama proprio lasciare che i parametri hardware possano essere variati...a parte poche eccezioni che non possono essere definite e vincolate a livello kernel perchè sarebbe assurdo farlo.
Per il resto...o non ci sono file di configurazione specifici oppure vengono bellamente ignorati dal sistema (bypassati).
Un ultimo modo che viene utlizzato per definire le configurazioni hardware sono le librerie: la maggior parte stanno system/lib/hw ma alcune vengono messe sotto system/vendor/lib. Tutti quei .so sono librerie in C++ spesso scritte e firmate da chi produce l'hardware. Potenzialmente, un programmatore può prendere una librerie, decompilarla, modificarla e ricompilarla...però non funzionerebbe in quanto deve essere signed, ovvero firmata compatibilmente con i certificati presenti da qualche parte nel sistema (forse nel kernel ma non ne sono sicuro).
Ad esempio, per avere il LED per le notifiche, avrete rimpiazzato la libreria light.default.so (oppure avete installato una ROM in cui la libreria stock era già stata sostituita). Tempo fa scrissi che probabilmente quella versione della libreria era stata presa da un cell compatibile che aveva il LED abilitato. La ragione per cui lo penso è la signature. Infatti se uno prende una libreria già firmata, allora potrebbe rimpiazzarla sic et simpliciter.

E adesso vi dico cosa penso io ma che non è necessariamente vero.
La mia sensazione è che la sensor.defualt.so contenga molte cose interessanti riguardo i sensori: in un'altra libreria invece ci potrebbero essere i parametri per l'illuminazione dei tasti. Il problema è che nessuno finora ha trovato librerie valide da sostituire...infatti il problema della bussola e dell'illuminazione dei tasti è comune a diversi cell con hardware MTK. Mi piacerebbe verificare la mia sensazione: posso prendere le librerie e decompilarle ma dovrei saperne di programmazione per capire

Per concludere, dopo questa panoramica, è chiaro che se esiste una soluzione al problema della bussola, allora il fix rientra in una delle categorie di cui sopra. Quindi basta domandare cosa avrebbe fatto per risolvere il problema. Se non sa rispondere, allora non sa cosa ha fatto e questo già direbbe molto.
Se invece risponde:
A) ho preso una libreria dal quel cell e l'ho sostituita: allora basta fare la stessa cosa nella propria ROM e testare quella libreria
B) ho inserito uno script init.d: allora uno prende lo script e ci si da un'occhiata
C) ho cambiato quel file di configurazione nella system: anche in questo caso uno ci da un'occhiata e casomai pratica le stesse modifiche nella sua ROM.
D) ho decompilato il kernel, estratto la RAMDISK ed editato dei file di configurazione: è molto poco probabile ma non impossibile. In questo caso uno dovrebbe testare la boot.img

[page64]

Spulciando il build.prop dovrebbe essere una Custom basata su di una versione Alyiun OS molto recente : ro.build.display.id=thl_T100S.159D.A2.JB9.FHD.EN.1 6P256.IMX135.MT6592GW.2014/06/06

e in framework i file jar.jex , però il sys/devices/platform non lo trovo esplorando lo .zip della ROM , viene creato con l'installazione ?

[Bokonon]

però il sys/devices/platform non lo trovo esplorando lo .zip della ROM , viene creato con l'installazione ?

La directory /sys è uno dei tanti mountpoints virtuali che vanno a creare la struttura dell'albero della root che è visibile con un explorer a piacere solo se il telefono è rootato. In particolare però la /sys è un riflesso di file e oggetti presenti nel kernel e quindi nel boot.img. Il kernel non è montabile per definizione e quindi sono files che possono essere solo visti (con un editor). Anche se vedi che le directory sono r/w, non significa che possiamo realmente modificare alcunchè (se così fosse android e anche linux sarebbero dei colabrodi). La /sys la puoi esplorare solo dal cell...ed è piutttosto interessante perchè contiene appunto molti file di configurazione. Come ho scritto, per modificarli uno dovrebbe decompilare il kernel, estrarre la ramdisk, fare dei cambiamenti e poi ricompilare il tutto e flashare il nuovo boot.img.

Comunque, qui c'è un'utile spiegazione generale dell'albero della root --> http://www.all-things-android.com/co...file-hierarchy

[Bokonon]

Doh! Visto che vi piace e interessa, vi consiglio di dare un'occhiata ai file .rc.
Sono tutti presenti nella root e stanno dopo la sfilza di cartelle (se non li vedete, andate nel setting del vostro explorer e ditegli di visualizzare tutto).
I file .rc sono i file di configurazione che partono al boot. Init.rc è quello che fa partire tutti gli altri ed è anche il famoso file che viene modificato nella ramdisk per ottenere un kernel con il famoso supporto init.d.
Ovviamente tutti questi files non sono editabili (anche se sembra che lo siano): provate pure, tanto poi ritornano identici al boot successivo oppure semplicemente vi viene restituito un errore.
Però, a differenza dei file della /sys, gli .rc files possono essere copiati nella vostra SDcard...e da la ve li mettete nel PC per leggerli comodamente con un buon editor (tipo Notepad++). Anche se ne capirete quanto me (ovvero, zero!) è sempre interessante vedere e provare a capire (anche se purtroppo non ho trovato guide sui comandi dell'init.rc per cogliere meglio il significato di alcuni comandi).
Per esempio, scoprirete che, tra le altre cose, questi file sono responsabili della costruzione di tutta la struttura ad albero che vedete e dei permessi assegnati ad ogni directory. Per fare un esempio, io ho il file init.no_ssd.rc, dentro ci stanno pochi comandi:

on init
mkdir /storage/sdcard0 0000 system system
mkdir /storage/sdcard1 0000 system system

export EXTERNAL_STORAGE /storage/sdcard0
export SECONDARY_STORAGE /storage/sdcard1

# for backwards compatibility
symlink /storage/sdcard0 /sdcard
symlink /storage/sdcard0 /mnt/sdcard
symlink /storage/sdcard1 /mnt/sdcard2

Il significato è piuttosto chiaro IMHO...serve a creare i mountpoints per gli storage (ovvero, SDcard e memoria interna).
Ad ogni boot, viene creata la directory virtuale /storage che contiene e definisce appunto la SDcard e la memoria interna.
Sono quasi (quasi!) sicuro che se cambiassi [B][I]export EXTERNAL_STORAGE /storage/sdcard0[/I][/B] in [B][I]export RUSCO /storage/sdcard0[/I][/B] cambierei il nome della SDcard da EXTERNAL_STORAGE a RUSCO. Non che abbia senso farlo ma almeno spiega come vengano dati i nomi e quando vengono dati!
Poi ci sono quelle linee che iniziano con symlink. Se sapete già cos''è un symlink avrete già indovinato cosa fanno. Esatto!
Servono ad inserire il mountpoint del block device reale (in questo caso la SDcard e la memoria interna) anche sotto altre directory. Infatti se andate dentro /storage/sdcard0 troverete la directory originale della SDcard. Ma anche se andate sotto /sdcard oppure /mnt/sdcard la trovate di nuovo! In realtà è solo un'illusione perchè ci riporta alla directory virtuale ma originale /storage/sdcard0...e tutto questo indipendentemente dal fatto che ci pare di essere sotto la directory /mnt.
Se uno volesse potrebbe aggiungere la riga symlink /storage/sdcard0 /system/app/sdcard e comparirebbe appunto anche sotto la directory /system/app!
Perchè lo fanno? Lo dice il titolo # for backwards compatibility. Evidentemente in passato i mountpoints delle memorie del telefono stavano in quelle directory e le app/librerie vecchie le cercavano laggiù. Quindi per mantenere la compatibilità anche con software datato, creano i symlink delle directory virtuali.

P.S. A ripensarci ho cannato l'interpretazione....
Infatti c'è scritto che viene creata la directory e definiti i suoi permessi con mkdir /storage/sdcard0 0000 system system e poi a questa directory virtuale viene associato il device EXTERNAL_STORAGE con il comando export EXTERNAL_STORAGE /storage/sdcard0. Quindi non è vero posso cambiare il nome del device...è già definito di default da qualche altra parte: qui viene solo associato.

[Bokonon]

A proposito, vi ho detto che presto Google introdurrà in Android il blocco della /system?
In pratica non sarà più montabile, proprio come il kernel, e quindi non sarà più possibile spostare app, librerie, editare config, etc. etc. usando comodamente un explorer. A differenza del kernel però, la system sarà montabile e quindi scrivibile da recovery: dev'essere così altrimenti non ci sarebbe modo di aggiornare il sistema operativo. Quindi sarà ancora possibile editare/spostare/cancellare i files della system flashando da recovery oppure (penso) usando un explorer dentro la recovery stessa.

La notizia è abbastanza recente ed è stata data da Chainfire (quello di Supersu). Chainfire controlla costantemente lo sviluppo di Android e ha notato che il codice incriminato per il blocco della system è stato spostato da un ramo generico di sviluppo al ramo principale di Android.
C'è anche la firma di chi ha creato il codice ed è un agente della NSA. Esatto la National Security Agency dei telefilm (che è anche quella che ha creato Selinux presente in kitkat). Oggettivamente, questo passo renderà molto più sicuro Android...mentre renderà un po' più noioso personalizzare il cell.
Di sicuro tuti vorremo una buona recovery che abbia magari anche un explorer come Aroma Explorer nella CWM.

P.S. Vi metto il link all'articolo --> http://www.androidpolice.com/2014/05...to-root-users/