Navegando por foros y sitios encontré las siguientes respuestas a mis dudas. No estoy completamente satisfecho pero me ayudó a entender más.
La gestión de la energía de cada dispositivo depende de algunos suspend / resume políticas que se implementan en el firmware que controla ese dispositivo en particular.
Esto es muy dependiente del dispositivo: cómo y cuándo cada dispositivo se apaga (se suspende) y se despierta (se reanuda) depende de las especificaciones del HW, hay que leer las hojas de datos para entender qué registros particulares deben ser manipulados para suspenderlo/reanudarlo.
Puedes controlar estas cosas a través del software de los drivers de los dispositivos, dentro del código fuente del kernel, accediendo a algunas funciones de la forma <something>_suspend y <something>_resume .
Por ejemplo, del código fuente del núcleo del emulador "goldfish":
en el archivo drivers/video/goldfishfb.c (el controlador responsable de la memoria intermedia de la trama)
#ifdef CONFIG_ANDROID_POWER
static void goldfish_fb_early_suspend(android_early_suspend_t *h)
{
struct goldfish_fb *fb = container_of(h, struct goldfish_fb, early_suspend);
writel(1, fb->reg_base + FB_SET_BLANK);
}
static void goldfish_fb_late_resume(android_early_suspend_t *h)
{
struct goldfish_fb *fb = container_of(h, struct goldfish_fb, early_suspend);
writel(0, fb->reg_base + FB_SET_BLANK);
}
#endif
Así que el early_suspend escribe un 1 en el registro FB_SET_BLANK para apagar la pantalla, o un 0 para volver a encenderla.
Así que me parece que un proceso en el entorno de ejecución de la aplicación necesita acceder y corromper los drivers de los dispositivos para manipular maliciosamente la gestión de la energía de un dispositivo.
