[ROM] JellySnap | Android 4.2.2 - CM10.1 | [... is coming ...]

Grazie a franyo per il suo prezioso aiuto!
Appena riesco posterò due framework che avranno valori di luminosità di default diversi. L'unica cosa da fare è, provarli e vedere quale dei due va bene. (flash via recovery).
[HR][/HR]AGGIORNATO POST DOWNLOAD E ISTRUZIONI PER IL FLASH. Ciò significa...NUOVA VERSIONE!
ATTENZIONE: le istruzioni ora prevedono una carica del dispositivo al 100% prima del flash...è importante!

in questa nuova versione le novità sono molte...ma prima di tutto fix di alcuni bug e imprecisioni.
Inoltre la rom è più leggera e con un nuovo metodo di gestione RAM.
Nuovi driver grafici (non quelli ex pacchetto aggiuntivo) e il tutto è decisamente più "burroso".
La novità più grande però...è la batteria!!! In 3g (grosso problema) i risultati sono OTTIMI!!!
La giornata media (ore 8:00 - ora 23:00) vola via con un bel 20% di batteria alla fine! Utilizzo medio --> NON ESASPERATO.

NOn è tutto...
questa è l' ultima versione beta...la prossima sarà ufficiale!!! Ma prima dovrà subire ancora qualche cambiamento....

CAMBIAMENTI FINALI:
- update a versione 25/09 cyano 10.1 --> dicono sia portentosa
- update kernel .63 --> c'è da risolvere qualche bug di compatibilità ma sono in via di risoluzione

- tweaks build prop
- project butter enchanger --> da testare...non è detto che sia una cosa positiva
- test vsync attivo --> il vsync è la vera "marcia in più" di JB, ma sul nostro arc s rende instabile la rom...vediamo se riusciamo a fare qualcosa...


buenas!

 

Ho dimenticato di mettere i moduli wifi...hehe aggiungo in download

Inviato dal mio Xperia Arc S con Tapatalk 2

 

Per i video provo ad informarmi ma dovrei modificare il kernel...altrimenti modificando solo il formato di registrazione verrebbero sformati..Non so, vediamo

Inviato dal mio Xperia Arc S con Tapatalk 2

 

Eh..Non saprei, ora sono fuori casa..di sicuro il problema è del kernel potresti provare a mettere il precedente...
https://mega.co.nz/#fmtZIXCbTZ


Inviato dal mio Xperia Arc S con Tapatalk 2

 

ikee
ho provato ad abilitare la registrazione a 720p da media profiles ma va in boot loop ritenterò per altre strade...

ok, nada de nada...il kernel è studiato appositamente per avere maggiore memoria libera (cosa imprescindibile con JB). Questa memoria libera è stata rubata proprio dalla parte dedicata alla registrazione a 720p...bisognerebbe ricompilare il kernel...

https://github.com/garwedgess/semc-kernel-msm7x30/commit/68aa3314cdf5c5ab238ceceecf75f2b7304fbf18

Si può sempre usare il kernel LUPUS: http://forum.xda-developers.com/showthread.php?t=1885559

ma al 99% le performance generali di batteria e fluidità ne risentiranno..

tentar non nuoce..

 

Yep!!! Dovrebbe funzionare senza problemi

 

Peccato poteva essere un'alternativa, ma in effetti le mie speranze non erano molte.
Perchè il lupus è in verità basato sul kernel 2.6....--> quello di GB!!!!!!eheheh
Il dark sul 3.4..

Nella versione che sto testando (aggiornamento sia nightly cyano che kernel dark) ho qualche problemino di troppo con la fotocamera...
Regola confermata: non tutti gli upgrade escono col buco...

 

Allora, qui ci sarebbe da fare un discorso interessante ma lunghetto...cerco di essere semplice e breve.
Per prima cosa bisognerebbe conoscere a grandi linee come funziona Linux, ma per ovvi motivi non mi dilungo a scrivere tutto ciò.

Diciamo solo che puoi immaginare Android come un insieme enorme di processi che vengono scritti in memoria. Il criterio con cui vengono scritti è deciso dal kernel.
Quest'ultimo decide anche quanto sono importanti, cioè ne assegna la priorità inserendoli in sottogruppi con caratteristiche ben definite.

Ogni processo occupa memoria, o meglio, ha la capacità di "espandersi" occupando bit (pagine) fino ad un certo limite, anch'esso preimpostato dal kerenel.
Questa memoria occupata fa sempre parte della RAM, ed almeno nella fase iniziale del processo (quando viene scritto o richiamato) occupa molta memoria.
Dopo una fase iniziale le pagine di un processo vengono classificate e, in alcuni casi, smembrate andando ad occupare porzioni di memoria ROM.

Sorge a questo punto il problema dell'esaurimento fisico della RAM. Anche di questo si occupa il kernel per mezzo del lower memory killer.

Ora veniamo al KMS. E' un cosiddetto "demone" in Android che si occupa della fusione delle pagine del kernel.
In sostanza per mezzo di alcune "call" scandaglia la memoria di sistema (la voce che all'interno della RAM va sotto il nome di "S.O Android") alla ricerca di quelle pagine (piccole porzioni di memoria) che sono immobili, cioè che non vengono aggiornate, cioè non crescono e non diminuiscono da molto tempo. (stiamo parlando di secondi).
Le pagine vengono sottoposte ad un check sum, cioè ne viene controllata la dimensione e confrontata con l'ultima dimensione registrata, per capire se sono state aggiornate o meno.
Le pagine vengono quindi classificate come potenziali unificabili o non unificabili e in un secondo tempo vengono "fuse".
In termini pratici la loro memoria viene unificata. Un esempio perfetto è quello che succede in windows quando due cartelle con lo stesso nome si trovano allo stesso indirizzo: il sistema chiede se vuoi unire le due cartelle e nel caso di file omonimi ne viene mantenuto uno soltanto.

Il risultato di tutto ciò è da una parte una discreta riduzione della RAM occupata, dall'altro una discreta diminuzione della batteria, in quando il demone KMS gira in background utilizzando almeno un ciclo di cpu per ogni check sum delle pagine.

Il funzionamento è, negli obiettivi, molto simile alla zRAM, anche se il principio è completamente diverso.

Purtroppo non sono abbastanza competente per giudicare il funzionamento accoppiato KMS e zRAM. L'unico mio criterio di discrezione è il test, ma con una RAM di 360MB è totalmente impossibile valutare l'impatto dei due demoni combinati.
(è probabile che il KMS riduca l'impatto di una decina di MB e lo stesso faccia zRAM) ma ditemi voi come è possibile rendersi conto delle differenze solo valutando la fluidità generale.

In linea teorica immagino sia sconsigliato l'utilizzo combinato dei due sistemi...ma boh..magari uno dei due ha la capacità di escludere dal processo le pagine già "trattate" dall'altro demone...non so..

Bon..chi ha voglia e tempo può sempre testare e provare..


edit:
ho trovato questo http://www.consulenti-ict.it/Area-T...-linux-struttura-della-memoria-condivisa.html che spiega decisamente meglio di come ho fatto io