Micro Charts

redes móviles, Wi-Fi y Bluetooth. En el caso de redes móviles y Wi-Fi, cuyo consumo también está contemplado en las aplicaciones, Android distingue entre el uso de estos componentes por parte del sistema o por parte de las aplicaciones. Su consumo no se contabiliza dos veces.

Para cada uno de estos componentes se genera un objeto BatterySipper en el que se específica su tipo de consumo.

Los consumos que aparecen como UNNACOUNTED y OVERCOUNTED son

debidos a una mala estimación del consumo real. Es decir, si la batería ha sufrido una descarga del 20 % y su capacidad es de 3000mAh, quiere decir que se han consumido 600mAh. Estos 600mAh son reales, ya que el porcentaje de batería ha disminuido del 100 % al 80 %. Sin embargo, a veces, el teléfono estima que ha consumido 500mAh, debido a la sucesión de errores en los timers. Esto supone que aparezca un consumo

de UNNACOUNTED de 100mAh.

En el caso contrario, si el teléfono cree que ha consumido 700mAh, aparecerá un consumo de OVERCOUNTED de 100mAh.

La forma de calcular el consumo a partir de los valores definidos enpower_profile es la siguiente. El valor de consumo se recoge en mA, y se divide por 3600 para hacer la conversión a mAh. Pongamos por ejemplo que el dispositivo ha estado con el Wi-Fi escaneando durante dos horas. Su consumo se calcularía de la siguiente manera:

wifi.scan * 2 = 200mAh .

El valor dewifi.scan ha sido extraído del valor de referencia de la Tabla 3.1.

3.6.

Herramientas

Existen algunas herramientas para obtener feedback del consumo. Estas herramientas presentan información acerca del consumo, y del historial de eventos presente en el dispositivo.

3.6.1. Dumpsys

La herramienta más utilizada durante la realización de este TFG ha sido la salida dedumpsys batterystats.Dumpsys es una herramienta propia de Android cuya salida proporciona información relevante acerca de los servicios del sistema. En nuestro caso, de nuevo, nos interesa el servicio del sistema BatteryStats. Lo más sencillo es volcar la salida a un fichero con extensión txt para facilitar su lectura.

Los datos que aporta son relevantes para las estadísticas de batería, ya que aparecen todos los tiempos que cada componente ha estado activo, además de los consumos detallados de cada aplicación. Muestra todos los wakelocks que han despertado al

14 _{Capítulo 3.}Estadísticas de batería

teléfono de su estado de reposo y que suponen un aumento significativo en el consumo.

3.6.2. Battery Historian

Otra herramienta interesante es el repositorio de Google en Github llamado BatteryHistorian [7]. Este repositorio está escrito en GO y al ejecutarlo genera un servidor local en el que permite subir la salida de dumpsys batterystats comentada anteriormente.

Este servidor representa gráficamente los eventos que han ocurrido en el teléfono además de presentar los datos importantes de una manera más visual. Esto facilita enormemente el estudio de la salida de dumpsys que genera un fichero con más de mil líneas y su lectura es pesada.

Figura 3.1: Ejemplo de gráfica de Battery historian

3.6.3. FTrace

FTrace (Function Tracer) es una herramienta que permite perseguir el flujo de ejecución en el kernel de Linux. Todas las interacciones del usuario con su smartphone suponen una llamada al kernel, por lo que esta herramienta facilita seguir la comunicación entre espacio de usuario y kernel.

Esta herramienta es muy útil para perseguir loswakelocksque despiertan al teléfono de su modo de reposo y que suponen un aumento importante en el consumo.

Capítulo 4

Mejoras de cálculo de consumo

No podemos resolver problemas pensando de la misma manera que cuando los creamos. Albert Einstein

Resumen:En este capítulo se presentan los problemas detectados en la adquisición y en el cálculo del consumo. Se propone solución para algunos de ellos, y en otros se explica el porqué no ha sido posible resolver el problema. Por último se realiza una comparación de estos problemas con Android L.

Para el desarrollo de este capítulo se estudió el funcionamiento de las estadísticas de batería en Android. A lo largo del estudio se encontraron varias deficiencias que hacían que el consumo calculado fuera poco fiable. A continuación se analizan dichas deficiencias y se presentan soluciones en los casos en los que sea posible. Si no es posible encontrar una solución, se explica el porqué de esta decisión.

4.1.

Consumo de Bluetooth

El funcionamiento del Bluetooth [8] es un poco diferente al resto de servicios del sistema. Google ha decidido que exista un servicio del sistema específico para el Bluetooth, pero por debajo ha implementado una aplicación que funciona como el servicio. Es decir, el servicio del sistema delega sus funciones en la aplicación.

Esta aplicación es invisible para el usuario. Todo el consumo generado por el Bluetooth se le atribuye a esta aplicación. De este modo, cualquier aplicación que utilice el Bluetooth, como por ejemplo cualquiera encargada de comunicarse con un wearable, tendrá consumos muy bajos ya que no se le suma el consumo debido a la comunicación por Bluetooth.

La solución a este problema es eliminar dicha aplicación y dejar que el Bluetooth funcione como servicio del sistema de manera similar al Wi-Fi. Eliminar la aplicación no es sencillo, ya que todo el código se encuentra en ésta y el servicio del sistema no implementa ninguna funcionalidad sin la aplicación. Por lo que se debería reescribir el