AOSP phát hành mã nguồn quá muộn, lập trình viên phải dịch ngược thư viện để báo lỗi

Công nghệ14 tháng 10, 2026·4 phút đọc

Một lỗi trong thư viện bionic của Android 17 khiến các hàm wcscspn() và wcspbrk() xử lý sai mọi ký tự wchar_t từ U+0100 trở lên. Do mã nguồn AOSP không được công bố kịp thời, lập trình viên phải dịch ngược tệp libc.so để tìm ra nguyên nhân gốc rễ.

AOSP phát hành mã nguồn quá muộn, lập trình viên phải dịch ngược thư viện để báo lỗi

Google đang đối mặt với làn sóng chỉ trích từ cộng đồng mã nguồn mở sau khi việc phát hành mã nguồn AOSP bị trì hoãn quá lâu. Hệ quả trực tiếp là các lập trình viên buộc phải dịch ngược (disassemble) các thư viện đã biên dịch để tìm ra nguyên nhân lỗi, thay vì đọc mã nguồn như thông thường.

Lỗi trong thư viện bionic của Android 17

Vấn đề được ghi nhận trên các bản dựng Android 17 từ tháng 9 năm 2026. Hai hàm xử lý chuỗi ký tự rộng là wcscspn() và wcspbrk() hoạt động sai khi tập ký tự loại trừ (reject set) chứa từ hai ký tự trở lên.

Cụ thể, hàm sẽ dừng lại ngay tại ký tự đầu tiên có mã điểm lớn hơn hoặc bằng U+0100, bất kể ký tự đó có thực sự nằm trong tập loại trừ hay không. Kết quả là các chuỗi chứa emoji hoặc ký tự Unicode ngoài Latin cơ bản đều bị xử lý sai.

Theo báo cáo, có tới 1.111.808 mã điểm từ U+0100 đến U+10FFFF đều bị ảnh hưởng. Chỉ dải U+0001 đến U+00FF hoạt động chính xác.

Dịch ngược để tìm nguyên nhân gốc rễ

Điểm đáng chú ý nhất của sự việc là cách lập trình viên phát hiện ra lỗi. Vì mã nguồn AOSP chưa được công bố cho bản dựng này, họ đã phải dịch ngược tệp libc.so trong thư mục /apex/com.android.runtime/lib64/bionic/ để phân tích.

Quá trình phân tích cho thấy hàm wcscspn sử dụng ba nhánh xử lý khác nhau tùy theo tập ký tự:

  • Một ký tự: dùng vòng lặp so sánh đơn giản, hoạt động đúng.
  • Từ hai ký tự trở lên: tạo bảng tra cứu 256 byte trên stack, hoạt động đúng.
  • Trường hợp còn lại: quét haystack dựa trên bảng, nhưng gặp lỗi logic khi mã điểm vượt quá 0xFF.

Đoạn assembly cho thấy lệnh so sánh cmp w8, #0x100 kết hợp với nhảy có điều kiện b.lo đã vô tình coi mọi ký tự từ 0x100 trở lên là kết quả khớp, trong khi thực tế chúng không thể nằm trong tập loại trừ chỉ chứa các ký tự dưới 0x100.

Phản hồi từ đội ngũ phát triển

Kỹ sư của Google đã xác nhận lỗi và thừa nhận một điều đáng xấu hổ hơn: bài kiểm thử hiện có cho wcscspn() vốn đã sai từ trước. Kết quả kiểm thử trả về 3 thay vì giá trị mong đợi là 2, nhưng vẫn tồn tại trong mã nguồn mà không bị phát hiện.

Đại diện Google cho biết sẽ bổ sung các bài kiểm thử còn thiếu, đặc biệt là những bài có sử dụng ký tự không phải ASCII, và sẽ cố gắng đưa bản vá trở lại các phiên bản cũ để giảm số lượng thiết bị bị ảnh hưởng.

"Thành thật xin lỗi nếu nghe có vẻ bi kịch, vì thực tế không đến mức đó. Tôi chỉ lo lắng. Có gì đó không ổn với chuyện này..." — một thành viên cộng đồng bình luận.

Lo ngại về tính minh bạch của AOSP

Sự việc làm dấy lên lo ngại rộng hơn về cách Google quản lý dự án AOSP. Nhiều lập trình viên phản ánh rằng kể từ khi Google thắt chặt việc công bố mã nguồn, các lỗi ngày càng nhiều mà không có bản vá, và thiếu hoàn toàn sự minh bạch từ phía tập đoàn.

Một điểm tranh cãi cụ thể: nhánh android17-release đã có mã nguồn, nhưng nhánh Android 17 QPR1 — phiên bản thực sự chạy trên Pixel và đã ổn định hơn một tháng — vẫn chưa được công bố mã nguồn.

Đối với người dùng Việt Nam, đây là vấn đề đáng quan tâm vì mọi thiết bị Android đều bị ảnh hưởng, từ điện thoại đến máy tính bảng. Các ứng dụng xử lý chuỗi Unicode — bao gồm ứng dụng nhắn tin, mạng xã hội và công cụ soạn thảo tiếng Việt có sử dụng emoji — đều có thể gặp lỗi hiển thị hoặc xử lý sai ký tự.

Sự việc này cũng là lời nhắc nhở về giá trị của mã nguồn mở trong việc kiểm toán và sửa lỗi phần mềm. Khi quy trình đó bị thu hẹp, cả cộng đồng lẫn nhà sản xuất đều chịu thiệt.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