Introduction & Mythes

Quand on parle de kernels sur Android, le sujet principal des discussions de nos jours concerne l’autonomie. Mais il existe beaucoup de mythes quant à la relation entre kernel (noyau) et autonomie. D'un côté, il y a ceux qui râlent à propos de changements brutaux d’autonomie, des dizaines d’heures voir des heures de différence après avoir installé un kernel. De l'autre, on retrouve les personnes qui pensent que le kernel n’a absolument aucun impact sur l’autonomie. La vérité se trouve entre les deux.

Avant de rentrer dans le vif du sujet, il est bon de clarifier certains points.

Tout d’abord, le kernel ne provoque pas de « chute » de batterie. Très souvent, un utilisateur installe un kernel puis rapporte rapidement que le kernel a provoqué une forte baisse de l’autonomie (et aussi que le kernel est nul, que le développeur devrait se recycler, etc… ). Pour le prouver, il apporte des captures d’écran d’applications de surveillance de la batterie, montrant que « kernel » est une source majeure du problème. Ceci est très trompeur.
Sur les appareils Android, le kernel fournit un mécanisme pour garder le téléphone éveillé, c’est ce qu’on appelle un wakelock. Les processus tournant sur l’appareil (exemple : applications & services) peuvent demander au kernel  un wakelock et le kernel va lui rendre ce service. Alors oui, le kernel garde techniquement le téléphone éveillé, mais seulement à cause d’une application ou d’un service qui l’a demandé. Ce sont ces applications et services qui vous trompent et causent la perte d’autonomie, pas le kernel.

Cependant, cela ne veut pas dire que le kernel ne cause pas de perte d’autonomie. Il utilise évidemment de la mémoire et fonctionne en permanence, mais la quantité utilisée et extrêmement faible par rapport au système Android, aux applications et aux services. Il existe aussi des cas particuliers sur le hardware, comme la fonctionnalité sweep2wake sur le Nexus 5, qui fait que l’écran LCD reste allumé pour pouvoir fonctionner. Ceci sollicite davantage la batterie que lorsque l’appareil est endormi, mais on ne parle toujours pas de perte d’autonomie « brutale ». Sur le Nexus 5, sweep2wake fait perdre environ 2% par heure quand l’écran est éteint.
Pas insignifiant c’est sûr, mais ça reste très correct par rapport à la consommation d’un écran allumé.
À cause de cela, un mythe important s’est développé, affirmant que sweep2wake et doubletap2wake provoque une forte baisse de l’autonomie. Mis à part pour le Nexus 5, ceci est un mythe. Sur la grande majorité des appareils, la chute de la batterie due à sweep2wake est négligeable, entre 0 et 0.5% par heure, ce qui représente dans les 5% de consommation sur une journée de travail. Un pourcentage plus que tolérable vu le confort apporté.

Comment mesurer l’autonomie ?

Il est intéressant de regarder le pourcentage d’utilisation par heure. Beaucoup d’applications de surveillance peuvent vous donner ce chiffre, mais vous devez définir des points de passage précis si vous voulez être en mesure de comprendre l’utilisation de la batterie.
Si vous voulez mesurer et comparer, assurez-vous de le faire dans des conditions similaires et de faire l’analyse sur une période raisonnablement longue (plutôt des jours que des heures). Si vous avez des routines durant lesquelles vous utilisez les mêmes applications chaque jour, c’est un moment idéal pour faire vos tests. Le monitoring de batterie dans EX Kernel Manager fournit automatiquement les 2 données dont nous allons parler : idle drain et active drain.
(PS : c’est l’application du développeur du kernel ElementalX / Source).


Idle drain correspond à la consommation de la batterie lorsque l’écran est éteint.
Quand l’écran est coupé, le téléphone passe la plupart de son temps en « deep sleep ». Parfois, il se réveille pour effectuer des tâches d’arrière-plan, comme des synchronisations ou des vérifications de mises à jour. Ce sont des exemples pour dire que le système, les applis et les services « demandent » au kernel de rester éveillé le temps qu’ils effectuent leurs tâches. Si tout fonctionne correctement, une fois qu’ils ont fini, l’appareil retourne s’endormir. L’idle drain devrait se mesurer sur plusieurs heures pour avoir une idée pertinente de la situation. Faire cette mesure durant la nuit est une très bonne idée vu que vous ne touchez pas votre appareil.

