Tại sao Android lại ít được cập nhật phần mềm?

Điểm cốt yếu ở đây là vấn đề cơ bản mà các nhà sản xuất (OEM) gặp phải với các bản cập nhật: chi phí. Mọi OEM đều muốn thiết bị của mình có khả năng được cập nhật trong suốt vòng đời sử dụng. Nhưng họ bị hạn chế bởi những lựa chọn kinh tế khó khăn, thể hiện qua các loại chi phí. Vì vậy, để tăng tốc độ cập nhật, chúng tôi tập trung vào việc giảm những chi phí ấy.

 

Câu hỏi được đặt ra là, tại sao chi phí cập nhật lại cao? Với chúng tôi, câu trả lời có thể bao gồm các phần sau:

- Android là phần mềm mã nguồn mở và cho phép tùy biến

- Hệ sinh thái Android là rất rộng lớn

- Với mọi thiết bị, đều có vài công ty tham gia quá trình sản xuất

- Các nhà mạng phải tốn phí chứng chỉ cho mọi bản cập nhật lớn

 

Hai nguyên nhân đầu tiên có thể coi là đặc thù với Android, còn 2 nguyên nhân còn lại là vấn đề chung. Nguyên nhân thứ 3 thì có phần phổ biến hơn với hệ sinh thái Android. Kết hợp 3 nguyên nhân đầu tiên dẫn tới nguyên nhân thứ 4: chi phí chứng chỉ cao hơn.

 

Mọi dự án mã nguồn mở, đúng như tên gọi của nó, đều cho phép những điều chỉnh, thay đổi được thực hiện. Sự linh hoạt trong vấn đề này là một tính chất cốt lõi của Hệ điều hành (HĐH) Android. Đó cũng là một trong những nguyên nhân chính tại sao Android lại có thể thành công như vậy. Khi đội ngũ chúng tôi ở Google tung ra một phiên bản mới của HĐH Android, chúng tôi thực ra chỉ phát hành phiên bản AOSP (Android Open Source Project - Dự án Android mã nguồn mở), tất nhiên là dưới dạng mã nguồn.

 

Điều quan trọng cần phải chỉ ra là: phiên bản AOSP không phải là một sản phẩm cuối cùng (để tới tay người dùng). Có thể coi là nó mang sứ mệnh giới thiệu một dạng lõi cho HĐH, với mọi thành phần khiến Android là Android: môi trường ART, các hệ thống quản lí hoạt động, quản lí cửa sổ và các gói phần mềm (package), các hệ thống phụ về đa phương tiện, các cảm biến, máy ảnh, logic khởi tạo,v.v… những thứ như thế.

 

Bản phát hành AOSP cũng bao gồm các phiên bản mã nguồn mở của nhiều thành phần của HĐH mà người dùng cuối (end user) sẽ tương tác nhiều hơn như giao diện hệ thống hay trình khởi chạy ứng dụng (App Launcher), nhiều ứng dụng bổ sung nữa. Nhưng đây chỉ là những phiên bản mã nguồn mở mang tính tham chiếu, và chúng tôi không hề định sử dụng chúng trên bất cứ thiết bị nào tới tay người dùng.

 

Khi chúng tôi phát hành một phiên bản AOSP, chúng tôi muốn nó trở thành một bản tham chiếu. Các OEM cũng như các nhà sản xuất vi xử lí silicon có toàn quyền điều chỉnh mã nguồn này để phù hợp với nhu cầu của họ về sản phẩm, miễn là họ vượt qua một bộ những bài kiểm tra, để chắc chắn rằng những điều chỉnh này không can thiệp vào hành vi của HĐH, điều có thể gây ra việc các ứng dụng không hoạt động. Hầu hết các đối tác của chúng tôi đều tận dụng sự linh hoạt này để tạo nên sự khác biệt cho các sản phẩm của họ.

 

Tôi phải nhắc lại một lần nữa, điều này là đúng với mọi dự án mã nguồn mở. Bạn sử dụng một bản phát hành (release), thực hiện nhiều thay đổi, rồi sau đó lại phát hành phiên bản đã được thay đổi (ngay cả các kernel - lõi của HĐH Linux cũng thường được thay đổi theo cách này). Khi mà bản phát hành tiếp theo (của mã nguồn gốc) được đưa ra, bạn phải chuyển đổi (port) hoặc hoàn toàn tái cấu trúc lại phần mã lệnh cũ của những thay đổi bạn đã thực hiện. Việc này rất tốn thời gian và công sức, mà thời gian và công sức chính là chi phí.

 

