En parcourant les forums et les sites, j'ai trouvé les réponses suivantes à mes doutes. Je ne suis pas entièrement satisfait mais cela m'a aidé à mieux comprendre.
La gestion de l'alimentation de chaque appareil dépend de certains suspend / resume qui sont mises en œuvre dans le micrologiciel contrôlant ce dispositif particulier.
Cela dépend beaucoup du périphérique : comment et quand chaque périphérique s'éteint (se suspend) et se réveille (reprend) dépend des spécifications du matériel, vous devez lire les fiches techniques pour comprendre quels registres particuliers doivent être manipulés pour le suspendre/reprendre.
Vous pouvez contrôler ces éléments par l'intermédiaire d'un logiciel dans les pilotes des périphériques, à l'intérieur du code source du noyau, en accédant à certaines fonctions de la forme suivante <something>_suspend y <something>_resume .
Par exemple, à partir du code source du noyau de l'émulateur "goldfish" :
dans le fichier drivers/video/goldfishfb.c (le pilote responsable du tampon de trame)
#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
Ainsi, le early_suspend écrit un 1 dans le registre FB_SET_BLANK pour éteindre l'écran, ou un 0 pour le rallumer.
Il me semble donc qu'un processus dans l'environnement d'exécution de l'application doit accéder aux pilotes de périphériques et les corrompre pour manipuler de manière malveillante la gestion de l'alimentation d'un périphérique.