Sur la plupart des appareils, l’idle drain est compris entre 0.2 et 0.8% par heure avec une configuration stock et les options par défaut (cad, pas de fonctions d’économie de batterie) ainsi qu’une connexion WiFi basique. Sur certains appareils, les optimisations du kernel peuvent réduire ce chiffre.  On peut obtenir du 0.1% ~ 0.3% d’amélioration par rapport au stock. Ceci ne fera pas une grosse différence sur l’autonomie.
Comme déjà expliqué, il arrive que des fonctionnalités matérielles comme sweep2wake fassent doubler la consommation. Ainsi, le kernel offre peu d’amélioration dans ce cas, mais chaque partie compte.

Un autre facteur qui influence l’idle drain c’est votre connexion réseau, et notamment la connexion cellulaire. Un signal faible provoquera inévitablement une consommation supplémentaire. Cependant, ça ne devrait pas générer une consommation très excessive dans cette phase de sommeil. Vous sentirez surtout la différence lors de l’utilisation de connexion de données mobiles.
En général, si votre idle drain est en-dessous de 1% par heure, ne vous en préoccupez pas.  Dans le cas contraire, jetez un œil à vos applications et services. Parfois, une grosse vague de mises à jour peut provoquer une consommation excessive, ça arrive.


Active drain représente la quantité de batterie utilisée quand l’écran est allumé, quand vous utilisez votre appareil. L’active drain est forcément plus important que l’idle drain. Le téléphone est allumé, l’écran aussi, et il travaille via le CPU, GPU, la mémoire, le modem, le WiFi, etc… L’active drain varie pas mal d’un appareil à l’autre.

Très souvent, on voit des statistiques de SOT (Screen On Time). L’active drain, mesuré en % par heure peut facilement être traduit en SOT. Un active drain de 12.5% par heure est très bien et correspondra à environ 8 de SOT. Une consommation de 25% par heure donnera un 4h de SOT environ.
Comment ça marche ?

Screen On Time (heures) = 100 / Active drain (% par heure).

Ceci ne prend en compte la faible quantité de batterie utilisée lorsque l’écran est éteint. Partant du principe que l’idle drain est de 0.6%, vous perdez dans les 6% toutes les 10h, ou environ 14% toutes les 24h.  Vous pouvez déduire cela de l’équation ci-dessus.

Les symptômes de l'active drain

Maintenant, on passe à la vérité du problème de base. Qu’est-ce qui influence l’active drain ? Beaucoup de choses.
La connexion réseau (notamment la cellulaire) a un fort impact. Un signal faible signifie qu’il travaille plus dur pour transmettre et recevoir des données.
Le type d’applications joue aussi. Évidemment, jouer à un jeu avec des rendus graphiques élevés utilisera beaucoup plus de batterie que la lecture d’un e-mail. Utiliser l’appareil photo, notamment avec le flash, consommera davantage que l’envoi de SMS.
En clair, ce que vous faites avec votre appareil est la source numéro 1 de l’autonomie. Changer votre navigateur web peut avoir un impact significatif sur votre autonomie, peut-être même supérieur à n’importe quel kernel ou bidouille d’économie d’énergie.
Enfin, l’active drain varie d’un utilisateur à l’autre, même avec le même appareil !

Le rôle du Gouverneur CPU

Il y a, cependant, une partie du kernel qui joue un rôle important sur l’active drain, et donc qui peut avoir un impact majeur sur le temps de SOT. C’est le Gouverneur CPU. C’est pourquoi les développeurs de kernel passent beaucoup de temps à optimiser les gouverneurs.  Ça concerne l’utilisation des fréquences, que vous pouvez mesure via une application comme CPU Times.
Le Gouverneur CPU contrôle la graduation des fréquences selon la charge du système. Quand il n’est pas occupé, le CPU va rester à sa fréquence la plus basse, ce qui utilise le moins d’énergie possible. Quand il y a du travail à faire, le gouverneur CPU accroît la fréquence pour que le travail soit effectué plus rapidement et pour que l’utilisateur ait une expérience fluide. Un bon gouverneur est réactif, répond rapidement aux changements de la charge système, pour empêcher les lags, mais aussi pour retourner le plus vite possible à la fréquence la plus basse afin d’économiser de l’énergie.

