AOSP Source Releases Are So Late Developers Disassemble Libraries to Report Bugs
- ID
- 35348
- Status
- summarized
- Published
- 14 Oct 2026, 2:18 PM
- Fetched
- 14 Oct 2026, 9:59 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://github.com/android/ndk/issues/2260
- Source URL
- https://hnrss.org/best
Summary
- Score
- 6.0
- Created
- 14 Oct 2026, 10:00 PM
- Tags
- Audience
- developers
What happened
A bug report filed against android/ndk (issue #2260) documents that on Android 17 builds from September 2026 (CP3A.260905.009), bionic's wcscspn() and wcspbrk() treat every wchar_t >= U+0100 as a match whenever the reject set has two or more characters all below U+0100 — a sweep found 1,111,808 code points (U+0100 to U+10FFFF) affected, while wcsspn(), wcschr(), wcsrchr(), wmemchr() and wcsstr() remain correct. The reporter reproduces it on Pixel 7 and Pixel 8a running that build, but not on a Nothing Phone 2 still on Android 16, and notes the June 2026 android-17.0.0_r1 sources build these functions correctly from external/llvm-libc, so the regression landed between the June and September releases. The HN thread (360 points, 165 comments) focuses on the fact that developers had to disassemble the shipped libraries to characterise the bug because the matching AOSP source release was not available.
Why it matters
If you ship Android code via the NDK that scans wide strings for ASCII delimiters — newline, wildcards, separators — any string containing emoji, CJK, Cyrillic, Greek or Latin Extended characters will silently mis-scan on that specific September 2026 Android 17 build, and the failure is a wrong index, not a crash, so it will look like a logic bug in your app. Concretely: test wcscspn/wcspbrk against emoji input on a Pixel 7 or 8a on CP3A.260905.009, and if it misbehaves, work around it rather than waiting, since the June sources you can read are correct and therefore won't explain the shipped behaviour. Anyone relying on reading AOSP source to debug a platform-level regression should note the gap between binary release and source release demonstrated here.
Discussion angle
When the shipped platform binary diverges from the published AOSP sources — as it did between the June android-17.0.0_r1 drop and the September CP3A.260905.009 build — how do you debug at all? Is disassembling bionic a reasonable expectation for app developers, and what should the release process guarantee instead?