Sẽ có 2 cách khắc phục chính để giảm thiểu chi phí: cách đầu tiên là bạn (ví dụ như trong trường hợp này là các OEM) đóng góp những thay đổi của mình vào cả dự án mã nguồn mở, từ đó chi phí phát sinh sẽ được bao hàm bên trong (chi phí của) dự án chính và tất cả mọi người sẽ chịu trách nhiệm về phần thay đổi của bạn. Đây là cách mà cộng đồng Linux kernel hoạt động. Nhưng trường hợp của Android thì lại khác. Điều hiển nhiên là rất nhiều tùy chỉnh đối với mã nguồn cơ sở của Android là độc quyền (bởi các hãng), chính điều này đã ngăn cản chúng được cập nhật (bởi Android Dev Team). Điều này đồng nghĩa với việc, các đối tác của chúng tôi phải tự chịu trách nhiệm việc cập nhật những thay đổi của họ.

 

Bạn có thể nói: “Thế thì đừng tạo ra thay đổi gì (so với nguyên gốc) cả, và các anh sẽ chẳng phải chuyển đổi chúng mỗi khi cập nhật.”. Nhưng đó không phải là cách Android hoạt động: bản sắc của chúng tôi là sự linh hoạt và sự đa dạng, và chúng tôi muốn tạo điều kiện cho các đối tác của mình tận dụng tối đa khả năng này.

Một giải pháp khác để giảm thiểu chi phí là tạo ra một khoảng trung hòa giữa việc tạo ra thay đổi ở mọi nơi và không thay đổi gì cả. Cụ thể hơn, chúng tôi tạo ra những ranh giới - những giao thức giữa các thành phần - và phải đạt được một thỏa thuận chung rõ ràng với các đối tác: phải xác định rõ những loại thành phần họ có thể (và sẽ) điều chỉnh, không hề đánh mất sự linh hoạt, và những loại thành phần mà phải được giữ hoàn toàn tương tự giữa mọi cá thể trong hệ sinh thái.

Từ đó, chúng tôi đã tạo ra 2 dự án để giải quyết vấn đề cập nhật: Project Treble và Project Mainline. Hai dự án này đều nhằm giải quyết vấn đề ranh giới đã đề cập bên trên, theo cách khác nhau nhưng lại bổ khuyết được cho nhau.

Với dự án Treble, chúng tôi tìm cách để tạo nên những giao thức chắc chắn giữa các thành phần không phụ thuộc vào phần cứng của HĐH, và những phần mà cần để tâm tới phần cứng. Chúng tôi thường nhắc tới loại đầu tiên trong tài liệu chính thức dưới tên gọi “chương trình khung” (framework), hay “bản hệ thống” (system image), hoặc “HĐH Lõi” (Core OS). Loại thứ hai thì chúng tôi thường đề cập đến như là “bản cho nhà cung cấp” (vendor image) hay “các HAL” (Hardware Abstraction Layer - lớp trừu tượng hóa phần cứng).

 

Làm như vậy có ích gì? Câu trả lời giúp giải quyết một gạch đầu dòng ở bên trên: “Hệ sinh thái Android rất rộng lớn”. Với một nhà sản xuất điện thoại Android (một OEM), để sản xuất một thiết bị, họ phải sử dụng một hệ thống trên vi mạch (SoC - System on Chip, bao gồm bộ vi xử lí và cách thiết bị ngoại vi trên cùng một khuôn chip) từ một nhà sản xuất chip silicon, ví dụ như Qualcomm, Mediatek, Unisoc hay Rockchip. Nhưng nhà sản xuất chip không chỉ cung cấp SoC cho các OEM này, mà họ cũng phải cung cấp cả một môi trường phát triển cùng với nó, được gọi là BSP (Board Support Package - gói (phần mềm) hỗ trợ bảng mạch). Chính BSP cũng là một phiên bản của Android! So với bản AOSP, nó chứa nhiều tinh chỉnh để có thêm các tính năng như khả năng gọi điện (ví dụ như thực hiện cuộc gọi 4G hay 5G), hay để hỗ trợ các thành phần phần cứng đặc trưng của SoC đó, và cũng để thêm giá trị đặc trưng cho SoC và OEM sử dụng SoC đó (ví dụ như cho riêng thị trường nào đó chẳng hạn). Nhìn chung, BSP cung cấp một phiên bản Android cho nhà sản xuất, điều kiện cần để có thể sản xuất bất cứ thiết bị nào sử dụng SoC đó. Những tinh chỉnh ở phiên bản BSP này lại thường xảy ra ở các tầng thấp hơn của hệ điều hành.

 

