Câu hỏi thường gặp

Google có sử dụng OTA A/B trên thiết bị nào không?

Có. Tên tiếp thị cho bản cập nhật A/B là bản cập nhật liền mạch. Điện thoại Pixel và Pixel XL từ tháng 10 năm 2016 được xuất xưởng cùng với A/B và tất cả Chromebook đều sử dụng cùng một cách triển khai update_engine A/B. Việc triển khai mã nền tảng cần thiết là công khai trong Android 7.1 trở lên.

Tại sao OTA A/B lại tốt hơn?

OTA A/B mang đến trải nghiệm tốt hơn cho người dùng khi cập nhật. Số liệu đo lường từ các bản cập nhật bảo mật hằng tháng cho thấy tính năng này đã chứng minh được sự thành công: Tính đến tháng 5 năm 2017, 95% chủ sở hữu Pixel đang chạy bản cập nhật bảo mật mới nhất sau một tháng so với 87% người dùng Nexus và người dùng Pixel cập nhật sớm hơn người dùng Nexus. Việc không cập nhật được các khối trong quá trình cập nhật qua mạng (OTA) sẽ không còn khiến thiết bị không khởi động được nữa; cho đến khi hình ảnh hệ thống mới khởi động thành công, Android vẫn có khả năng quay lại hình ảnh hệ thống hoạt động trước đó.

system_other là gì?

Các ứng dụng được lưu trữ trong tệp .apk, đây thực chất là các tệp lưu trữ ZIP. Mỗi tệp .apk có một hoặc nhiều tệp .dex chứa mã byte Dalvik di động bên trong. Tệp .odex (tệp .dex được tối ưu hoá) nằm riêng biệt với tệp .apk và có thể chứa mã máy dành riêng cho thiết bị. Nếu có tệp .odex, Android có thể chạy các ứng dụng ở tốc độ biên dịch trước thời hạn mà không cần phải đợi mã được biên dịch mỗi khi ứng dụng khởi chạy. Tệp .odex không thực sự cần thiết: Android có thể chạy trực tiếp mã .dex thông qua quá trình diễn giải hoặc biên dịch Just-In-Time (JIT), nhưng tệp .odex mang đến sự kết hợp tốt nhất giữa tốc độ khởi chạy và tốc độ thời gian chạy nếu có đủ dung lượng.

Ví dụ: Đối với tệp installed-files.txt trên Nexus 6P chạy Android 7.1 với tổng kích thước hình ảnh hệ thống là 2628 MiB (2755792836 byte), thông tin chi tiết về những thành phần đóng góp lớn nhất vào tổng kích thước hình ảnh hệ thống theo loại tệp như sau:

.odex	1391770312 byte	50,5%
.apk	846878259 byte	30,7%
.so (mã C/C++ gốc)	202162479 byte	7,3%
Tệp .oat/Hình ảnh .art	163892188 byte	5,9%
Phông chữ	38952361 byte	1,4%
dữ liệu ngôn ngữ ICU	27468687 byte	0,9%

Những số liệu này cũng tương tự đối với các thiết bị khác, vì vậy, trên các thiết bị Nexus/Pixel, các tệp .odex chiếm khoảng một nửa phân vùng hệ thống. Điều này có nghĩa là chúng ta có thể tiếp tục sử dụng ext4 nhưng ghi các tệp .odex vào phân vùng B tại nhà máy, sau đó sao chép các tệp này vào /data khi khởi động lần đầu. Bộ nhớ thực tế được dùng với A/B ext4 giống hệt với A/B SquashFS, vì nếu đã dùng SquashFS, chúng ta sẽ gửi các tệp .odex được tối ưu hoá trước trên system_a thay vì system_b.

Việc sao chép tệp .odex vào /data có nghĩa là dung lượng đã lưu trên /system sẽ bị mất trên /data không?

