Googlebook OS chạy được trên Mac: đáng thử ứng dụng, chưa nên dùng tài khoản chính

Chạy được Googlebook OS trên Mac mở ra một cách tiếp cận hệ điều hành mới mà không phải mua thêm laptop. Nhưng mục tiêu hợp lý của gbos-vm là một môi trường thử nghiệm. Giao diện xuất hiện trong cửa sổ máy ảo không có nghĩa toàn bộ cơ chế bảo mật và khả năng tích hợp của Googlebook cũng đã được chuyển sang macOS.

Dự án mã nguồn mở của Skylar Taylor dùng bản recovery do Google phân phối, thay các thành phần phụ thuộc phần cứng rồi khởi động bằng QEMU. Điểm có ích nhất với người đã dùng Mac là kiểm tra ứng dụng Android trong môi trường desktop Googlebook. Đánh đổi nằm ở lớp hệ thống bên dưới, nơi một số thành phần vốn dựa vào phần cứng chuyên dụng phải được thay bằng thiết bị ảo.

Chạy cùng kiến trúc ARM chưa giải quyết được đồ họa

Phần khó của gbos-vm nằm ở việc khiến các thành phần đồ họa phối hợp trên macOS, chứ không đơn thuần khởi động một hệ điều hành ARM. Mac Apple Silicon và bản Googlebook OS được chọn cùng dùng ARM64, nên hệ điều hành khách có thể chạy qua hypervisor thay vì phải giả lập toàn bộ kiến trúc CPU. Cách làm này cũng giải thích vì sao Mac Intel không nằm trong phạm vi hỗ trợ của dự án.

Theo tài liệu gbos-vm, bản recovery được lấy cho Dell Googlebook chạy Android 17. Các phân vùng system được giữ nguyên; phân vùng vendor được dựng lại bằng thành phần thiết bị ảo từ Android Cuttlefish. Vendor là nơi chứa nhiều phần phụ thuộc vào phần cứng cụ thể. Một image dành cho laptop Dell không thể tự nhận ra GPU và các thiết bị mà QEMU cung cấp nếu chỉ đem khởi động nguyên trạng.

Ở đường xử lý đồ họa, Vulkan được chuyển sang Metal trên máy Mac. Vấn đề tiếp theo là Android có thể đưa cùng một bộ đệm hình ảnh cho cả OpenGL ES và Vulkan. Trên Linux, dma-buf phục vụ việc chia sẻ kiểu này; macOS không có cùng cơ chế. gbos-vm dùng vùng nhớ chia sẻ POSIX làm nền cho bộ đệm, rồi đưa bộ đệm đó vào cả Metal và MoltenVK.

Điều này quan trọng vì một ứng dụng và hệ thống hiển thị có thể dùng những API khác nhau. Chỉ làm một API hoạt động chưa đủ nếu hai bên không đọc được cùng dữ liệu hình ảnh. Giải pháp chia sẻ bộ đệm xử lý đúng điểm nối đó, giúp đường đồ họa ảo phục vụ giao diện desktop thay vì chỉ có một màn hình khởi động.

Còn một khác biệt ở cách bố trí hàng pixel: tài liệu dự án nêu Metal cần căn hàng texture theo bội số 16 byte. Bộ nhớ liên quan nằm ở phía Mac, nên máy chủ có thể điều chỉnh bước hàng mà không buộc hệ điều hành khách biết cách Metal bố trí dữ liệu. Đây là ví dụ rõ về việc phần mềm phải xử lý khác biệt giữa hai nền tảng dù CPU cùng kiến trúc.

Tăng tốc GPU vẫn chưa đồng nghĩa tương thích đồ họa hoàn chỉnh. Tài liệu gbos-vm ghi màn hình khách bị giới hạn ở 60 fps. Chrome còn cần một phần mở rộng Vulkan mà MoltenVK chưa có; giải pháp hiện tại có thể làm nội dung WebGL sử dụng flat interpolation chọn sai đỉnh. Vì vậy, một ứng dụng mở được và cuộn được chưa đủ để kết luận phần hiển thị của nó đúng trong mọi trường hợp.

