Con el framework de Android, los fabricantes de dispositivos y los desarrolladores de apps pueden usar datos térmicos para garantizar una experiencia del usuario (UX) coherente si un dispositivo comienza a sobrecalentarse. Por ejemplo, cuando un sistema se somete a estrés térmico, se limita la cantidad de trabajos de jobscheduler y, si es necesario, se inicia un apagado térmico del framework. Las apps que reciben notificaciones de estrés térmico a través de una devolución de llamada registrada en la clase PowerManager pueden ajustar su UX de forma correcta.
HAL de Thermal
Android 9 y versiones anteriores usan una interfaz de sondeo definida en Thermal HAL 1.0 para obtener lecturas de temperatura. Este HAL permitía que el framework de Android y otros clientes de confianza, como el HAL de un fabricante de dispositivos, leyeran la temperatura actual y los umbrales de cierre y limitación específicos de la política del producto para cada sensor a través de la misma API.
Android 10 introdujo un sistema térmico en el framework de Android y una nueva versión de la HAL, Thermal HAL 2.0, que abstrae la interfaz a los dispositivos de hardware del subsistema térmico. La interfaz de hardware incluye sensores de temperatura y termistores para la máscara, la batería, la GPU, la CPU y el puerto USB. La temperatura de la carcasa del dispositivo es el sistema más importante que se debe monitorear para mantener la temperatura de la superficie del dispositivo dentro de los límites térmicos especificados.
Además, Thermal HAL 2.0 proporciona a varios clientes lecturas de sensores térmicos y niveles de gravedad asociados para indicar estrés térmico. En la siguiente figura, se muestran dos mensajes de advertencia de la IU del sistema Android. Estos mensajes se muestran cuando la interfaz de devolución de llamada IThermalEventListener para los sensores USB_PORT y SKIN, respectivamente, alcanza el nivel de gravedad THERMAL_STATUS_EMERGENCY.
Figura 1: Advertencias de sobrecalentamiento
Las temperaturas actuales se recuperan para los diferentes tipos de sensores térmicos a través de IThermal HAL. Cada llamada a la función devuelve un valor de estado de SUCCESS o FAILURE. Si se devuelve SUCCESS, el proceso continúa. Si se devuelve FAILURE, se envía un mensaje de error legible para las personas a status.debugMessage.
Además de ser una interfaz de sondeo que devuelve las temperaturas actuales, puedes usar la devolución de llamada IThermalChangedCallback (HIDL, Android 10 a 13) o IThermalChangedCallback (AIDL, Android 14 y versiones posteriores) con la interfaz de devolución de llamada de los clientes de la HAL de Thermal, como el servicio de Thermal del framework. Por ejemplo, RegisterIThermalChangedCallback y UnregisterIThermalChangedCallback para registrar o cancelar el registro de eventos de gravedad modificada. Si cambió la gravedad térmica de un sensor determinado, notifyThrottling envía una devolución de llamada de evento de regulación térmica a los objetos de escucha de eventos térmicos.
Además de la información del sensor térmico, en getCurrentCoolingDevices se expone una lista de dispositivos de enfriamiento mitigados. El orden de esta lista es persistente, incluso si un dispositivo de enfriamiento se desconectó. Los fabricantes de dispositivos pueden usar la lista para recopilar métricas de statsd.
Para obtener más información, consulta la implementación de referencia.
Si bien puedes agregar tus propias extensiones, no debes inhabilitar la función de mitigación térmica.
Servicio térmico
En Android 10 y versiones posteriores, el servicio térmico del framework proporciona una supervisión constante con los diversos indicadores de mitigación de la HAL de Thermal 2.0 y brinda comentarios sobre la gravedad de la limitación a sus clientes. Estos clientes incluyen componentes internos y apps para Android. El servicio usa dos interfaces de devolución de llamada de Binder, IThermalEventListener y IThermalStatusListener, que se exponen como devoluciones de llamada. El primero es para uso interno de la plataforma y el fabricante del dispositivo, y el segundo es para apps para Android.
A través de las interfaces de devolución de llamada, se puede recuperar el estado térmico actual de un dispositivo como un valor entero que va de 0x00000000 (sin limitación) a 0x00000006 (apagado del dispositivo). Solo un servicio de sistema confiable, como una API de Android o la API del fabricante del dispositivo, puede acceder a la información detallada del sensor térmico y de los eventos térmicos. En la siguiente figura, se proporciona un modelo del flujo del proceso de mitigación térmica en Android 10 y versiones posteriores:
Figura 2: Diagrama de flujo del proceso de mitigación térmica en Android 10 y versiones posteriores.
Lineamientos del fabricante del dispositivo
Para informar el estado de regulación y el sensor de temperatura del dispositivo en Android 10 a 13, los fabricantes de dispositivos deben implementar el aspecto HIDL de la HAL térmica 2.0 (IThermal.hal).
Para informar el estado del sensor de temperatura y la limitación del dispositivo en Android 14, los fabricantes de dispositivos deben implementar el aspecto del AIDL de la HAL de Thermal 2.0 (IThermal.aidl).
Todo lo que limite el rendimiento del dispositivo, incluidas las restricciones de energía de la batería, se debe informar a través del HAL térmico. Para garantizar que esto suceda, coloca todos los sensores que puedan indicar la necesidad de mitigación (según los cambios de estado) en el HAL térmico y registra la gravedad de las acciones de mitigación que se tomen. El valor de temperatura que se devuelve de una lectura del sensor no tiene que ser la temperatura real, siempre y cuando refleje con precisión el umbral de gravedad correspondiente. Por ejemplo, puedes pasar diferentes valores numéricos en lugar de los valores reales de umbral de temperatura o puedes incorporar la protección de banda en las especificaciones de umbral para proporcionar histéresis. Sin embargo, la gravedad correspondiente a ese valor debe coincidir con lo que se necesita en ese umbral. Por ejemplo, puedes decidir devolver 72 °C como el umbral de temperatura crítico cuando la temperatura real es de 65 °C y corresponde a la gravedad crítica que especificaste. El nivel de gravedad debe ser preciso para que el marco térmico funcione de la mejor manera.
Para obtener más información sobre los niveles de umbral en el marco de trabajo y cómo se corresponden con las acciones de mitigación, consulta Cómo usar códigos de estado térmico.
Cómo usar las APIs térmicas
Las apps pueden agregar y quitar objetos de escucha, y acceder a la información del estado térmico a través de la clase PowerManager.
La interfaz IThermal proporciona toda la funcionalidad necesaria, incluido el retorno de los valores de estado térmico. La interfaz del vinculador IThermal se encapsula como la interfaz OnThermalStatusChangedListener, que las apps pueden usar cuando registran o quitan objetos de escucha del estado térmico.
Las APIs térmicas de Android tienen métodos de devolución de llamada y de sondeo para que las apps reciban notificaciones sobre los niveles de gravedad térmica a través de códigos de estado, que se definen en la clase PowerManager. Los métodos son los siguientes:
getCurrentThermalStatus()muestra el estado térmico actual del dispositivo como un número entero, a menos que el dispositivo esté en modo de limitación.addThermalStatusListener()agrega un objeto de escucha.removeThermalStatusListener()quita un objeto de escucha agregado anteriormente.
Usa códigos de estado térmico
Los códigos de estado térmico se traducen en niveles de regulación específicos que puedes usar para recopilar datos y diseñar una UX óptima. Por ejemplo, las apps pueden recibir un estado de 0x00000000 (THERMAL_STATUS_NONE), que más tarde puede cambiar a 0x00000001 (THERMAL_STATUS_LIGHT). Marcar el estado 0x00000000 como t0 y, luego, medir el tiempo transcurrido desde el estado THERMAL_STATUS_NONE hasta el estado THERMAL_STATUS_LIGHT como t1 permite que los fabricantes de dispositivos diseñen y prueben estrategias de mitigación para casos de uso específicos. En la siguiente tabla, se describen las formas sugeridas de usar los códigos de estado térmico:
| Código de estado térmico | Descripción y uso sugerido |
|---|---|
THERMAL_STATUS_NONE (0x00000000) |
Sin restricciones Usa este estado para implementar acciones de protección, como detectar el inicio del período (t0 a t1) desde THERMAL_STATUS_NONE (0) hasta THERMAL_STATUS_LIGHT (1). |
THERMAL_STATUS_LIGHT (0x00000001) |
Limitación leve, no se ve afectada la UX. Usa una mitigación suave del dispositivo para esta etapa. Por ejemplo, omite el aumento o el uso de frecuencias ineficientes, pero solo en los núcleos grandes. |
THERMAL_STATUS_MODERATE (0x00000002) |
Limitación moderada, la UX no se ve muy afectada. La mitigación térmica afecta las actividades en primer plano, por lo que las apps deben reducir la energía de inmediato. |
THERMAL_STATUS_SEVERE (0x00000003) |
Limitación grave; la UX se ve muy afectada. En esta etapa, la mitigación térmica del dispositivo debería limitar la capacidad del sistema. Este estado puede causar efectos secundarios, como tirones en la pantalla y fluctuaciones de audio. |
THERMAL_STATUS_CRITICAL (0x00000004) |
La plataforma hizo todo lo posible para reducir el consumo de energía. El software de mitigación térmica del dispositivo colocó todos los componentes para que funcionen a su capacidad más baja. |
THERMAL_STATUS_EMERGENCY (0x00000005) |
Los componentes clave de la plataforma se apagan debido a las condiciones térmicas, y la funcionalidad del dispositivo es limitada. Este código de estado representa la última advertencia antes de que se apague el dispositivo. En este estado, algunas funciones, como el módem y los datos celulares, se desactivan por completo. |
THERMAL_STATUS_SHUTDOWN (0x00000006) |
Cerrar de inmediato Debido a la gravedad de esta etapa, es posible que las apps no puedan recibir esta notificación. |
Los fabricantes de dispositivos deben aprobar la prueba de VTS para el HAL térmico y pueden usar emul_temp desde la interfaz kernel sysfs para simular cambios de temperatura.