Chưa chính xác. Trên Pixel, hầu hết dung lượng mà các tệp .odex chiếm dụng là dành cho các ứng dụng. Các ứng dụng này thường nằm trên /data. Những ứng dụng này nhận được các bản cập nhật của Google Play, vì vậy, các tệp .apk và .odex trên hình ảnh hệ thống sẽ không được dùng trong phần lớn thời gian hoạt động của thiết bị. Người dùng có thể loại trừ hoàn toàn các tệp như vậy và thay thế bằng các tệp .odex nhỏ, dựa trên hồ sơ khi thực sự sử dụng từng ứng dụng (do đó không cần dung lượng cho các ứng dụng mà người dùng không sử dụng). Để biết thông tin chi tiết, hãy tham khảo bài nói chuyện tại Google I/O 2016 có tên Sự phát triển của nghệ thuật.

Việc so sánh này gặp khó khăn vì một số lý do chính:

• Các ứng dụng do Google Play cập nhật luôn có tệp .odex trên /data ngay khi nhận được bản cập nhật đầu tiên.
• Những ứng dụng mà người dùng không chạy sẽ không cần đến tệp .odex.
• Quá trình biên dịch dựa trên hồ sơ tạo ra các tệp .odex nhỏ hơn so với quá trình biên dịch trước khi thực thi (vì quá trình này chỉ tối ưu hoá mã quan trọng đối với hiệu suất).

Để biết thông tin chi tiết về các lựa chọn điều chỉnh mà OEM có thể sử dụng, hãy xem phần Định cấu hình ART.

Có phải có 2 bản sao của tệp .odex trên /data không?

Quá trình này phức tạp hơn một chút ... Sau khi hình ảnh hệ thống mới được ghi, phiên bản dex2oat mới sẽ chạy trên các tệp .dex mới để tạo các tệp .odex mới. Điều này xảy ra khi hệ thống cũ vẫn đang chạy, vì vậy, cả tệp .odex cũ và mới đều nằm trên /data cùng một lúc.

Mã trong OtaDexoptService (frameworks/base/+/android16-release/services/core/java/com/android/server/pm/OtaDexoptService.java) gọi getAvailableSpace trước khi tối ưu hoá từng gói để tránh tình trạng tràn /data. Xin lưu ý rằng dung lượng còn trống ở đây vẫn còn khá lớn: đó là dung lượng còn lại trước khi đạt đến ngưỡng dung lượng thấp thông thường của hệ thống (được đo bằng cả tỷ lệ phần trăm và số byte). Vì vậy, nếu /data đầy, sẽ không có 2 bản sao của mọi tệp .odex. Cùng một mã cũng có BULK_DELETE_THRESHOLD: Nếu thiết bị gần đầy dung lượng trống (như vừa mô tả), các tệp .odex thuộc về những ứng dụng không được dùng sẽ bị xoá. Đó là một trường hợp khác không có 2 bản sao của mọi tệp .odex.

