Bài toán porting (chuyển đổi) Android là một chủ đề rất rộng, bao gồm nhiều mảng kiến thức liên kết chặt chẽ với nhau. Bài viết này sẽ phân tích về một thành phần nền tảng: hệ thống phân vùng (partition) của Android.
Trong quá trình porting, lập trình viên (developer) cần phải hiểu rất rõ về cấu trúc các phân vùng: Từng phân vùng có chức năng gì, bên trong chứa những gì, và chúng được build (xây dựng) từ đâu.
Một ví dụ thực tế: Khi porting Android, hệ thống có thể bị treo ở tiến trình init. Khi kiểm tra, nguyên nhân có thể là do phân vùng system_a bị thiếu một số file service quan trọng, khiến init không thể tải và khởi động chúng, dẫn đến treo hệ thống.
1. So sánh với Linux và Cấu trúc Phân vùng Android
Nếu một hệ thống Linux nhúng truyền thống chỉ cần 1 hoặc 2 phân vùng (một chứa kernel/device tree và một chứa root file system), thì hệ thống phân vùng của Android phức tạp hơn nhiều, thường có khoảng 9 – 10 phân vùng chính (chưa tính các phân vùng dự phòng cho cơ chế A/B update).
Thứ tự và chức năng của các phân vùng chính như sau:
- U-Boot: U-Boot (hoặc bootloader) không được ghi vào một phân vùng riêng biệt. Thông thường, nó được ghi vào vùng đầu tiên của thiết bị lưu trữ (ví dụ: eMMC hoặc SDCard). Khi hệ thống khởi động, ROM code của SoC sẽ đọc và thực thi U-Boot từ vùng này.
- boot_a: Phân vùng này chứa file
boot.img. Trên Android 8,boot.imgkhi giải nén sẽ bao gồm kernel, device tree, và ramfs. Ramfs này chứa một số file cấu hình cơ bản và các tiến trình quan trọng ban đầu nhưinitvàfstab(bảng mô tả các phân vùng). Khi khởi động, U-Boot sẽ tải kernel, device tree và ramfs vào RAM, sau đó chuyển quyền điều khiển cho kernel. Kernel sẽ khởi tạo driver, chuẩn bị môi trường rồi gọi tiến trìnhinittừ ramfs. - system_a: Phân vùng này chứa root file system (rootfs) chính của Android, tương tự như cây thư mục gốc của Linux. Đây cũng là nơi chứa máy ảo Zygote của Android. Tiến trình
init(từ ramfs) sẽ khởi động máy ảo Zygote từ phân vùng này.
Lưu ý (System-as-Root): Trên Android 9 trở lên, phân vùngsystem_athường chứa luôn cả nội dung của ramfs (kernel sẽ mount trực tiếpsystemlàm rootfs). - userdata: Chứa dữ liệu của người dùng, dữ liệu của các application, cài đặt…
- vendor_a: Chứa các file chương trình (binary) được cung cấp bởi các hãng làm chip (SoC) hoặc làm bo mạch. Các hãng này thường không công bố mã nguồn (public code) mà chỉ cung cấp các file binary này (dạng “prebuilt”) vào trong source Android. Khi build, các file này sẽ được nén thành
vendor.imgvà được ghi vào phân vùngvendor_a. - Các phân vùng khác: Ngoài ra, còn có các phân vùng chức năng khác như
metadata,misc,cache,recovery,radio(chứa firmware cho baseband), vàtos(Trusty OS).
2. Quá trình Build, Nạp (Flashing) và Cấu hình
Sau khi build xong các file binary, hệ thống build của Android sẽ sử dụng một số công cụ để nén (zip) chúng lại, tạo thành các file ảnh (image) .img cho từng phân vùng. Các file image này có thể được giải nén, chỉnh sửa cây thư mục bên trong, sau đó nén lại và nạp vào thiết bị.
Cấu hình Kích thước (Sizing)
Khi porting Android, một việc quan trọng là phải cấu hình kích thước (size) của file .img cho từng phân vùng. Google thường định nghĩa kích thước khuyến nghị cho từng phiên bản:
- Ví dụ:
system.imgtrên Android 8 có thể là 1.5GB, nhưng trên Android 9 là 2.5GB. - Lập trình viên có thể cấu hình lại size, tuy nhiên nếu đặt size file
.imgquá bé, có thể gây lỗi trong quá trình booting (do thiếu dung lượng).
Công cụ Nạp (Flashing Tools)
Do cấu trúc phân vùng phức tạp, nhà sản xuất chip thường sẽ cung cấp các tool hoặc script đi kèm bộ code Android để tự động nạp (ghi) các phân vùng này vào thiết bị lưu trữ.
Trong trường hợp lập trình viên chỉ muốn ghi lại một phân vùng cụ thể (ví dụ: boot.img hoặc system.img sau khi sửa lỗi), công cụ fastboot (đi kèm trong bộ code Android) có thể được sử dụng để thực hiện việc này một cách nhanh chóng.