Contrairement à ce que beaucoup pourraient penser, ce dont nous rendons compte n’est pas toujours parfait. Même si nous faisons beaucoup de choses correctement et disposons d'un excellent groupe de développeurs qui étirer continuellement les appareils en hauteur, nous mettons parfois en avant des solutions aux gains inconnus. Un article récent que nous avons publié sur un hack pour jouer sur le Nexus 7 et d'autres appareils en sont un exemple.
Le principe du hack est que vous pouvez réduire le décalage en conservant une section du système de fichiers Android (/dev/random) plein de bits aléatoires afin que le système n'ait pas à attendre que le système de fichiers les génère. En théorie, cela semble génial et cela a montré quelques succès dans certains domaines où le décalage était évident, mais il présente toutes sortes d'autres problèmes.
C'est pour ces problèmes que nous ne recommandons pas d'utiliser ce correctif. Le correctif lui-même ne cause aucun dommage et ses effets sont proches du placebo. Arcee du développeur CyanogenMod informations publiées sur le correctif, déclarant que
Les seuls utilisateurs de /dev/random sont libcrypto (utilisé pour les opérations cryptographiques comme les connexions SSL, la génération de clés ssh, etc.), wpa_supplicant/hostapd (pour générer des clés WEP/WPA en mode AP) et les bibliothèques qui génèrent des ID de partition aléatoires lorsque vous effectuez une format ext2/3/4. Aucun de ces 3 utilisateurs n'est sur le chemin de l'exécution de l'application, donc alimenter de manière aléatoire à partir d'urandom ne fait rien d'autre que rendre aléatoire... Bien... moins aléatoire
Il existe des préoccupations valables concernant le décalage et la manière dont le système d'exploitation Android les gère, et il y a discussion actuellement en cours dans le code Android à ce sujet, mais ce correctif ne résout pas ces problèmes et offre à la place des gains de performances en augmentant la vitesse du processeur. Le développeur lui-même a déclaré que cela pourrait en fait réduire la durée de vie de la batterie, puisque le hack réveille le processeur toutes les secondes.
Comme c'est toujours le cas, tout ce que vous utilisez ici sur XDA se fait à vos propres risques et vous assumez l'entière responsabilité de vos actes. Cela dit, il arrive parfois que nous transmettions des informations inexactes, et celui-ci en fait partie. Nous félicitons tous nos développeurs pour avoir travaillé pour trouver des correctifs aux problèmes qui les dérangent. Cependant, nous avons sauté le pas sur ce point, sans laisser de discussions et de tests adéquats avoir lieu.
[Image adaptée de /dev/pensées aléatoires.]