Un chiarimento sulle meccaniche post-deodexing e le stock rom

[Caviglia]

C'è una questione riguardo al concetto dex/odex/deodexed che non mi è chiara ancora....
Ho letto What's Deodex and Odex? su xda che è stato illuminante, però mi sfugge ancora un piccolo particolare:

Tramite l'eventuale Deodexer v2.3 (come consigliato da guida) si de-ottimizza il file che rappresenta l'apk, ricomponendolo e portandolo in uno stato modificabile in maniera sicura, evitando eventuali conflitti con le sue parti "volanti" tipiche della meccanica file odex/java VM (Dalvik cache)....ebbene, a questo punto io stupro il file e ne faccio quello che mi pare....e dopo?
Specifichiamo che in realtà di solito si deodexano tutte le app, non stiamo parlando di un lavoro mirato ad una sola....però il mio dubbio è su questo passaggio: monto la rom deodexed, i suoi file de-odex come si rapportano alla Virtual Machine? Posto che al "primo giro" di caricamento ovviamente ci sarà più lentezza....ma poi, la cache Dalvik si popolerà come previsto con una rom odex? Ovvero, i miei file non ottimizzati, verranno ottimizzati automaticamente da questo sistema una volta che verranno cercati/interrogati/caricati una prima volta? Diventeranno quindi nuovamente odex?

Spero di essermi espresso correttamente o quanto meno di aver fatto comprendere il mio dubbio.

In seconda battuta, ma strettamente correlata a queste elucubrazioni...volevo chiedere perei sull'utilizzo della JS8 stock deodexed (a chiunque l'abbia utilizzata)...perchè mi sto un po' documentando in questi giorni e mentre vedo fiorire le prime rom ginger, sono ancora un po' sotto sotto titubante a fare "il salto"....e quindi sto battendo più approfonditamente il "vecchio e solido" mondo delle ultime release froyo.....
Personalmente mi piacerebbe presto o tardi arrivare a potermi configurare la mia personale rom partendo dalla stock che eleggerò a "indiscutibilmente migliore"...
Attualmente sto usando una JS5 con l'ultimo Kernel Speedmod per Froyo e non ho molto di cui lamentarmi, a parte a volte il gps un pochino lento nell'aggancio (ma nella peggiore delle ipotesi stiamo parlando di una manciata di minuti)...però ho voglia di sperimentare.

Come ROM cucinata già pronta ho puntato gli occhi sulla Serendipity e sulla Essential Rom v3 basata su JS7...ci sarebbe anche una ROm di JUWE's ma so che adesso è preso dalla versione per ginger e quindi la tengo come ultima scelta.
Altrimenti restando sulle stock ero indeciso tra JS7 e JS8 per partire in seguito da lì a fare i miei primi esperimenti personali.

[Val3r10]

Complimenti per l'approfondimento. Spero anch'io ti risponda presto qualche esperto cuoco che conosce i trucchi e gli effetti del deodexing.

Personalmente posso farlo solo per la "scena finale" risultante.
Magari è un tassello in più.

Ma semplicemente perché il mio personalissimo script di svuotamento della Dalvik-cache, che deriva da una osservazione empirica nella shell del telefono, è:

