Google's Bionic libc — the C standard library underpinning every Android app — shipped a regression in September 2026 Android 17 builds that silently corrupts wide-string scanning for any text containing characters above U+00FF. The functions wcscspn() and wcspbrk(), used to search wide strings for delimiter characters, incorrectly report a match whenever they encounter emoji, CJK, Cyrillic, Greek, or Latin Extended characters while scanning against an ASCII-only reject set. The bug affects 1,111,808 of the 1,112,064 valid Unicode code points. The mechanism is a classic fast-path optimization gone wrong. When the reject set contains two or more characters all below U+0100, the implementation builds a 256-byte boolean lookup table on the stack — a standard trick to avoid O(n×m) scanning. The haystack loop checks each character against this table. But when it encounters a character >= U+0100, which by definition cannot be in the table, the code branches to the stop-and-report path instead of continuing the scan. The complement function wcsspn() has the same structure but happens to produce correct results because stopping on an out-of-set character is the right answer for a span function. Only the complement functions break. The regression was introduced between the June 2026 public android17-release sources (android-17.0.0r1), which use a correct plain nested loop from external/llvm-libc, and the September CP3A.260905.009 builds that ship the optimized-but-broken table lookup. The bug is confirmed on Pixel 7 and Pixel 8a running September builds; a Nothing Phone 2 on Android 16 is unaffected. The filer provides full disassembly of the shipped libc.so with the exact instruction sequence — ldrb, tbnz, ldr, cmp, b.lo — annotated to show where the logic fails. The real-world impact is immediate and specific. Visual Pinball on Android, which uses a Unix build of Wine's VBScript engine, stopped loading any table whose VBScript source contains a comment with an emoji. The VBScript lexer calls wcspbrk(ptr, L"\n\r") to skip comments and got the position of the first emoji instead of the line end. FileSystem.MoveFolder treated every path containing a character >= U+0100 as a wildcard pattern. Both were worked around downstream by replacing the libc calls with plain loops. The existing Bionic test suite for wcspbrk uses only ASCII input, which is why the regression passed CI. The filer provides a specific test case — EXPECTEQ(3u, wcscspn(L"aĀb\n", L"x\n")) — that would catch it. A full sweep of every code point from U+0001 to U+10FFFF confirms the boundary: U+0001 through U+00FF are correct, U+0100 through U+10FFFF are broken. This is a textbook case of an optimization that works perfectly on the test inputs that existed and fails catastrophically on the inputs that matter in 2026. The world's strings are not ASCII. The fact that a 256-byte table optimization — a technique from the 1990s — can ship in a platform used by billions of devices without a single non-ASCII test case in the validation suite is the structural story here. The fix is trivial (continue scanning instead of stopping when the character exceeds the table range), but the gap in test coverage that allowed it to ship is not.
