|
||
|
#101
|
||||
|
||||
|
a mi me pasa una cosa rara con todas las versiones de cm (la 9 la 10 o la 10.1 ke llevo ahora) y es ke se me dispara el SO android y en el better battery stats me sale el multipdp,y en partial wakelocks la sincro del gtalk...he deshabilitado el gtalk pero sigue subiendo como la espuma cuando entro en deep sleep (con la pantalla encendida no me pasa,es mas,el consumo de cm10.1 con la pantalla encendida es excepcional)
![]() Aquí http://goo.gl/kay49 hablan de el, pero no tienen muy claro a qué es debido. Alguien lo solucionó parace ser dejando en blanco el campo "proxy" en la configuración del APN. Pero eso a mi no me funcionó, tengo Movistar y ya está en blanco. Yo llegué a deshabilitar GTalk, pausar la sincronización de la cuenta de google, instalar un cortafuegos que impidiera la conexión a internet de todas las aplicaciones que tuvieran algo que ver con Google, de todas las aplicaciones del kernel, de todas las del sistema operativo ...... y no funcionó nada. Sólo dejaba de tenerlo si no estaba conectado a internet. Llevo CM10. |
|
|
|
#102
|
||||
|
||||
|
a mi todos esos procesos me han desaparecido en cm10.1,como por arte de magia,el multidpd me ha desaparecido por completo,y los procesos de google como gtalk,maps y esos,se han reducido un monton,ya no me molesto ni en desactivar Google now
|
|
#103
|
||||
|
||||
|
a mi en cm10 parece ke me lo hacia un poco menos... habra ke esperar a ver si en versiones nuevas lo solucionan,si no cuando salga la final y alguien haga una cocinada pues me tendre ke meter esa >_<
|
|
#104
|
||||
|
||||
|
Holaa tengo un consumo elevado de bateria con el Sistema Android y no se a que se debe, mientras el SO Android consume un 7-8%, el Sistema Android chupa entre 25-26%, por que puede ser?
|
|
#105
|
||||
|
||||
|
hola compis! alguno sabe que es el ConnectivtyService?? porque en las foto que he visto, a ninguno le sale tan elevado como a mi... gracias por la ayuda!!
EDITO: foto abajo, perdon D
|
|
#108
|
||||
|
||||
|
Consumos de esta noche.
Rom resurrection remix 3.1.2 Set cpu en ondemand con máximo de 800 en screen off. Wifi y 2g. |
|
#109
|
||||
|
||||
|
Un 1% A la hora no es un mal consumo con una rom AOSP, los procesos son los normales en éste tipo de roms
|
|
#110
|
||||
|
||||
|
|
| Gracias de parte de: | ||
|
#111
|
||||
|
||||
|
Por si puede servir he encontrado esta explicacion traducida de un post de XDA sobre "partial wakelocks" por si puede servir de ayuda. Me ha parecido interesante:
En XDA hay bastante información sobre lo que se ha encontrado sobre el tema. Parece ser que la causa de ese bug es "otros bugs" que algunas aplicaciones dan con los "Partial Wakelocks". A modo de super-resumen-simplificado (que no se me tire encima ningún experto ), voy a traducir y simplificar la información de XDA sobre qué es un "partial wakelock":El teléfono tiene, resumiendo mucho, lo que serían unos 3 modos de operación: "activo, despierto y reposo". Ya digo que la traducción de los "nombres" es licencia artística mía para hacerlo "más llano", así que dev's y otros expertos, no me echéis a los leones todavía... Cuando estás usando el teléfono, por norma general, está activo (la CPU trabaja a una velocidad "alta"). Cuando dejamos de usarlo (cerramos la aplicación o terminamos la llamada) el teléfono queda "despierto" pero no "activo" (la pantalla está encendida y el teléfono está listo para ser usado, pero no está siéndolo). Y cuando ha pasado cierto tiempo sin que lo uses, se pasa a "reposo" (la CPU baja de velocidad y varios procesos se suspenden para ahorrar batería). Esto a grandes rasgos, insisto. Digamos que el estado "del medio" es un estado de transición entre el "activo" y el "reposo", y que lo ideal es, siempre que no necesite estar activo, pase a reposo para ahorrar ese gasto de batería innecesario. Pero eso no es siempre posible... por ejemplo, cuando haces una llamada. Si el teléfono pasase a "reposo" se te cortaría la llamada, y por eso es por lo que el proceso de la llamada hace un "wakelock" (o lo que es lo mismo, bloquea el teléfono en el modo "despierto") para que sigan ejecutándose los procesos necesarios para la llamada y para que el teléfono esté listo para responder a cualquier comando (como el de colgar la llamada). Eso pasa con infinidad de aplicaciones y procesos, y es necesario. No es "malo" siempre que un proceso ejecute un wakelock y no deje irse el teléfono al modo "reposo" precisamente por eso, porque para que funcionen muchas cosas necesitan que el teléfono no esté en ese reposo. Pero el problema de los "partial wakelocks" que aparecen reflejados dentro del proceso "SO Android" viene siendo que ciertas aplicaciones y servicios "abusan" de ese "wakelock" impidiendo que el teléfono se vaya al modo "reposo" y, por tanto, manteniendo la CPU a un nivel de velocidad "medio" y procesos abiertos que hacen que la batería se consuma mucho antes. Estos programas y procesos que "alimentan el bug" suelen ser, por norma general, programas que necesitan mantener una conexión de datos activa (para sincronizarse) y cosas así. No son todos los que necesitan datos, y no son sólo los que necesitan conexión de datos... por tanto hay que estudiar cada caso independientemente. Pero la fuente del problema viene ahí. Con algunos kernels nuevos que han salido después, se supone que "se corregía" el problema, pero se comprobó que lo único que hacían esos kernels era no tener en cuenta los wakelocks para el cómputo de consumo de batería en el proceso "SO Android", por lo que lo único que "reparan" esos kernels es que no aparece reflejado, pero el consumo de batería sigue siendo el mismo. Y como experiencia personal, hay por ejemplo una aplicación que se llama "Samsung Push Service" que, si entras en Samsung Apps se te actualiza y es, sin duda alguna, uno de los que más partial wakelocks provocan (si entras en Samsung Apps, inicias sesión en tu cuenta, y entras en "opciones" y puedes desactivar "recibir notificaciones push si compras aplicaciones desde la web"... y el proceso deja de ser un drena-baterías). Por eso a cualquiera que "sufra" este bug le recomiendo que mire qué aplicaciones necesita y cuales no, a cuales les quiere mantener la conexión permanentemente activas y cuales no (ya digo que no son sólo las de "datos" ni tampoco todas las de "datos" son las que lo provocan), y que con paciencia y probando (en XDA está muchísima información sobre qué mirar y cómo mirarlo) es bastante "solucionable" el asunto. Y mi batería ya dura tranquilamente todo el fin de semana sin cargar y dándole el mismo uso ![]() Saludos.
__________________
![]() |
| Los siguientes 12 usuarios han agradecido a pringaguardias su comentario: | ||
|
#112
|
||||
|
||||
|
Hola.
No se si ya esta posteado en otro mensaje, sabe alguien de que es el proceso awake. Saludos. |
|
#114
|
||||
|
||||
|
|
|
#115
|
||||
|
||||
|
Tienes un tutorial en el primer post de cómo usarla, pero tienes que ser root si quieres que te muestre todo
|
|
#116
|
||||
|
||||
|
solo me mostraba los datos de since boot. Ahora tengo otra versión que si funciona bien. Ya iré os iré preguntando a medida que vaya haciendo pruebas. Saludos. |
| Gracias de parte de: | ||
|
#117
|
||||
|
||||
|
Buenas, donde puedo conseguir el better battery stats? En el Market no aparece
|
|
#118
|
||||
|
||||
|
|
|
#119
|
||||
|
||||
|
Saludos. Última edición por PEPO Día 07/01/13 a las 21:16:21. |
|
|
|
#120
|
||||
|
||||
|
Como veis éstas capturas ?...creo que las he tomado bien
![]() ![]() ![]()
|
![]() |
Estás aquí
|
||||||
|
||||||
| Herramientas | |