Android Open System Platform (AOSP) là mã nguồn Android được công khai và có thể chỉnh sửa. Bất kỳ ai cũng có thể tải xuống và sửa đổi AOSP cho thiết bị của mình. Trong chuỗi bài viết đầu tiên này, chúng ta sẽ cùng nhau tìm hiểu về kiến trúc phần mềm của AOSP bao gồm những thành phần nào và vai trò của từng thành phần đó là gì.

Hình: AOSP software stack architecture.

1. Kiến trúc AOSP

1.1. Android application

• Là các ứng dụng mà người dùng cài đặt và sử dụng trên thiết bị Android. Chúng có thể được tải xuống từ Google Play Store hoặc các nguồn khác.
• Ví dụ: WhatsApp, Facebook, Google Maps.

1.2. Privileged application

• Là các ứng dụng có quyền truy cập đặc biệt, thường được cài đặt sẵn bởi nhà sản xuất thiết bị hoặc nhà cung cấp dịch vụ di động. Chúng có quyền truy cập vào các API hệ thống không được công khai cho các ứng dụng thông thường.
• Ví dụ: Ứng dụng quản lý hệ thống, ứng dụng quản lý SIM của nhà mạng.

1.3. Device manufacturer's application

• Là các ứng dụng được phát triển và cài đặt bởi nhà sản xuất thiết bị. Chúng có thể là các ứng dụng tùy chỉnh để cải thiện trải nghiệm người dùng trên thiết bị của nhà sản xuất đó.
• Ví dụ: Samsung Health, MIUI Apps của Xiaomi.

1.4. System API

• Là các API được cung cấp bởi hệ điều hành Android để các ứng dụng hệ thống sử dụng. Những API này thường không được công khai cho các ứng dụng bên thứ ba.
• Ví dụ: API để truy cập thông tin hệ thống chi tiết, API quản lý kết nối mạng thấp cấp.

1.5. Android API

• Là tập hợp các API được công khai và tài liệu hóa bởi Android để các nhà phát triển ứng dụng sử dụng. Chúng cung cấp các chức năng cần thiết để phát triển các ứng dụng Android.
• Ví dụ: API cho các hoạt động, dịch vụ, quản lý nội dung và giao diện người dùng.

1.6. Android framework

• Là tầng phần mềm cung cấp các API cho các nhà phát triển ứng dụng để họ có thể truy cập vào các chức năng của hệ điều hành Android.
• Ví dụ: Các lớp và phương thức cho quản lý giao diện người dùng (UI), quản lý vòng đời ứng dụng, truy cập tài nguyên hệ thống.

1.7. System service

• Là các dịch vụ hệ thống chạy nền cung cấp các chức năng cốt lõi của hệ điều hành Android. Chúng bao gồm quản lý nguồn lực thiết bị như pin, bộ nhớ, kết nối và các dịch vụ khác.
• Ví dụ: WindowManager, PackageManager, AlarmManager.

1.8. Android Runtime (ART)

• Là môi trường runtime mới thay thế cho Dalvik VM trong các phiên bản Android mới. ART thực thi mã bytecode của ứng dụng sau khi được biên dịch từ mã nguồn Java.
• Ví dụ: Quản lý bộ nhớ, biên dịch Ahead-of-Time (AOT) và Just-in-Time (JIT).

1.9. Hardware abstraction layer (HAL)

• Là lớp trừu tượng phần cứng cung cấp giao diện chuẩn giữa phần cứng cụ thể của thiết bị và hệ điều hành Android. Nó cho phép các nhà sản xuất phần cứng triển khai các driver mà không cần phải tiết lộ mã nguồn.
• Ví dụ: Camera HAL, Audio HAL.

1.10. Daemons and native libraries

• Là các tiến trình nền và thư viện gốc (native) được viết bằng ngôn ngữ C/C++ và cung cấp các chức năng cấp thấp cho hệ thống.
• Ví dụ: vold (volume daemon) cho quản lý hệ thống tập tin, surfaceflinger cho quản lý bề mặt đồ họa.

1.11. Linux kernel

• Là lõi của hệ điều hành Android, chịu trách nhiệm quản lý tài nguyên hệ thống, cung cấp các dịch vụ cơ bản cho phần mềm ứng dụng, và đảm bảo sự giao tiếp giữa phần cứng và phần mềm. Android sử dụng một phiên bản tùy chỉnh của Linux kernel.

2. Hướng tiếp cận

Trong lĩnh vực phát triển phần mềm và thiết kế hệ thống, có hai cách tiếp cận phổ biến là "bottom-up" và "top-down". Cả hai cách tiếp cận đều có những ưu và nhược điểm riêng nên không thể nói nên hay không nên chọn phương pháp nào. Ở chuỗi các bài viết tiếp theo mình sẽ lựa chọn triển khai việc phân tích théo cách tiếp cận bottom-up vì các đặt tính sau phù hợp với cá nhân mình. Đặc điểm:

• Bắt đầu từ các thành phần nhỏ: Cách tiếp cận này bắt đầu từ các module hoặc thành phần nhỏ nhất và sau đó tích hợp chúng lại với nhau để tạo thành hệ thống hoàn chỉnh.
• Phát triển từ dưới lên: Các phần tử cơ bản được xây dựng trước, và các phần tử cao hơn trong hệ thống được xây dựng dựa trên các phần tử cơ bản này.
• Định hướng module: Mỗi module hoặc thành phần được phát triển và kiểm thử độc lập trước khi được tích hợp vào hệ thống lớn hơn.

Lợi ích:

• Kiểm soát chi tiết: Dễ dàng kiểm soát và kiểm thử từng thành phần nhỏ lẻ.
• Tái sử dụng mã nguồn: Các module được xây dựng có thể được tái sử dụng trong các dự án khác.
• Giảm thiểu lỗi: Vì mỗi thành phần được kiểm thử độc lập, nên lỗi có thể được phát hiện và sửa chữa sớm.

Hạn chế:

• Khó khăn trong tích hợp: Khi tích hợp các thành phần, có thể gặp khó khăn trong việc đảm bảo chúng hoạt động tốt cùng nhau.
• Thiếu cái nhìn tổng thể: Không có cái nhìn tổng thể về hệ thống cho đến khi tất cả các thành phần được tích hợp.

3. Kết luận

Biết được kiến trúc của hệ điều hành Android mang lại nhiều ưu điểm quan trọng trong công việc, nắm vững kiến trúc Android hỗ trợ trong việc tích hợp phần cứng và phát triển các tính năng mới một cách mượt mà, nâng cao trải nghiệm người dùng và giảm thiểu thời gian phát triển. Hướng tiếp cận: bottom-up

Tài liệu tham khảo.

• AOSP structure overview