 |
|
||
|
|
|
|||||||
| ROMs y desarrollo Samsung Nexus S ROMs y desarrollo Samsung Nexus S |
 |
|
|
Herramientas |
|
#1
20/10/11, 08:39:55
|
||||
|
||||
|
¿Estaba errado sobre el consumo de la Wifi?
Os cuento: Hace un tiempo que no dejo de ver el consumo de la batería para ir reduciendo en medida. Lo que mas me sorprendió era el consumo de la batería durante la noche. ¿cómo puede ser que consuma tanta batería si no lo utilizo? Con SetCpu puse el criterio de "cuando la pantalla apagada" min100 max400 conservative. Aparte de bajar el voltage 400/1025 200/925 100/925. Aún así me consumía bastante.
Estuve mirando, y resulta que por la noche hacía muchas sincronizaciones utilizando la red de datos "ya que pensaba que la wifi me consumía mas". Así que busque los programas que sincronizaban, e intenté que no sincronizasen, aparte, uno de los que mas consumía era K-9 (gestor de correos). Pensé que obtendría una mejora utilizando el Gmail que lleva, pero tenía varias cuentas distintas, así que investigando.... he logrado sincronizar estas cuentas "no-Gmail" con Gmail. Ahora solo con introducir la cuenta Gmail puedo: sincronizar mensajes, escribir desde la cuenta que quiera, y todo como si fuese un Gestor de correos. Y acerté, ya que Gmail de Android, por el motivo que sea no está en continuo envío de paquetes como hacía K-9. Pero aún así no dejaba de bajarme la batería sin estar utilizandose. Me fijé en la intensidad de la linia verde de datos, era mas intensa, y es cierto que tengo poca señal en la habitación. Una noche decidí poner la wifi: TODAVÍA ME CUESTA DE CREER! apenas un cinco por ciento de la batería. screenshot-1319091086583.png Esa es una imagen cutremente retocada con paint.... ¿Pero se ve no? ¿Estoy errado con el consumo de batería de la wifi en comparación a la red de datos? P.D.: En Autokiller - Optimizador de memoria dejé activada Wifi (que escanea cada 3 minutos. 
|
|
|
|
#2
20/10/11, 21:54:54
|
||||
|
||||
|
Wifi consume menos que 3g.
Usa juiceplotter para medir la bateria. Es mas preciso. El perfil de set cpu da igual porque la cpu estará inactiva por la noche. Usa cpuspy para verificar que la cpu entra en deep sleep por la noche. Mide el consumo con 3g, que sera el consumo natural fuera de casa. Desativa bln (black light nification) porque altera el consumo : si te llega un email a las 3am estara encendido toda la noche. Tendras que desactiva la sincronozacion de gmail. El consumo ideal esta en torno a 0.8 y 1.5 % hora. Bajar de ahi es muy dificil. Sent from my Nexus S using Tapatalk
|
|
#5
20/10/11, 23:06:22
|
||||
|
||||
|
haz todo lo que te dice robto, yo desactive latitude de google Maps, y he notado mejora en la autonomía del terminal
__________________
|
|
#6
21/10/11, 01:01:02
|
||||
|
||||
|
Cuanta info! De maravilla.
BLN si, lo tengo configurado para que cuando duerma no se encienda, que a los 20min (tiempo suficiente que considero puedo mirar el smartphone) deje de dar señal. Latitude no lo tengo puesto, ya de por si. Ciertamente setcpu lo tengo configurado min100 max400 conservative Cuando se apaga la pantalla, así que durante la noche como queda apagada, el consumo será inferior. Debo probar la app que comentáis para verificar que el smartphone duerme de noche, a ver que tal. El gasto de batería ronda eso de un 5 a un8% de entre 12 a 8. Una prueba que quería hacer, pero no sé bien bien como configurarla, es la de Optimizador task killer. Por cuanto he leído es bueno tener las aplicaciones abiertas en la memoria, para no tener que volverlas a abrir ya que supone un gasto de energía. Pero por otro lado, ¿no os pasa que cuando lleváis tiempo trasteando de un lado para otro, abriendo cientos de cosas, se os empiece a ralentizar considerablemente? Buscaba algo para hacer una especie de limpieza de cache, y cierre de aplicaciones en memoria al finalizar el día. ¿Creeís que se ganaría en eficacia?
|
|
#7
21/10/11, 02:00:27
|
||||
|
||||
 Cita: Originalmente Escrito por Franciscopr
Cuanta info! De maravilla.
BLN si, lo tengo configurado para que cuando duerma no se encienda, que a los 20min (tiempo suficiente que considero puedo mirar el smartphone) deje de dar señal. Latitude no lo tengo puesto, ya de por si. Ciertamente setcpu lo tengo configurado min100 max400 conservative Cuando se apaga la pantalla, así que durante la noche como queda apagada, el consumo será inferior. Debo probar la app que comentáis para verificar que el smartphone duerme de noche, a ver que tal. El gasto de batería ronda eso de un 5 a un8% de entre 12 a 8. Una prueba que quería hacer, pero no sé bien bien como configurarla, es la de Optimizador task killer. Por cuanto he leído es bueno tener las aplicaciones abiertas en la memoria, para no tener que volverlas a abrir ya que supone un gasto de energía. Pero por otro lado, ¿no os pasa que cuando lleváis tiempo trasteando de un lado para otro, abriendo cientos de cosas, se os empiece a ralentizar considerablemente? Buscaba algo para hacer una especie de limpieza de cache, y cierre de aplicaciones en memoria al finalizar el día. ¿Creeís que se ganaría en eficacia?  centrándome en el tema en cuestión, estaba probando un script que hice con algunas configuraciones que se aplican en modo de espera , voy a calibrar la batería, y comentare resultados , pero aprox. calculo que cercano a 3 hrs de batería por cada 1%. que piensan en probar algunas configuraciones entre los que puedan , y que podamos ir aportando experiencias, así podremos saber a ciencia cierta que es mejor o peor, tal vez abrir algún otro tema o continuar con este. espesando mi aporte de lo que he investigado aparte de lo que sabemos todos , los consumos pantalla y conexiones inalabricas. el consumo se centra en el uso de memoria virtual por ejemplo aumentando estos valores tendremos mayor duración de batería ya que incrementamos el tiempo de escritura, usando valores mas altos con la pantalla apagada podría ser algún ahorro de energía sobre todo si tenemos algunas aplicaciones funcionando como algún servicio de chat echo 1500 > /proc/sys/vm/dirty_writeback_centisecs echo 1500 > /proc/sys/vm/dirty_expire_centisecs otra de las configuraciones que es mas obvia es reducir a 0 el valor de swapp que en nuestro caso afectaría ya que tendríamos disponible menos ram. echo 0 > /proc/sys/vm/swappiness y por ultimo si alguien quiere probar otra opción que todavía no he comprobado si funciona realmente es : echo 5 > /proc/sys/vm/laptop_mode de manera simple lo que realiza, es acumular datos para luego escribirlos en el disco, lo cual hace que se use menos la memoria que en nuestro caso al no ser un hdd, quizás no exista una mejora real. espero sus comentarios , y ojala podamos trabajar en conjunto. un saludo Última edición por teckx Día 21/10/11 a las 02:06:05.
|
|
#8
21/10/11, 10:38:59
|
||||
|
||||
|
lo mejor es dejar un acceso directo al gestor de conexiones y desconectar el consumo de datos por la noche. el consumo de bateria no llega al 5/6% y no creo que a nadie le haga falta recibir correos a las 5 de la mañana.
|
|
#9
21/10/11, 11:45:18
|
||||
|
||||
|
vicenfox tienes toda la razón. hay muchas cosas que no son necesarias ni imprescindible. Mirandolo desde un punto de vista mas utilitario, una continua mejora del Nexus S es mas una distracción. Nexus S tiene mucha potencia, dejandola a 1200hz, tiene mas que de sobra. Pero el hecho de investigar, trastear, mejoras continuas hace del Smartphone: Un reto continuo, una distracción agradable para desconectar del trabajo, y muchas otras cosas.
teckx muy muy interesante!! no tenía ni idea de lo del script, y es genial! 1. Con la pantalla apagada augmentar valores de memoria virtual: No estoy del todo deacuerdo. Si apagamos la pantalla yen ese instante augmentamos los valores, cuando volvamos a encender aunque bajen los valores tendremos que volver a cargar las aplicaciones. La idea que tenía era utilizar estos augmentos de valores en la memoria virtual durante la noche. Y al día siguiente al encender la pantalla volver a bajar los valores para no tener que cargar aplicaciones continuamente. El compañero robto comentó lo del deep sleep (cuando duerme el smartphone). ¿qué condición se tiene que cumplir para activar deep sleep? ¿si conocieramos esta condición no podríamos generar la condición de: augmentar los valores de memoria virtal cuando se active deep sleep? 2. Los valores de la swap se pueden reducir a 0 desde el recovery. 3. lo que comentas del hdd es una de las opciones de Optimicer memori. Por el momento no meteré el script de jewe11, ya que muchas de las aplicaciones las puede hacer Optimicer memori. Veamos como sigue el hilo, son mejoras muy buenas!! P.D.: teckx una consulta: la caché. ¿Las aplicaciones generan continuamente caché? Si es así ¿el tener el smartphone mucho tiempo encendido, no produciría tanta memoría cahé que lo relentizara?
|
|
#10
21/10/11, 13:13:57
|
||||
|
||||
|
teckx Si no estoy equivocado el script es un archivo que debe sustituirse o incluirse en el init. Este archivo init (imagino) se abre al principio de encender el Smartphone. Por eso mismo entré en la memoria principal (/) y busqué los archivos con init, me los llevé al ordenador y abrí con el bloc de notas y.... tachan! (init.rc)
Write value must be consistent with the above properties. # Note that the driver only supports 6 slots, so we have combined some of # the classes into the same memory level; the associated processes of higher # classes will still be killed first. write /sys/module/lowmemorykiller/parameters/adj 0,1,2,4,7,15 write /proc/sys/vm/overcommit_memory 1 write /proc/sys/vm/min_free_order_shift 4 write /sys/module/lowmemorykiller/parameters/minfree 2048,3072,4096,6144,7168,8192 # Set init its forked children's oom_adj. write /proc/1/oom_adj -16 # Tweak background writeout write /proc/sys/vm/dirty_expire_centisecs 200 write /proc/sys/vm/dirty_background_ratio 5 y no solo eso... una curiosidad: /sys/kernel/ipv4/tcp_rmem_max chown root radio /proc/cmdline # Define TCP buffer sizes for various networks # ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax, setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.wifi 4095,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.umts 4094,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.edge 4093,26280,35040,4096,16384,35040 setprop net.tcp.buffersize.gprs 4092,8760,11680,4096,8760,11680 class_start default ## Daemon processes to be run by init. Por una parte, el script de jewe11 es una modificación del init, unos comandos que debe hacer al arrancar. Osease, puede modificarse directamente en este init.rc. Por otro lado los bufers de las antenas. No es por nada, pero me da la impresión de que con estos parametros podríamos mejorar las conexiones con las antenas. Espero seguir informandome, y poder averiguar mas sobre android. Parece sencillo si utilizamos ciertas reglas... podemos encontrar cosas curiosas, lástima que no sea programador Saludos
|
|
#11
21/10/11, 18:03:34
|
||||
|
||||
|
Cita: Originalmente Escrito por Franciscopr
teckx Si no estoy equivocado el script es un archivo que debe sustituirse o incluirse en el init. Este archivo init (imagino) se abre al principio de encender el Smartphone. Por eso mismo entré en la memoria principal (/) y busqué los archivos con init, me los llevé al ordenador y abrí con el bloc de notas y.... tachan! (init.rc)
Write value must be consistent with the above properties. # Note that the driver only supports 6 slots, so we have combined some of # the classes into the same memory level; the associated processes of higher # classes will still be killed first. write /sys/module/lowmemorykiller/parameters/adj 0,1,2,4,7,15 write /proc/sys/vm/overcommit_memory 1 write /proc/sys/vm/min_free_order_shift 4 write /sys/module/lowmemorykiller/parameters/minfree 2048,3072,4096,6144,7168,8192 # Set init its forked children's oom_adj. write /proc/1/oom_adj -16 # Tweak background writeout write /proc/sys/vm/dirty_expire_centisecs 200 write /proc/sys/vm/dirty_background_ratio 5 y no solo eso... una curiosidad: /sys/kernel/ipv4/tcp_rmem_max chown root radio /proc/cmdline # Define TCP buffer sizes for various networks # ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax, setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.wifi 4095,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.umts 4094,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.edge 4093,26280,35040,4096,16384,35040 setprop net.tcp.buffersize.gprs 4092,8760,11680,4096,8760,11680 class_start default ## Daemon processes to be run by init. Por una parte, el script de jewe11 es una modificación del init, unos comandos que debe hacer al arrancar. Osease, puede modificarse directamente en este init.rc. Por otro lado los bufers de las antenas. No es por nada, pero me da la impresión de que con estos parametros podríamos mejorar las conexiones con las antenas. Espero seguir informandome, y poder averiguar mas sobre android. Parece sencillo si utilizamos ciertas reglas... podemos encontrar cosas curiosas, lástima que no sea programador Saludos Si quieres crear uno para init.d Solo crea un archivo con el siguiente encabezado #!/system/bin/sh Si quieres puedes hacer pruebas con las lineas que deje anteriormente. Saludos Enviado desde mi Nexus S usando Tapatalk Última edición por teckx Día 21/10/11 a las 18:09:56.
|
| Gracias de parte de: | ||
|
#12
22/10/11, 11:39:08
|
||||
|
||||
|
Seguiré un poco mas, no me sirve de mucho preparar un archivo sin saber com puedro comprobar que funcione correctamente. ¿Como debo llamar al archivo?
El tema de las antenas.... Si tu mejoras "no la calidad" si no el funcionamiento de las mismas, puede ser que se reduzca el consumo de la batería. No enviando mas información que la encesaria, no haciendo barridos continuados en busqueda de la red wifi, pero bueno... creo que es demasiado si apenas entiendo que valores debo configurar en la memoria virtual. Seguramente si voy teniendo tiempo, bajaré algunas roms, recuperaré el archivo init de cada una de ellas e iré investigando los valores que tienen y los funcionamientos en cada uno de ellos. Si yo preparo un init y en init.d que ya está en la memoria: ¿a quien hará caso primero? y si es que lee el mío en segundo: ¿modificará init(mio) los valores sobre las linias de init.d ya en memoria? Ahora mismo estoy de examenes, a ver si tengo tiempos y puedo continuar con ello
|
|
#13
25/10/11, 00:15:36
|
||||
|
||||
|
Cita: Originalmente Escrito por teckx
centrándome en el tema en cuestión, estaba probando un script que hice con algunas configuraciones que se aplican en modo de espera , voy a calibrar la batería, y comentare resultados , pero aprox. calculo que cercano a 3 hrs de batería por cada 1%.
He puesto el script de Juwe11. Haré unas pruebas de consumo y aplicaré los valores que recomiendas a ver qué tal. Pondré aquí los resultados. Gracias por compartirlo!!
|
|
#14
25/10/11, 00:58:56
|
||||
|
||||
|
Cita: Originalmente Escrito por robto
1% en 3 horas es muy espectacular.
He puesto el script de Juwe11. Haré unas pruebas de consumo y aplicaré los valores que recomiendas a ver qué tal. Pondré aquí los resultados. Gracias por compartirlo!! Enviado desde mi Nexus S usando Tapatalk
|
|
#15
25/10/11, 07:34:35
|
||||
|
||||
|
Cita: Originalmente Escrito por Franciscopr
Write value must be consistent with the above properties. # Note that the driver only supports 6 slots, so we have combined some of # the classes into the same memory level; the associated processes of higher # classes will still be killed first. write /sys/module/lowmemorykiller/parameters/adj 0,1,2,4,7,15 write /proc/sys/vm/overcommit_memory 1 write /proc/sys/vm/min_free_order_shift 4 write /sys/module/lowmemorykiller/parameters/minfree 2048,3072,4096,6144,7168,8192 # Set init its forked children's oom_adj. write /proc/1/oom_adj -16 # Tweak background writeout write /proc/sys/vm/dirty_expire_centisecs 200 write /proc/sys/vm/dirty_background_ratio 5 /sys/kernel/ipv4/tcp_rmem_max chown root radio /proc/cmdline # Define TCP buffer sizes for various networks # ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax, setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.wifi 4095,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.umts 4094,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.edge 4093,26280,35040,4096,16384,35040 setprop net.tcp.buffersize.gprs 4092,8760,11680,4096,8760,11680 class_start default ## Daemon processes to be run by init. http://forum.xda-developers.com/show....php?t=1111145
|
|
#16
25/10/11, 07:53:57
|
||||
|
||||
|
Cita: Originalmente Escrito por teckx
He calibrado la bateria y me esta durando 2.7hrs por cada 1% en modo espera, tengo modem kf1 y la rom mia en la cual tengo el script. Quiero llegar a las 3 horas :P
Enviado desde mi Nexus S usando Tapatalk Ayer metí el script de Juwe11 original y he conseguido esta noche un consumo de 1%/hora (consumo anterior 1.2%/hora)(en modo avión me consume 0.75 %/hora). Acabo de actualizar los parámetros que recomendabas a ver que tal, aunque uso otra rom y configuración, por lo que los resultados no tienen por qué ser idénticos (tengo Oxygen 222 + Matr1x 8.5 con un poquito de overvolt, radio KD1 -va mejor en mi zona) Con Juwe11 original, la verdad, visualmente no noto mucha mejora de velocidad (es dificil de medir), aunque tengo la CPU on demand 100-1300 y me da poco más de 4000 en quadrant, es decir, que va muy rápida en general (últimamente me ha dado por la velocidad).
|
|
#17
25/10/11, 10:37:37
|
||||
|
||||
|
Cita: Originalmente Escrito por robto
De donde salen estos parámetros? No los veo en el script de Juwe11.
http://forum.xda-developers.com/show....php?t=1111145 son otras configuraciones , no te confundas . en el script de Juwe11 puedes modificar estos parámetros y puedes ganar algo mas de batería con coste de rendimiento # este valor si lo colocas en 0 no consumira memoria memoria adicional a la ram , claro que al, utilizar varias aplicaciones ayuda a tener memoria virtual. echo "20" > /proc/sys/vm/swappiness # los siguientes al aumentarlos puede mejorar el consumo , también dependiendo el valor afecta el rendimiento. echo "3000" > /proc/sys/vm/dirty_expire_centisecs echo "500" > /proc/sys/vm/dirty_writeback_centisecs pueden googlear mas acerca de estas configuraciones, para que tengan una mejor explicacion, estos son solo relacionado con la memoria swapp Cita: Originalmente Escrito por robto
Impresionante. 2.7 horas por cada 1% es 0.37%/hora. "Insane" que dicen los americanos.
Ayer metí el script de Juwe11 original y he conseguido esta noche un consumo de 1%/hora (consumo anterior 1.2%/hora)(en modo avión me consume 0.75 %/hora). Acabo de actualizar los parámetros que recomendabas a ver que tal, aunque uso otra rom y configuración, por lo que los resultados no tienen por qué ser idénticos (tengo Oxygen 222 + Matr1x 8.5 con un poquito de overvolt, radio KD1 -va mejor en mi zona) Con Juwe11 original, la verdad, visualmente no noto mucha mejora de velocidad (es dificil de medir), aunque tengo la CPU on demand 100-1300 y me da poco más de 4000 en quadrant, es decir, que va muy rápida en general (últimamente me ha dado por la velocidad). Última edición por teckx Día 25/10/11 a las 11:17:51.
|
|
#18
25/10/11, 11:15:01
|
||||
|
||||
|
Cita: Originalmente Escrito por Franciscopr
vicenfox tienes toda la razón. hay muchas cosas que no son necesarias ni imprescindible. Mirandolo desde un punto de vista mas utilitario, una continua mejora del Nexus S es mas una distracción. Nexus S tiene mucha potencia, dejandola a 1200hz, tiene mas que de sobra. Pero el hecho de investigar, trastear, mejoras continuas hace del Smartphone: Un reto continuo, una distracción agradable para desconectar del trabajo, y muchas otras cosas.
teckx muy muy interesante!! no tenía ni idea de lo del script, y es genial! 1. Con la pantalla apagada augmentar valores de memoria virtual: No estoy del todo deacuerdo. Si apagamos la pantalla yen ese instante augmentamos los valores, cuando volvamos a encender aunque bajen los valores tendremos que volver a cargar las aplicaciones. La idea que tenía era utilizar estos augmentos de valores en la memoria virtual durante la noche. Y al día siguiente al encender la pantalla volver a bajar los valores para no tener que cargar aplicaciones continuamente. El compañero robto comentó lo del deep sleep (cuando duerme el smartphone). ¿qué condición se tiene que cumplir para activar deep sleep? ¿si conocieramos esta condición no podríamos generar la condición de: augmentar los valores de memoria virtal cuando se active deep sleep? 2. Los valores de la swap se pueden reducir a 0 desde el recovery. 3. lo que comentas del hdd es una de las opciones de Optimicer memori. Por el momento no meteré el script de jewe11, ya que muchas de las aplicaciones las puede hacer Optimicer memori. Veamos como sigue el hilo, son mejoras muy buenas!! P.D.: teckx una consulta: la caché. ¿Las aplicaciones generan continuamente caché? Si es así ¿el tener el smartphone mucho tiempo encendido, no produciría tanta memoría cahé que lo relentizara? 1- entiendo lo que piensas , pero si tienes la pantalla apagada con algún programa de chat WhatsApp etc... necesitas tener rendimiento ?? ...No, entonces ya no es tan necesario tener la ram lo mas limpia posible , así no se gasta energía en traspasar datos sucios a la memoria swapp. es una idea similar a lo que hace la opcion "laptop mode" que se usa en notebook, solo que relacionado con escritura en la memoria principal hdd o sd. En el tema de desactivar el swapp es mejor utilizarlo con algun valor que estar continuamente cambiando, aunque no estaría mal probar  2- por recovery es flasheando un script, al ejecutar el comando echo "0"..... es temporal , por eso hay que mantener el script en la carpeta init.d para que se ejecute al arranque, se pueden hacer cambios que se guarden atraves de sysctl pero no me ha funcionado 3- no conozco ese programa el cache solo tienes datos de programas, no es que se generen siempre, si te refieres al tema de la ram, la memoria swapp se encarga de ayudar por decirlo de algún modo a la memoria ram, ayuda a mantener procesos poco activos , lo que ayuda a tener mas ram disponible , el proceso es algo mas lento pero ayuda. por eso al reducir el swapp a "0" solo se utilizara la memoria ram que en nuestro caso no es tanta , en dispositivos con 1GB de ram es distinto . Última edición por teckx Día 25/10/11 a las 11:22:20.
|
|
#19
25/10/11, 22:28:11
|
||||
|
||||
|
Cita: Originalmente Escrito por teckx
para aclarar los resultados que obtuve son modificando un poco los valores del script de juwe11 y teniendo un script que hice, que cambia algunas configuraciones al estar en modo de espera que están incluidos en mi rom basada en cm7, estoy en pruebas todavía, espero mejorarlo algo mas. saludos
 Me dan muchas ganas de probar tu rom. Me declaro cyanogenofilo, pero a mi nexus no le sienta bien cyanogen ... y llevo probando nightlies desde la 70. La 215 parecia que iba bien pero .... no : se queda congelada cuando le apetece. Necesito fiabilidad. A ver si con tu rom consigo romper la tendencia. Asi que animo con ella!!! Sent from my Nexus S using Tapatalk
|
|
|
|
#20
26/10/11, 01:27:24
|
||||
|
||||
|
Cita: Originalmente Escrito por robto
Gracias @teckx por la informacion aportada. Hare unas pruebas -ya tengo entretenimiento para los proximos dias
Me dan muchas ganas de probar tu rom. Me declaro cyanogenofilo, pero a mi nexus no le sienta bien cyanogen ... y llevo probando nightlies desde la 70. La 215 parecia que iba bien pero .... no : se queda congelada cuando le apetece. Necesito fiabilidad. A ver si con tu rom consigo romper la tendencia. Asi que animo con ella!!! Sent from my Nexus S using Tapatalk  . dejo una captura , no lo pude evitar , recibi 2 llamadas . saludos  
|
|
Estás aquí
|
||||||
|
||||||
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar355660_1.gif){kind=avatar}
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar17845_1.gif){kind=avatar}
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar289651_29.gif){kind=avatar}
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar484351_1.gif){kind=avatar}
![Array
[xs_avatar]](https://avatar.htcmania.com/avatares/avatar323510_1.gif){kind=avatar}