Bug critique dans Android 17 : les développeurs désassemblent le code faute d'accès aux sources
Sommaire
En bref
- Un bug dans les fonctions wcscspn() et wcspbrk() d'Android 17 casse le traitement des chaînes de caractères contenant des émojis ou des caractères non-ASCII.
- Le correctif source n'est pas encore public, forçant les développeurs à désassembler la libc pour diagnostiquer le problème.
- Réal-world impact : applications comme Visual Pinball et FileSystem.MoveFolder se cassent dès qu'une chaîne contient un caractère > U+0100.
- Le retard de publication des sources AOSP s'expliquerait, selon plusieurs commentateurs, par des contraintes réglementaires (délais de mise à jour imposés en UE) poussant Google à ralentir la publication pour coordonner les partenaires OEM.
Ce que dit la source
Un bug détecté dans Android 17 (build septembre 2026) affecte wcscspn() et wcspbrk(), deux fonctions de la libc bionic pour scanner les chaînes larges. Dès qu'une chaîne contient un caractère >= U+0100 (emoji, CJK, cyrillique, grec, Latin étendu) et que l'ensemble de rejet comporte deux caractères ou plus tous < U+0100, la fonction s'arrête faussement à ce caractère non-ASCII et le signale comme un match, alors qu'il n'est pas dans l'ensemble. L'auteur, Francis Db, a dû désassembler la libc.so pour isoler le mécanisme : le code remplit une table bool de 256 octets en stack pour les caractères ASCII, puis scanne le haystack ; dès qu'il rencontre un caractère >= 0x100, il s'arrête et le rapporte comme match au lieu de continuer. Ce comportement était correct dans la version AOSP publique (juin 2026), issue d'external/llvm-libc, ce qui place la régression entre juin et septembre.
- La fonction wcscspn(L"a🚀\u0100bx\n", L"x\n") retourne 1 au lieu de 4 ; wcspbrk() hérite du bug et affecte le lexage de VBScript dans Visual Pinball (commentaires avec émoji non parsés) et les vérifications de chemins en wildcard via FileSystem.MoveFolder.
- Les tests existants dans bionic/tests/wchar_test.cpp ne couvrent que l'ASCII, laissant passer le bug ; un test élémentaire aurait suffi : EXPECT_EQ(3u, wcscspn(L"aĀb\n", L"x\n"))
- Le code embarqué diffère du code source public (juin 2026 vs. septembre 2026) : AOSP est trop à la traîne, suggérant que les binaires livrés dans les ROM proviennent de branches privées ou en cours de correction.
- Les appareils testés (Pixel 7, Pixel 8a, Nothing Phone 2) avec les builds septembre 2026 sont affectés ; le commit de correction n'est toujours pas visible dans android-latest-release au moment du rapport.
Dans les commentaires
Débat partisé entre reconnaissance technique du bug et critique institutionnelle du retard AOSP, sans consensus sur les causes ou les solutions.
- Plusieurs commentateurs invoquent un effet de bord réglementaire : une hypothèse non confirmée selon laquelle les règles UE de cycle de mise à jour auraient incité Google à retarder la publication AOSP pour coordonner les partenaires OEM. Une interprétation de la directive à « compter depuis la publication du code source ».
- Un commentateur souligne que le titre est hyperbolique : le désassemblage était une étape de diagnostic supplémentaire, pas une nécessité absolue pour rapporter le bug.
- Plusieurs demandent des alternatives à Android (SalfishOS, Ubuntu Touch, Nura/PostmarketOS) ou spéculent que l'IA décompilera désormais les binaires de toute façon, rendant le débat sur l'open source moins pertinent.
- Critique du NDK en général : l'un des répondants estime que le NDK fonctionne comme un projet interne peu financé (« 20% project ») avec probablement ~2 équivalents temps plein, stagnant depuis Android 2.1.
Notre lecture
Le bug lui-même est technique et reproductible, affectant des cas d'usage réels avec des émojis et des caractères non-ASCII. Mais l'enjeu qui émerge du fil HN dépasse la correction : c'est le retard systématique de publication des sources AOSP qui rend l'open source inefficace. Les développeurs ne peuvent ni vérifier ni corriger en amont, ni même diagnostiquer sans reverse engineering. Si la spéculation sur les contraintes UE a du poids, elle reste anecdotique face au fait brut : l'open source perd son intérêt quand le code public est toujours à la traîne du code embarqué. Pour les équipes Android NDK, à surveiller (la correction sera backportée), mais plus largement un symptôme d'une fragmentation volontaire ou accidentelle entre AOSP public et ROM commerciales.