Bản recovery chính thức không khiến máy ảo có bảo mật như máy thật

Không nên đăng nhập tài khoản chính vào môi trường này chỉ vì image xuất phát từ Google. Nguồn gốc bản tải về và tính toàn vẹn của hệ thống sau khi sửa là hai vấn đề khác nhau. Dự án không liên kết với Google hoặc Dell, và máy ảo không phải Googlebook đã được xác minh.

Googlebook OS trông đợi các thành phần mà máy ảo không cung cấp, gồm TPM, Trusty và phần cứng đặc thù khác. gbos-vm thay KeyMint và Gatekeeper dựa trên phần cứng bằng phiên bản phần mềm của Cuttlefish. Hệ quả trực tiếp là khóa trong máy ảo không có phần tử bảo mật chuyên dụng bảo vệ như cấu hình phần cứng mà hệ điều hành vốn trông đợi.

Phân vùng vendor đã sửa cũng không còn Verified Boot. Các phân vùng khác giữ cơ chế verity nguyên bản, còn SELinux vẫn ở chế độ enforcing với ba quy tắc bổ sung cho việc chia sẻ bộ đệm đồ họa, theo tài liệu dự án. Vì thế, nói toàn bộ bảo mật đã bị tắt là sai; nói bản máy ảo có cùng mức bảo đảm với Googlebook thật cũng sai. Phần cần chú ý là ranh giới tin cậy đã thay đổi ở chính lớp được chỉnh để hệ điều hành khởi động.

Công cụ đồng bộ con trỏ và clipboard còn tạo thêm đường trao đổi giữa máy chủ và máy khách. Thiết kế hiện tại dùng token ngẫu nhiên mỗi lần khởi động để nhận diện máy chủ. Cơ chế đó có ích, nhưng không biến một bản thử nghiệm thành môi trường thích hợp cho tài khoản doanh nghiệp hoặc dữ liệu nhạy cảm.

Nếu muốn khảo sát hệ điều hành, nên dùng tài khoản thử nghiệm tách biệt và chỉ đưa vào dữ liệu có thể bỏ đi. Đồng thời, vẫn phải kiểm tra script trước khi chạy trên Mac: quá trình cài sẽ tải thành phần, biên dịch phần mềm và có thể bổ sung gói Homebrew. Script không yêu cầu sudo không có nghĩa nó không thay đổi môi trường của người dùng.

Chuẩn bị dung lượng và chấp nhận lỗi trước khi cài

gbos-vm phù hợp hơn với người quen công cụ phát triển so với người chỉ muốn mở một ứng dụng Android. Cài đặt gồm tải image, dựng renderer và viewer trên máy chủ, biên dịch thành phần Android rồi lắp image khởi động. Dung lượng tải xuống vì thế không phản ánh toàn bộ không gian cần cho thư mục làm việc và kết quả biên dịch.

Hạng mục	Yêu cầu hoặc tình trạng của gbos-vm
Máy chủ	Mac Apple Silicon; không hỗ trợ Mac Intel
RAM thực tế được khuyến nghị	16 GB; máy ảo mặc định nhận 4 GB
Dung lượng trống	Khoảng 60 GB
Dữ liệu tải về	Khoảng 9 GB
Công cụ phát triển	Xcode Command Line Tools, Homebrew, Android SDK/NDK và JDK
Android SDK	Có build-tools và platform API 34 trở lên
Cấu hình tác giả dùng để kiểm tra	MacBook M5, RAM 16 GB, macOS 27
Thời gian được tác giả ghi nhận trên MacBook M5	Khoảng 5 phút cho phần build; khởi động lần đầu khoảng 45 giây, không tính thời gian tải

Số liệu: tài liệu gbos-vm trên GitHub.

Những mốc thời gian này chỉ phản ánh cấu hình tác giả dùng, không phải cam kết cho mọi máy Apple Silicon. Dự án có báo cáo chạy được trên M4, nhưng phạm vi kiểm tra trực tiếp vẫn hẹp. Người dùng Mac đời khác cần xem việc cài thành công là điều phải xác nhận, không phải điều đã được bảo đảm.