rm /data/dalvik*/*.dex

(naturalmente eseguito da ADB SHELL con diritti di root)

Questo già dovrebbe parzialmente rispondere, ma...

Allora. L'attività di deodexing non fa altro che eliminare tutti i file .odex associati ai file .apk "stock", reinserendo i moduli corrispondenti all'interno degli stessi apk.
Quei file .odex spariscono dalla ROM così ottimizzata (deodexing=ottimizzazione ?!? qualche dubbio l'ho espresso tempo fa, ma senza solleticare nessuno), e non tornano più.

Ad ogni boot, il sistema effettua una verifica della dalvik-cache, che contiene come hai visto il runtime java dei pacchetti (formato .dex), e confronta tale contenuto con tutto l'albero dei pacchetti presenti nel sistema, /system/app e /data/app in particolare.
Per ogni applicazione deve essere presente il corrispondente file runtime: se c'è l'odex, vale quello; se non c'è, come appunto nelle versioni deodexed, al primo boot utile viene ricreato/aggiornato il corrispondente .dex nella dalvik cache (non sono certo, ma potrebbe essere scompattato direttamente quello contenuto nel file apk corrispondente)

E' per questo che il primo avvio di una ROM cucinata impiega parecchio tempo, come pure dopo il wipe della dalvik.

Aggiungo che la creazione massiccia dei file .dex avviene solo al boot, mentre quella delle singole applicazioni scaricate ad esempio dal market avviene contestualmente alla loro installazione.
Se non c'è il .dex, l'applicazione corrispondente parte ma va in force-close immediatamente...

Ho risposto in parte al tuo dubbio ?
Aspettiamo i cuochi, cmq!

[Caviglia]

Grazie Valerio per l'attenzione.
Sì, in parte mi hai risposto o quantomeno fornito nuovi spunti di riflessione...dunque una volta che abbiamo presentato una rom de-odexed al nostro runtime, lui si limita a ricrearsi le proprie immagini .dex a partire dagli .apk che abbiamo "maneggiato" noi. Se così è, dunque il processo di frammentazione degli .apk per produrre solo parziali .dex (appunto il concetto di ottimizzazione .odex) non è di competenza della virtual machine......e se non è di sua competenza....a chi spetta? E che genere di "flag" fa intervenire quest'entità?

A meno tutta questa faccenda non dia per scontato che sarà qualcosa di "esterno" ad ottimizzare i .dex per poi presentarli alla VM....e in questo caso, chi? Forse la pista da seguire potrebbe partire dal programma che si occupa di "de-odexare"? Avrà una libreria di funzioni che si occuperà di rimettere insieme i tasselli ottimizzati per tornare all'immagine originale tutta intera del .dex a cui corrisponde il .apk che intenderemmo smanettare.....dunque esiste/esistono degli algoritmi con cui questa frammentazione di ottimizzazione viene applicata agli .apk....si potrà evincere dallo studio inverso del modo di procedere del programma per de-odexare? O magari qualcuno si è già "sbattuto" a compiere queste indagini e ne sa qualcosa?


PS: riguardo ai pareri sulle stock/rom, Valerio ho notato che hai avuto una JS8 de-odexed...posso chiederti come ti sei trovato?

[Max92]

Grazie Valerio per l'attenzione.
Sì, in parte mi hai risposto o quantomeno fornito nuovi spunti di riflessione...dunque una volta che abbiamo presentato una rom de-odexed al nostro runtime, lui si limita a ricrearsi le proprie immagini .dex a partire dagli .apk che abbiamo "maneggiato" noi. Se così è, dunque il processo di frammentazione degli .apk per produrre solo parziali .dex (appunto il concetto di ottimizzazione .odex) non è di competenza della virtual machine......e se non è di sua competenza....a chi spetta? E che genere di "flag" fa intervenire quest'entità?

A meno tutta questa faccenda non dia per scontato che sarà qualcosa di "esterno" ad ottimizzare i .dex per poi presentarli alla VM....e in questo caso, chi? Forse la pista da seguire potrebbe partire dal programma che si occupa di "de-odexare"? Avrà una libreria di funzioni che si occuperà di rimettere insieme i tasselli ottimizzati per tornare all'immagine originale tutta intera del .dex a cui corrisponde il .apk che intenderemmo smanettare.....dunque esiste/esistono degli algoritmi con cui questa frammentazione di ottimizzazione viene applicata agli .apk....si potrà evincere dallo studio inverso del modo di procedere del programma per de-odexare? O magari qualcuno si è già "sbattuto" a compiere queste indagini e ne sa qualcosa?


PS: riguardo ai pareri sulle stock/rom, Valerio ho notato che hai avuto una JS8 de-odexed...posso chiederti come ti sei trovato?

Tra le ROM cucinate su base Froyo a mio parere rimane ancora oggi la Serendipity come migliore in stabilità e velocità, su kernel speedmod k13e. Per le versioni base non saprei consigliarti perchè ho sempre usato cucinate.

[Val3r10]

Visto che ti sei addentrato dove non posso più esserti utile , rispondo solo a questo:

PS: riguardo ai pareri sulle stock/rom, Valerio ho notato che hai avuto una JS8 de-odexed...posso chiederti come ti sei trovato?

Sono tutt'ora come ho scritto in firma.
In particolare utilizzo per me un ibrido della ROM Kitchen 9.9.5 (ultima JS8 in assetto europeo) integrata con diversi file ottimizzati, raccolti e aggiustati nel tempo, che uso come "patch" prima del flash cwm. A cominciare dall'update-script riscritto da me
Anzi, al momento sono alle prese con la canonicizzazione dei permessi su _tutti_ i file, che ho notato quasi sempre vengono completamente trascurati. Dai cuochi o dalla cucina che sia, che invece si limitano ai pochi modded...

Personalmente mi trovo molto bene, senza lagfix o fronzoli, perché preferisco sapere cosa c'è dentro una ROM. E soprattutto perché, zip compare alla mano, ho realizzato che le differenze sono quasi sempre solo estetiche.
Anche se in taluni casi contano molto e si ripercuotono sulle performance...

Quindi quanto a ROM cucinate la penso un po' controcorrente. E probabilmente non faccio testo.
Sottolineo che è il mio parere, deformato professionalmente dal voler capire cosa accade dentro/dietro le quinte. Il che ovviamente complica parecchio la vita - e si confonde - col bombardamento e la curiosità di provare le varie creazioni sempre nuove.
Non sempre così rivoluzionarie o stabili come da aspettative (CM 702 docet)

[Caviglia]

Bè, direi che siamo sulla stessa lunghezza d'onda
Il mio riflettere di questi tempi sulla questione ROM/Stock è dato proprio dallo stesso tipo di fissazione caratteriale/professionale della ricerca del "perchè e percome" delle cose....
Mi son perso un pezzo quando parli di canonicizzazione dei permessi su tutti i file....probabilmente è un argomento basilare che ignoro....
Personalmente il mio istinto mi spinge a pensare/illudermi di prendere un firmware Stock e cominciare a studiarlo fin nelle viscere e piegarlo ai miei desideri interiorizzando in itinere tutta la filosofia (e la logica) che sta dietro a questo mondo.....
Da qui probabilmente è nato il mio interessamento per le ROM cooked...un po' come dire: "Bè, come son fatte queste ROM che dovrebbero rappresentare il risultato finale a cui anch'io intendo giungere?".....e da lì mi son scontrato con questo primo punto focale sul discorso .odex/de-odex......al di là del voler arrivare a comprendere/maneggiare il processo che si occupa di ottimizzare/de-ottimizzare i .dex, vorrei quantomeno comprendere PERCHE' un deodex dovrebbe esser "meglio" del corrispettivo odex.....

L'idea che mi son fatto è che in realtà il de-odexing è una necessità operativa per chi intende modificare i file .apk...poichè se si lasciano le porzioni di corrispettivi .dex libere di vagare s'incorre necessariamente in conflitti....inoltre non è certo possibile pensare di modificare qualcosa che non è integro, e dunque è giusto prima ricomporlo e poi modificarlo a piacimento....è a questo punto che non comprendo lo step successivo.
Se ho ben capito, una volta che il cuoco di turno ha modificato il file .apk a suo piacimento, lascerà che si crei il corrispettivo .dex ad uso e consumo della VM....ma perchè si salta il passaggio dell'ottimizzazione?? Perchè non dovrebbe ri-applicarsi anche al .dex del .apk modificato? Non dovrebbe garantire maggior fluidità etc. etc.?

Non comprendo se questo passaggio si salta perchè non si è in grado di replicarlo su un file che di fatto è ormai modificato, se lo si salta perchè non è necessario al raggiungimento delle migliori performance, se lo si salta perchè proprio non è più implementabile una volta che presentiamo un .dex di un.apk modificato.....

Forse ho chiarito meglio il mio particolare dubbio.

[Val3r10]

Guarda, sul deodexing ripeto che non sono molto titolato a risponderti.
Però da quanto ho visto, un po' grossolanamente, puoi rappresentarti la trasformazione semplicemente così:
il file .odex collegato ad un .apk sparisce e ci finisce direttamente dentro, sotto forma di .dex. Quello stesso dex viene estratto dall'apk al primo boot utile e spostato dalla partizione SYSTEM alla DALVIK, liberando quindi un pò di spazio dalla prima (perché i singoli apk sono sì più grandi di quelli originali, ma di sicuro meno dell' apk+odex complessivo)

Riguardo alle ottimizzazioni, il dubbio di fondo è quello della milza che ho indicato. Certo è che su una rom non deodexed guai a modificare i temi (framework-res & co) perché il sistema non parte più.
Forse proprio per i disallineamenti che citi...




Il discorso dei permessi è semplice, anche se OT:
quando installi un firmware attraverso Odin, non fai altro che flashare un file-system su una partizione, tipo il dd (diskdump) di linux. Tale FS (mi riferisco in particolare alla partizione SYSTEM) ha già le sue strutture linux complete di uid, gid e permessi rwx. Complete e corrette.
Non altrettanto accade quando scompatti un file ZIP (ROM cucinata o stock-like che sia), perché i permessi sui file non vengono mantenuti, ammesso e non concesso che il cuoco originale li avesse impostati _tutti_ correttamente.
Tutto ciò si traduce nel fatto che tutti i file (centinaia e centinaia) avranno i permessi e l'ownership di default del sistema linux, salvo i pochissimi che normalmente si impostano nell'update-script.
E ciò accade anche per quelle ROM cucinate che si flashano via Odin, perché altro non sono che un backup della versione artigianale dumpata dal telefono del cuoco (vedi cap.9 delle guide). Che all'origine si è costruito via CWM di sicuro.

Poi alla fine ci si chiede perché certe applicazioni, anche di sistema, vanno in FC in modo incomprensibile: vattelapesca, tra tutti quei file, poi qual'è la libreria giusta coi permessi o l'owner linux sbagliati

[Caviglia]

Ah ok, allora il problema dei permessi, anche se non conosco ancora linux così a fondo, era esattamente quello che immaginavo e di fatto, la motivazione per cui istintivamente diffidavo/diffido dalle ROM e preferirei metterci mano personalmente. Decisamente il discorso non fa una piega e fila liscio come l'olio....il punto è che si dovrebbe partire da un firmware Stock di cui si ha certezza delle giuste impostazione su tutta la directory e poi cominciare a fare una lavoro da certosino nel prendere ogni parte che c'interessa e modificarla nella direzione che vogliamo pur mantenendo, prima di passare oltre, tutti i suoi permessi e caratteristiche fondamentali che aveva in precedenza.

Ancora una volta purtroppo mi ritrovo a sbattere contro sto muro della questione dex/odex.....a rigor di logica, se assumo che il sistema così com'è stato concepito sia funzionale, ovvero che effettivamente aiuti il lavoro della VM sulla cache Dalvik il fatto che i .dex estratti dagli .apk vengano anche frammentati...allora mi viene da pensare che una motivazione potrebbe risiedere nel fatto che alcuni frammenti di .dex estratti da varie .apk siano in realtà uguali, o meglio, servano per svolgere le stesse procedure....in questo modo suppongo si avrebbe un risparmio di tempi di calcolo, elaborazione o accesso letture di queste informazioni....

Non so se mi sto spiegando comprensibilmente....l'idea è: ogni .apk è una persona che deve interpretare uno spettacolo su un palcoscenico (cache Dalvik). Ovviamente ogni attore avrà delle caratteristiche specifiche: costume, trucco, dialoghi, entrate/uscite di scena, etc.
Se la VM può considerarsi un po' il regista dello spettacolo da mandare in scena, come potrebbe organizzare il gruppo di attori? semplice, sono tutti nei camerini (partizione system), ma posso pensare di tenere le cose che gli servono (.dex) dietro le quinte in modo che sia più funzionale per loro utilizzarle al momento giusto...e magari non ha senso pensare di tenere decine di scatoloni per contenere la singola "spada" che dovrà impugnare quell'attore piuttosto che quell'altro in quella scena o in quell'altra. Tanto vale mettere in comune la spada e raccoglierle in un cartone generico (.odex).

In pratica estrapolo parte della caratteristica di un'applicazione e la condivido con le altre perchè so che la posseggono anche loro per quanto istanziata......non so se mi sto perdendo troppo in un Object-Oriented-Thinking....ma credo che potrebbe filare come concetto per giustificare l'esistenza di questo sistema di ottimizzazione....

[Max92]

Ah ok, allora il problema dei permessi, anche se non conosco ancora linux così a fondo, era esattamente quello che immaginavo e di fatto, la motivazione per cui istintivamente diffidavo/diffido dalle ROM e preferirei metterci mano personalmente. Decisamente il discorso non fa una piega e fila liscio come l'olio....il punto è che si dovrebbe partire da un firmware Stock di cui si ha certezza delle giuste impostazione su tutta la directory e poi cominciare a fare una lavoro da certosino nel prendere ogni parte che c'interessa e modificarla nella direzione che vogliamo pur mantenendo, prima di passare oltre, tutti i suoi permessi e caratteristiche fondamentali che aveva in precedenza.

Ancora una volta purtroppo mi ritrovo a sbattere contro sto muro della questione dex/odex.....a rigor di logica, se assumo che il sistema così com'è stato concepito sia funzionale, ovvero che effettivamente aiuti il lavoro della VM sulla cache Dalvik il fatto che i .dex estratti dagli .apk vengano anche frammentati...allora mi viene da pensare che una motivazione potrebbe risiedere nel fatto che alcuni frammenti di .dex estratti da varie .apk siano in realtà uguali, o meglio, servano per svolgere le stesse procedure....in questo modo suppongo si avrebbe un risparmio di tempi di calcolo, elaborazione o accesso letture di queste informazioni....

Non so se mi sto spiegando comprensibilmente....l'idea è: ogni .apk è una persona che deve interpretare uno spettacolo su un palcoscenico (cache Dalvik). Ovviamente ogni attore avrà delle caratteristiche specifiche: costume, trucco, dialoghi, entrate/uscite di scena, etc.
Se la VM può considerarsi un po' il regista dello spettacolo da mandare in scena, come potrebbe organizzare il gruppo di attori? semplice, sono tutti nei camerini (partizione system), ma posso pensare di tenere le cose che gli servono (.dex) dietro le quinte in modo che sia più funzionale per loro utilizzarle al momento giusto...e magari non ha senso pensare di tenere decine di scatoloni per contenere la singola "spada" che dovrà impugnare quell'attore piuttosto che quell'altro in quella scena o in quell'altra. Tanto vale mettere in comune la spada e raccoglierle in un cartone generico (.odex).

In pratica estrapolo parte della caratteristica di un'applicazione e la condivido con le altre perchè so che la posseggono anche loro per quanto istanziata......non so se mi sto perdendo troppo in un Object-Oriented-Thinking....ma credo che potrebbe filare come concetto per giustificare l'esistenza di questo sistema di ottimizzazione....

Il discorso pare filare ma se non ho capito male: ogni file ha il suo corrispettivo elaborato che viene ricreato nel file di origine allora non è possibile che la spada di un attore venga utilizzata per tutti ma sarebbe singola per ogni attore, quindi resta da capire se il regista ragione come dici te o no...