Sau đó, các OEM sẽ nhận được BSP rồi tiếp tục thực hiện những thay đổi mã nguồn để hoạt động được trên những thiết bị của họ. Không như BSP, những thay đổi này thường diễn ra ở tầng trên của HĐH Android, ví dụ như phần Cài đặt, trình khởi chạy ứng dụng hay trình quản lí cửa sổ.

Với dự án Treble, chúng tôi đánh giá sự chia tách này và nhận ra nó đã tạo nên một ranh giới tự nhiên giữa nhà sản xuất thiết bị và nhà sản xuất chip, và tổng quát hơn là giữa phần “trừu tượng” của HĐH Android và phần phụ thuộc phần cứng của nó.

 

Mục tiêu và kết quả của những nỗ lực của chúng tôi với Treble được liệt kê dưới đây, bao gồm:

- Để tạo ra một bản tham chiếu sẵn có và được chuẩn hóa, không chỉ ở dạng mã nguồn, mà ở dạng một sản phẩm thực, cho mọi phiên bản Android. Chúng tôi gọi nó là phiên bản hệ thống chung (Generic System Image - GSI)

- Các bản GSI có thể tương thích ngược với các phiên bản BSP cũ hơn cho nhà sản xuất

- Từ đó sẽ cho phép các OEM có thể duy trì những thay đổi của mình với các phiên bản hệ thống của họ mà không xung đột với những tầng bên dưới (của HĐH)

- Kết cấu này có khả năng mở rộng, để cả nhà sản xuất chip và OEM có khả năng mở rộng giao thức cho những khối phần cứng đặc trưng của họ.

 

 

Quan trọng nhất là, từ góc độ chi phí, những nỗ lực của chúng tôi sẽ tách riêng được chi phí duy trì của các OEM ra khỏi chi phí của các nhà sản xuất chip, và từ đó giúp giảm chi phí cho cả hai bên. Dự án này đã có những kết quả nhất định, được đăng tải trên blog của chúng tôi.

 

Dự án Mainline lại tiếp cận với câu hỏi về ranh giới theo một hướng khác. Nếu như Treble sẽ nói “đây là một ranh giới, chúng ta hãy tinh chỉnh cách thực hiện bằng một cách nào đó, miễn là mọi thứ tiếp tục hoạt động qua ranh giới này”, thì Mainline lại có hướng: “đây là một bộ các ranh giới phân định một thành phần mà tất cả chúng ta nên đồng ý không thực hiện điều chỉnh”. Những thành phần kiểu này thường sẽ là những phần quan trọng nhất của HĐH Android - từ các góc độ như độ ổn định, khả năng bảo mật và khả năng bảo vệ riêng tư.

 

Chúng tôi gọi những thành phần này là các môđun Mainline (Mainline Module). Một môđun Mainline là một phần mã nguồn với các thuộc tính sau:

- Trước khi (bản) Android được phát hành, có thể được cả Google và các đối tác chung tay điều chỉnh

- Sau khi bản Android được phát hành, sẽ là hoàn toàn thống nhất với mọi thiết bị trong hệ sinh thái

- Chỉ thay đổi, cập nhật với những lỗi nghiêm trọng và liên quan đến bảo mật.

 

Phẩm chất quyết định của một môđun Mainline là sự ổn định giữa mọi thiết bị. Với các môđun Mainline, chúng tôi đều đồng ý rằng không có chỗ cho sự khác biệt có chủ đích (giữa các OEM). Dự án Mainline được bắt đầu với Android 10 và hiện đã được giao phó nhiệm vụ đưa những bản vá tới nhiều và nhiều hơn nữa các thiết bị, ở một tốc độ và chất lượng mà sẽ không bao giờ trở thành sự thực nếu không có nó.

 

Tổng kết lại: Câu trả lời cho câu hỏi của bạn là: “chi phí duy trì” là lí do gây ra sự khó khăn cho việc cập nhật, và giải pháp của chúng tôi đã và đang (và sẽ tiếp tục) là một cách tiếp cận vấn đề thận trọng. Chúng tôi định nghĩa những ranh giới để khiến cho ngày càng nhiều phần của HĐH có thể được cập nhật một cách nhanh hơn, mà không phải hy sinh sự linh hoạt cũng như sức mạnh mà bản sắc mã nguồn mở của Android mang lại.