Quy trình cài được dự án cung cấp qua install.sh sau khi tải repository. Khi hoàn tất, ứng dụng Googlebook VM.app trong work/host dùng để mở máy ảo và tắt Android khi thoát. Dữ liệu máy khách nằm trong file work/image/googlebook.raw, tồn tại giữa các lần chạy. Đây là điểm cần nhớ khi muốn xóa sạch môi trường thử: đóng cửa sổ không xóa dữ liệu đã nhập.

Lỗi hiện tại ảnh hưởng cả thao tác thường ngày. Bluetooth báo lỗi khi khởi động; tiến trình TPM lặp lại việc bị lỗi và có thể tiêu tốn CPU. Âm thanh từng không hoạt động ở một lần khởi động. Sao chép từ máy khách ra ngoài, nhấp chuột phải và phiên sử dụng dài chưa được kiểm tra đầy đủ. Những hạn chế đó khiến việc dùng máy ảo như máy tính chính thiếu cơ sở, ngay cả khi Chrome đã mở được.

Con trỏ cũng có đánh đổi. Chế độ bắt chuột là lựa chọn đáng tin cậy hơn hiện tại, còn chế độ tích hợp cho phép đi ra vào cửa sổ tự do vẫn được đánh dấu thử nghiệm. Nếu đang kiểm tra giao diện ứng dụng, cần tách lỗi thao tác do máy ảo khỏi lỗi của ứng dụng để tránh sửa nhầm phần mềm vốn hoạt động đúng trên thiết bị thật.

Nhà phát triển tại Việt Nam nên dùng để khảo sát, không thay thiết bị kiểm thử

Giá trị thiết thực của bản máy ảo là hạ rào cản tiếp cận giao diện desktop Googlebook cho người đã có Mac. Một ứng dụng Android vốn thiết kế cho màn hình điện thoại cần được xem lại khi cửa sổ thay đổi kích thước, có bàn phím và dùng con trỏ. Môi trường này có thể hỗ trợ phát hiện sớm bố cục bất tiện hoặc luồng thao tác không hợp với desktop.

Google thiết kế Googlebook trên nền Android, kết hợp nền tảng desktop từ ChromeOS và khả năng làm việc cùng điện thoại Android. Dòng laptop ban đầu gồm Acer, ASUS, Dell, HP và Lenovo. Tuy nhiên, xem giao diện trong VM không xác nhận đầy đủ việc kết nối điện thoại, tính năng AI hoặc hành vi phần cứng trên các máy thương mại. Bản ảo nên đứng ở đầu quá trình khảo sát, còn kiểm thử phát hành vẫn cần thiết bị và cấu hình mục tiêu.

Với nhóm phát triển tại Việt Nam đang dùng Mac làm máy làm việc, cách tiếp cận này giúp quyết định xem có đáng đầu tư thiết bị Googlebook riêng hay không. Có thể bắt đầu bằng dữ liệu mẫu, kiểm tra cửa sổ và điều hướng, rồi ghi lại lỗi cùng cấu hình VM để đối chiếu trên máy thật. Không nên dùng kết quả từ VM để quảng cáo hiệu năng, thời lượng pin hay mức an toàn của sản phẩm Googlebook.

Người chỉ muốn dùng ứng dụng Android hằng ngày có ít lý do hơn để chấp nhận việc biên dịch cùng các lỗi còn lại. Nếu không cần khảo sát Googlebook OS, không nên dành hàng chục GB ổ đĩa và đưa tài khoản quan trọng vào một môi trường phát triển chỉ để thử tính mới. Còn với nhà phát triển, đây là công cụ đáng quan tâm chính vì nó cho phép nhìn thấy hệ điều hành trên chiếc Mac đang có, miễn là giữ rõ giới hạn của phép thử.

Nguồn tham khảo: gbos-vm trên GitHub, Google Blog, CNET, Android Authority