Rettifico, il kernel è il 3.4.53!
Inviato dal mio GT-I9001 con Tapatalk 2
Rettifico, il kernel è il 3.4.53!
Inviato dal mio GT-I9001 con Tapatalk 2
Ora anche a me aggancia dopo un reboot, ogni tanto però mi fa lo scherzo di ritardare l'aggancio.. Google Maps non mi funge anche dopo aver fatto il cancella dati
Galaxy S3 Neo
Consolati, non sei solo se ne parlava anche qui:https://www.androidiani.com/forum/sa...e-slim-35.html
Ultima modifica di Ahasvero; 19-07-13 alle 20:32
ROM: [5.1.1_r13][07/09/15]Resurrection Remix 5.5.8 EOL
Kernel: Stock
Governor/Scheduler: SmartassV2/sio
Recovery: TWRP v2.8.1.0
Ho letto quel 3d ed anche altre risposte, per il momento lo lascio così e vedo che succede, in caso di problemi vedrò cosa fare...
Inviato dal mio GT-I9001 con Tapatalk 2
Quella di david no..
Spoiler:
Christopher o ktulu, ripropongo una domanda che ho fatto in un precedente post senza ricevere alcuna risposta, forse perche' non letta o non esposta chiaramente. Ho letto con attenzione (e traduzione decente) la spiegazione che dai sul funzionamento del kill low memory e le diverse funzionalità delle feature per determinare quali processi kill e la priorità da dare.Quote Originariamente inviato da Christopher83 Visualizza il messaggio
Ciao Leonida,
dipende da cosa fai prima che ti si riavvii.
La feature serve per preservare il più possibile i processi scelti dal kill da parte del lowmemorykiller.
In pratica, quando il sistema ha bisogno di memoria per il processo correntemente in uso, il lowmemorykiller sceglie uno o più processi attualmente in background (tra cui il launcher, se non incluso in lista), in base alla memoria occupata e a quella necessaria da liberare, e li killa.
Con un uso normale del cellulare (poche app usate in contemporanea, telefonate e giochi non pesanti), i processi inclusi nelle due white list (se pochi e non pesanti) non verranno killati probabilmente per tutto il giorno.
Se viene avviato un processo che necessita di una quantità eccessiva di memoria (ad esempio un gioco pesante o app malfatte), anche i processi preservati (soprattutto se occupano molto spazio) saranno necessariamente killati, per evitare lag estremi, chiusure dell'app che si sta eseguendo o addirittura dei freeze.
In pratica con la feature si hanno tre specifiche gerarchie:
1) processi killabili normalmente
2) processi definiti dall'utente da preservare
3) processi di sistema definiti dall'utente da preservare
Quando è necessario liberare memoria, vengono dapprima ricercati e killati i processi non inclusi in alcuna white list (gerarchia 1), se i processi killabili sono finiti ed è necessario liberare ancora spazio, allora si passa ai processi della gerarchia 2 e infine, se proprio non basta ancora, si passa al kill dei processi della gerarchia 3.
Spero sia stato chiaro...
Tuttavia nel post sempre di XDA definisci i parametri minimi di soglia (minfree), al di sotto dei quali un processo viene ucciso, attraverso questa scala, che noto ha una incremento doppio sopra i 9216. Mi spiego:
Adesso le mie domande sono su un k^k di 390mb:Questo file include una virgola serie separata dei numeri di soglia per le dimensioni della memoria minfree (in unità di pagina).
Il valore del parametro impostato per K ^ kernel è "2048,.......4096,........6656,......9216,........ 14336,......19456. "
.................................................. .........................+2048.......+2560......+2 560.......+5120.......+5120
- / sys / module / lowmemorykiller / parametri / adj
- posso cambiare questi valori del parametro impostato? e in che misura e modo ? fino a che limite?
- utilizzando un programma di espansione di memoria ram come sdlink2 o meglio Swapit Expander avrei dei vantaggi in termini di maggior utilizzo di memoria e quindi di collocazione di processi al fine di ridurre il maggior numero di kill? Oppure non avrebbe nessun effetto in quanto non si puo' superare il limite di memoria che lo sviluppatore ha fissato in 390mb?
Perche' chiedo queste delucidazioni?
Come ben saprai ho una marea di widget e apk che per lavoro devo far girare all'avvio del cell quasi simultaneamente. Alla prima installazione del k^k v.1.7 a valori di default, il low kill memory ha comportato che il sistema procedeva di continuo a killare dei processi per liberare come e' giusto che sia della memoria ram. Dal mio test avevo sempre una Ram libera sui 2-3 mb e questo processo continuo bloccava le apk generando freeze continui, la visibilità e' stata immediata.
Adesso se l'espandere della Ram inciderebbe sulla configurazione delle feature in modo da evitare il maggior numero di kill, i vantaggi sarebbero notevoli, non credi?
Scusami se sono stato lungo e forse poco chiaro e perdonami se non sono stato troppo tecnico o mi e' sfuggito qualche elemento di base del funzionamento RAM di Android.
Se quello ce ho chiesto e' fattibile, ti garantisco che inizio i test e se funziona apro un thread, perche' secondo me diventa micidiale il kernel cosi
Ultima modifica di pierm; 21-07-13 alle 18:51
S+ i9001 DarkCM + gapps Team ADC
TWRP_2.6.3.0_ariesve - Governor On demand 245-1401 I/O row - Band/DDKP0
Samsung Tab 2.10+3G slimbean
mi trovi anche qui twitter dcroma
Il thanks! e' gratis e La Wiki di dell serve a tutti, impariamo a leggerla
Anche a me è successo, e siamo alla terza volta a dire il vero ... io però ho la ADC e temo a sto punto sia un problema della 10.1
Tutte le configurazioni ( mail, calendario, suoneria, allarmi ... ) eliminate ed il telefono mi ha richiesto un' altra volta tutta la configurazione.
Ha anche "scongelato" alcune app che avevo bloccato ... provo a chiedere anche nel thread adc ...
================================================Dari78
Samsung A3 (2016)================================================
se dici "grazie" mi fai piacere, ma se premi "thanks" ancora di più
<=================
pierm (22-07-13)
S+ i9001 DarkCM + gapps Team ADC
TWRP_2.6.3.0_ariesve - Governor On demand 245-1401 I/O row - Band/DDKP0
Samsung Tab 2.10+3G slimbean
mi trovi anche qui twitter dcroma
Il thanks! e' gratis e La Wiki di dell serve a tutti, impariamo a leggerla