Trong trường hợp xấu nhất khi /data đã đầy, bản cập nhật sẽ chờ cho đến khi thiết bị khởi động lại vào hệ thống mới và không còn cần đến các tệp .odex của hệ thống cũ nữa. PackageManager xử lý việc này: (frameworks/base/+/android16-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215). Sau khi hệ thống mới khởi động thành công, installd (frameworks/native/+/android16-release/cmds/installd/dexopt.cpp#2422) có thể xoá các tệp .odex mà hệ thống cũ đã dùng, đưa thiết bị trở lại trạng thái ổn định chỉ có một bản sao.

Vì vậy, mặc dù có thể /data chứa 2 bản sao của tất cả các tệp .odex, nhưng (a) điều này chỉ là tạm thời và (b) chỉ xảy ra nếu bạn có nhiều dung lượng trống trên /data. Trừ phi trong quá trình cập nhật, nếu không thì chỉ có một bản sao. Ngoài ra, trong số các tính năng chung về độ ổn định của ART, ART sẽ không bao giờ điền /data bằng các tệp .odex (vì đó cũng sẽ là một vấn đề trên hệ thống không phải A/B).

Việc ghi/sao chép này có làm tăng mức độ hao mòn của bộ nhớ flash không?

Chỉ một phần nhỏ của bộ nhớ flash được ghi lại: một bản cập nhật hệ thống Pixel đầy đủ sẽ ghi khoảng 2,3 GiB. (Các ứng dụng cũng được biên dịch lại, nhưng điều này cũng đúng với các ứng dụng không phải A/B.) Theo truyền thống, các OTA đầy đủ dựa trên khối ghi một lượng dữ liệu tương tự, vì vậy, tốc độ hao mòn của bộ nhớ flash sẽ tương tự nhau.

Việc flash hai phân vùng hệ thống có làm tăng thời gian flash tại nhà máy không?

Không. Pixel không tăng kích thước hình ảnh hệ thống (chỉ phân chia không gian trên 2 phân vùng).

Việc giữ các tệp .odex trên B có làm cho quá trình khởi động lại sau khi đặt lại dữ liệu về trạng thái ban đầu diễn ra chậm hơn không?

Có. Nếu bạn đã thực sự sử dụng một thiết bị, nhận được bản cập nhật qua mạng không dây (OTA) và đặt lại dữ liệu về trạng thái ban đầu, thì lần khởi động lại đầu tiên sẽ chậm hơn so với bình thường (1 phút 40 giây so với 40 giây trên Pixel XL) vì các tệp .odex sẽ bị mất khỏi B sau lần cập nhật OTA đầu tiên và do đó không thể sao chép sang /data. Đó là sự đánh đổi.

Thao tác đặt lại dữ liệu về trạng thái ban đầu của nhà máy hiếm khi xảy ra so với quá trình khởi động thông thường, vì vậy, thời gian thực hiện không quan trọng. (Điều này không ảnh hưởng đến những người dùng hoặc người đánh giá nhận được thiết bị từ nhà máy, vì trong trường hợp đó, phân vùng B sẽ có sẵn.) Việc sử dụng trình biên dịch JIT có nghĩa là chúng ta không cần biên dịch lại mọi thứ, vì vậy, điều này không tệ như bạn nghĩ. Bạn cũng có thể đánh dấu các ứng dụng là yêu cầu biên dịch trước thời gian bằng cách sử dụng coreApp="true" trong tệp kê khai: (frameworks/base/+/android16-release/packages/SystemUI/AndroidManifest.xml#23). system_server hiện đang sử dụng tính năng này vì không được phép JIT vì lý do bảo mật.

Việc giữ các tệp .odex trên /data thay vì /system có làm cho quá trình khởi động lại sau khi cập nhật qua mạng (OTA) diễn ra chậm hơn không?

Không. Như đã giải thích ở trên, dex2oat mới sẽ chạy trong khi hình ảnh hệ thống cũ vẫn đang chạy để tạo các tệp mà hệ thống mới sẽ cần. Bản cập nhật sẽ không được coi là có sẵn cho đến khi hoàn tất công việc đó.

Chúng ta có thể (nên) vận chuyển thiết bị A/B 32 GiB không? 16GiB? 8GiB?

32 GiB hoạt động tốt như đã được chứng minh trên Pixel và 320 MiB trên 16 GiB có nghĩa là giảm 2%. Tương tự, 320 MiB trên 8 GiB giảm 4%. Rõ ràng, A/B sẽ không phải là lựa chọn được đề xuất trên các thiết bị có 4 GiB, vì mức hao tổn 320 MiB gần bằng 10% tổng dung lượng có sẵn.

AVB 2.0 có yêu cầu OTA A/B không?

Không. Tính năng Khởi động đã xác minh của Android luôn yêu cầu các bản cập nhật dựa trên khối, nhưng không nhất thiết phải là các bản cập nhật A/B.

Bản cập nhật qua mạng (OTA) A/B có yêu cầu AVB 2.0 không?

STT

Bản cập nhật qua mạng (OTA) A/B có phá vỡ tính năng bảo vệ chống khôi phục về phiên bản cũ của AVB 2.0 không?

Không. Có một số nhầm lẫn ở đây vì nếu hệ thống A/B không khởi động được vào hình ảnh hệ thống mới, hệ thống sẽ tự động quay về hình ảnh hệ thống "trước đó" (sau một số lần thử lại do trình tải khởi động của bạn xác định). Tuy nhiên, điểm mấu chốt ở đây là "trước" theo nghĩa A/B thực sự vẫn là hình ảnh hệ thống "hiện tại". Ngay khi thiết bị khởi động thành công một hình ảnh mới, tính năng bảo vệ chống quay lại sẽ hoạt động và đảm bảo rằng bạn không thể quay lại. Nhưng cho đến khi bạn thực sự khởi động thành công hình ảnh mới, tính năng bảo vệ khôi phục sẽ không coi đó là hình ảnh hệ thống hiện tại.

Nếu bạn cài đặt bản cập nhật trong khi hệ thống đang chạy, thì quá trình này có chậm không?

Với các bản cập nhật không phải A/B, mục tiêu là cài đặt bản cập nhật nhanh nhất có thể vì người dùng đang chờ và không thể sử dụng thiết bị của họ trong khi bản cập nhật được áp dụng. Với bản cập nhật A/B, điều ngược lại sẽ xảy ra; vì người dùng vẫn đang sử dụng thiết bị của họ, nên mục tiêu là giảm thiểu tác động đến mức có thể, do đó, bản cập nhật sẽ diễn ra chậm hơn. Thông qua logic trong ứng dụng cập nhật hệ thống Java (đối với Google là GmsCore, gói cốt lõi do GMS cung cấp), Android cũng cố gắng chọn thời điểm mà người dùng không sử dụng thiết bị của họ. Nền tảng này hỗ trợ việc tạm dừng/tiếp tục cập nhật và ứng dụng có thể sử dụng tính năng đó để tạm dừng cập nhật nếu người dùng bắt đầu sử dụng thiết bị và tiếp tục cập nhật khi thiết bị không hoạt động trở lại.

Có 2 giai đoạn khi thực hiện OTA, được thể hiện rõ ràng trong giao diện người dùng dưới dạng Bước 1/2 và Bước 2/2 trong thanh tiến trình. Bước 1 tương ứng với việc ghi các khối dữ liệu, trong khi bước 2 là biên dịch trước các tệp .dex. Hai giai đoạn này khá khác nhau về tác động đến hiệu suất. Giai đoạn đầu tiên là I/O đơn giản. Việc này không đòi hỏi nhiều tài nguyên (RAM, CPU, I/O) vì chỉ sao chép các khối xung quanh một cách chậm rãi.

Giai đoạn thứ hai chạy dex2oat để biên dịch trước hình ảnh hệ thống mới. Rõ ràng là yêu cầu này có ít giới hạn rõ ràng hơn vì nó biên dịch các ứng dụng thực tế. Rõ ràng là việc biên dịch một ứng dụng lớn và phức tạp sẽ tốn nhiều công sức hơn so với một ứng dụng nhỏ và đơn giản; trong khi đó, ở giai đoạn 1, không có khối đĩa nào lớn hơn hoặc phức tạp hơn các khối khác.

Quy trình này tương tự như khi Google Play cài đặt bản cập nhật ứng dụng ở chế độ nền trước khi hiển thị thông báo 5 ứng dụng đã được cập nhật, như đã diễn ra trong nhiều năm.

Điều gì xảy ra nếu người dùng thực sự đang chờ bản cập nhật?

Cách triển khai hiện tại trong GmsCore không phân biệt giữa bản cập nhật trong nền và bản cập nhật do người dùng thực hiện, nhưng có thể sẽ phân biệt trong tương lai. Trong trường hợp người dùng yêu cầu cài đặt bản cập nhật một cách rõ ràng hoặc đang xem màn hình tiến trình cập nhật, chúng tôi sẽ ưu tiên công việc cập nhật với giả định rằng họ đang tích cực chờ đợi quá trình này hoàn tất.

Điều gì sẽ xảy ra nếu không áp dụng được bản cập nhật?

Với các bản cập nhật không phải A/B, nếu không áp dụng được một bản cập nhật, thì người dùng thường sẽ không dùng được thiết bị. Ngoại lệ duy nhất là nếu lỗi xảy ra trước khi ứng dụng bắt đầu (vì gói không xác minh được, chẳng hạn). Với bản cập nhật A/B, việc không áp dụng được bản cập nhật sẽ không ảnh hưởng đến hệ thống đang chạy. Bạn chỉ cần thử cập nhật lại sau.