Il existe une idée appellée « race to idle » qui exprime le fait que le gouverneur doive immédiatement passer à la fréquence la plus élevée pour que les tâches soient effectuées aussi vite que possible, et par conséquent, le CPU peut plus rapidement retourner dans un état de faible consommation. Cette logique est globalement sensée, mais avec les processeurs modernes, il peut y avoir une différence de temps non négligeable pour effectuer une tâche en utilisant la plus haute fréquence disponible par rapport à une fréquence moyenne. Autrement dit, ça peut être une perte d’énergie inutile de passer à la fréquence la plus élevée quand une fréquence inférieure peut effectuer la tâche dans un laps de temps identique.
La fréquence la plus élevée utilisera plus d’énergie qu’une fréquence moyenne, et cela peut générer un impact significatif sur l’autonomie, sachant qu’on parle de milliers ou de millions de répétitions par jour. Le truc c’est de trouver des fréquences qui sont assez rapides pour ressentir de bonnes sensations, sans pour autant passer sur la fréquence la plus haute.
Il est clair que les gouverneurs agissent différemment et ont un impact sur la batterie.

Autres éléments impactant l'autonomie

D’autres aspects du kernel impactent l’autonomie. Le plus important d’entre eux est la planification de tâches, notamment quand des tâches sont assignées à un cœur CPU ou un autre. Cela veut dire qu’un CPU peut être « réveillé » pour effectuer une tâche, ou des tâches peuvent être regroupées sur le même cœur.

Un autre est le hotplugging. Il y a un coût d’énergie à mettre en ligne ou hors ligne les cœurs CPU. Sur la plupart des appareils, vous entendez parler des démons du mpdecision, un binaire closed-source de Qualcomm qui contrôle le hotplugging et qui inclut souvent une fonctionnalité « touchboost » qui outrepasse le gouverneur CPU. Beaucoup de kernels custom désactive le mpdecision et implémente leur driver hotplugging personnalisé.
Le développeur du kernel ElementalX a tiré ses propres conclusions : mpdecision et son touchboost excessif n’ont pas d’impact majeur sur l’autonomie donc il les a laissé activé par défaut sur ses kernels.
Sur certains appareils récents, comme le Nexus 6 ou le HTC One M9, il n’y a pas de hotplugging lors d’une utilisation normale. Tous les cœurs CPU sont actifs.

Même si la planification de tâches, le hotplugging ou le touchboost ont un impact sur l’autonomie, cela reste faible. Si on parle en termes d’active drain (% par heure), le changement sera très faible, probablement moins de 1% par heure, ce qui peut être mesuré en minutes de SOT sur une journée.
Ces modifications devraient avoir une plus grande importance sur les anciens appareils qui ont des batteries moindres et une efficacité énergétique inférieure.


Parlons maintenant d’une notion qui revient dans les sujets d’autonomie : l’undervolting. Encore une fois, l’undervolting a un réel intérêt sur les anciens appareils. Les appareils sortis depuis 2014 ne sont pas concernés. Certains disposent même d’optimisations par défaut et d’une graduation automatique des voltages.
Les appareils msm8960 seront sensibles à l’undervolting vu qu’ils utilisent le même voltage pour chaque fréquence CPU.

Conclusion

D’autres éléments pourraient être apportés à cette discussion mais le développeur souhaitait pointer du doigt le fait que le kernel a bel et bien un impact sur l’autonomie, même si la différence n’est souvent pas flagrante. Côté kernel, le gouverneur CPU aura le plus gros impact sur l’autonomie. La majorité des choses soulevées par des utilisateurs ne changeront pas bien la donne.
Enfin, si vous voulez juger l’autonomie de votre appareil Android, optez pour une approche scientifique. Essayez de rester dans les mêmes conditions lors de vos comparaisons, mesurer avec précaution et laissez-vous du temps.
Mettez-vous dans la peau du développeur qui a travaillé des jours, des semaines et des mois sur son kernel. Il mérite un effort minimum d’analyse, non ?

Réservé

Merci pour le partage

Super article, merci

Content que ça serve

Merci pour ces bonnes infos

WooooW, on va se faire un guide ha ouiiii, franchement !!!!

Bien joué encore une fois