Trang này mô tả những thay đổi được thêm vào AOSP để giảm những thay đổi không cần thiết về tệp giữa các bản dựng. Những người triển khai thiết bị duy trì hệ thống xây dựng của riêng mình có thể sử dụng thông tin này làm hướng dẫn để giảm kích thước của các bản cập nhật qua mạng không dây (OTA).
Các bản cập nhật Android OTA đôi khi chứa các tệp đã thay đổi không tương ứng với những thay đổi về mã. Chúng thực sự là các cấu phần phần mềm hệ thống xây dựng. Điều này có thể xảy ra khi cùng một mã, được tạo ở từ nhiều lần, từ các thư mục khác nhau hoặc trên các máy khác nhau sẽ tạo ra một lượng lớn dữ liệu tệp. Các tệp thừa như vậy làm tăng kích thước của bản vá OTA và gây khó khăn cho việc xác định mã nào đã thay đổi.
Để nội dung của OTA trở nên rõ ràng hơn, AOSP có các thay đổi về hệ thống xây dựng được thiết kế để giảm kích thước của bản vá OTA. Những thay đổi không cần thiết về tệp giữa các bản dựng đã được đã bị loại bỏ và chỉ có các tệp liên quan đến bản vá mới được đưa vào bản cập nhật OTA. AOSP cũng bao gồm build diff tool (công cụ so sánh bản dựng), giúp lọc ra các thông tin liên quan đến bản dựng các thay đổi về tệp để làm cho tệp bản dựng có sự khác biệt rõ ràng hơn và công cụ liên kết khối để duy trì việc phân bổ chặn nhất quán.
Hệ thống xây dựng có thể tạo các bản vá lớn không cần thiết theo nhiều cách. Để giảm thiểu điều này, trong Android 8.0 trở lên, các tính năng mới được triển khai để giảm kích thước bản vá cho mỗi phiên bản điểm khác biệt về tệp. Sau đây là những điểm cải tiến giúp giảm kích thước gói bản cập nhật OTA:
-
Sử dụng ZSTD, một thuật toán nén không tổn hao, mục đích chung để tạo
hình ảnh trên các bản cập nhật thiết bị không theo A/B. Bạn có thể tuỳ chỉnh ZSTD để có
tỷ lệ nén bằng cách tăng mức nén. Mức nén được đặt trong thời gian kết nối mạng không dây
thời gian tạo và có thể được thiết lập bằng cách chuyển cờ
--vabc_compression_param=zstd,$COMPRESSION_LEVEL
-
Tăng kích thước cửa sổ nén dùng trong OTA. Kích thước cửa sổ nén tối đa
bạn có thể thiết lập bằng cách tuỳ chỉnh tham số bản dựng trong tệp
.mk
của thiết bị. Chiến dịch này biến được đặt thànhPRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 262144
- Sử dụng tính năng nén Puffin, một công cụ vá lỗi tất định để xả luồng, xử lý các hàm nén và khác biệt để tạo bản cập nhật A/B OTA.
-
Những thay đổi đối với việc sử dụng công cụ tạo delta, chẳng hạn như cách
bsdiff
thư viện được dùng để nén các bản vá. Trong Android 9 trở lên, Công cụbsdiff
chọn thuật toán nén mà sẽ cho phép kết quả nén tốt nhất cho bản vá. -
Các cải tiến đối với
update_engine
dẫn đến tiêu thụ ít bộ nhớ hơn khi áp dụng bản vá cho các bản cập nhật thiết bị A/B.
Các phần sau đây thảo luận nhiều vấn đề ảnh hưởng đến kích thước của bản cập nhật qua mạng không dây, giải pháp khắc phục và ví dụ về cách triển khai trong AOSP.
Thứ tự tệp
Vấn đề: Các hệ thống tệp không đảm bảo thứ tự tệp khi được yêu cầu cung cấp danh sách
trong một thư mục, mặc dù thư mục này thường giống nhau cho cùng một quy trình thanh toán. Các công cụ như
ls
sắp xếp kết quả theo mặc định, nhưng hàm ký tự đại diện được sử dụng bởi các lệnh như
vì find
và make
sẽ không sắp xếp. Trước khi sử dụng các công cụ này, bạn phải sắp xếp
dữ liệu đầu ra.
Giải pháp: Khi bạn sử dụng các công cụ như find
và
make
bằng hàm ký tự đại diện, sắp xếp kết quả của các lệnh này trước khi sử dụng
chúng. Khi dùng $(wildcard)
hoặc $(shell find)
trong
Android.mk
tệp, cũng sắp xếp các tệp đó. Một số công cụ như Java sẽ sắp xếp dữ liệu đầu vào, vì vậy,
trước khi sắp xếp các tệp, hãy xác minh rằng công cụ bạn đang sử dụng chưa thực hiện việc này.
Ví dụ: Nhiều thực thể đã được khắc phục trong hệ thống xây dựng cốt lõi bằng cách sử dụng
macro all-*-files-under
tích hợp sẵn, bao gồm
all-cpp-files-under
(vì một số định nghĩa được trải rộng trong các tệp makefile khác).
Để biết thông tin chi tiết, vui lòng tham khảo các nội dung sau:
- https://android.googlesource.com/platform/build/+/4d66adfd0e6d599d8502007e4ea9aaf82e95569f
- https://android.googlesource.com/platform/build/+/379f9f9cec4fe1c66b6d60a6c19fecb81b9eb410
- https://android.googlesource.com/platform/build/+/7c3e3f8314eec2c053012dd97d2ae649ebeb5653&hl=vi
- https://android.googlesource.com/platform/build/+/5c64b4e81c1331cab56d8a8c201f26bb263b630c
Thư mục bản dựng
Vấn đề: Việc thay đổi thư mục chứa những thứ được xây dựng có thể khiến
tệp nhị phân khác biệt. Hầu hết đường dẫn trong bản dựng Android đều là đường dẫn tương đối, vì vậy,
__FILE__
trong C/C++ không phải là vấn đề. Tuy nhiên, biểu tượng gỡ lỗi mã hoá toàn bộ
pathname theo mặc định và .note.gnu.build-id
được tạo từ việc băm
tệp nhị phân xoá trước nên tệp này sẽ thay đổi nếu biểu tượng gỡ lỗi thay đổi.
Giải pháp: AOSP hiện tại sẽ tạo các đường dẫn gỡ lỗi tương đối. Để biết thông tin chi tiết, hãy tham khảo CL: https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02.
Dấu thời gian
Vấn đề: Dấu thời gian trong dữ liệu đầu ra của bản dựng dẫn đến những thay đổi không cần thiết đối với tệp. Điều này có thể xảy ra ở những vị trí sau:
- Macro
__DATE__/__TIME__/__TIMESTAMP__
trong mã C hoặc C++. - Dấu thời gian được nhúng trong tệp lưu trữ theo định dạng zip.
Giải pháp/ví dụ: Để xoá dấu thời gian khỏi kết quả của bản dựng, hãy sử dụng hướng dẫn bên dưới trong __DATE__/__TIME__/__TIMESTAMP__ bằng C/C++. và Dấu thời gian được nhúng trong bản lưu trữ.
__DATE__/__TIME__/__TIMESTAMP__ bằng C/C++
Những macro này luôn tạo ra kết quả khác nhau cho các bản dựng khác nhau, vì vậy, đừng sử dụng chúng. Ở đây là một vài tùy chọn để loại bỏ các macro này:
- Hãy xoá các từ khoá đó. Ví dụ: tham khảo https://android.googlesource.com/platform/system/core/+/30622bbb209db187f6851e4cf0cdaa147c2fca9f.
- Để xác định duy nhất tệp nhị phân đang chạy, hãy đọc mã bản dựng trong tiêu đề ELF.
-
Để biết thời điểm hệ điều hành được tạo, hãy đọc
ro.build.date
(điều này phù hợp với mọi thứ ngoại trừ các bản dựng tăng dần (có thể không cập nhật ngày này). Ví dụ: hãy tham khảo đến https://android.googlesource.com/platform/external/libchrome/+/8b7977ecpc94f6b3a3896cd13b4aeacbfa1e0f84.
Dấu thời gian được nhúng trong tệp lưu trữ (zip, jar)
Android 7.0 khắc phục vấn đề dấu thời gian được nhúng trong tệp lưu trữ zip bằng cách thêm
-X
cho mọi trường hợp sử dụng lệnh zip
. Thao tác này đã xoá UID/GID của
và dấu thời gian Unix mở rộng từ tệp zip.
Một công cụ mới, ziptime
(nằm trong
/platform/build/+/main/tools/ziptime/
) đặt lại dấu thời gian bình thường trong tiêu đề zip. Để biết thông tin chi tiết, hãy tham khảo
Tệp README.
Công cụ signapk
đặt dấu thời gian cho các tệp APK có thể thay đổi tuỳ theo
múi giờ máy chủ. Để biết chi tiết, vui lòng tham khảo CL
https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.
Công cụ signapk
đặt dấu thời gian cho các tệp APK có thể thay đổi tuỳ theo
múi giờ máy chủ. Để biết chi tiết, vui lòng tham khảo CL
https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.
Chuỗi phiên bản
Vấn đề: Chuỗi phiên bản APK thường có thêm BUILD_NUMBER
vào phiên bản được cố định giá trị trong mã. Ngay cả khi không có gì thay đổi trong APK, thì APK
vẫn sẽ khác.
Giải pháp: Xoá số bản dựng khỏi chuỗi phiên bản APK.
Ví dụ:
- https://android.googlesource.com/platform/packages/apps/Camera2/+/5e0f4cf699a4c7c95e2c38ae3babe6f20c258d27
- https://android.googlesource.com/platform/build/+/d75d893da8f97a5c7781142aaa7a16cf1dbb669c
Bật tính năng tính toán xác minh trên thiết bị
Nếu dm-verity được bật trên thiết bị của bạn, sau đó các công cụ OTA sẽ tự động nhận cấu hình xác thực của bạn, và bật tính năng tính toán xác minh trên thiết bị. Điều này cho phép tính toán các khối xác thực trên Android thay vì được lưu trữ dưới dạng byte thô trong gói OTA. Khối xác thực có thể sử dụng khoảng 16 MB cho phân vùng 2 GB.
Tuy nhiên, việc tính xác thực trên thiết bị có thể mất nhiều thời gian. Cụ thể, Nhà xuất bản chuyển tiếp
Mã sửa lỗi có thể mất nhiều thời gian. Trên thiết bị pixel, quá trình này thường mất đến 10
phút. Trên các thiết bị cấp thấp, quá trình này có thể mất nhiều thời gian hơn. Nếu bạn muốn tắt tính năng xác thực trên thiết bị
nhưng vẫn bật dm-verity, bạn có thể thực hiện việc này bằng cách truyền
--disable_fec_computation
cho công cụ ota_from_target_files
khi
tạo bản cập nhật OTA. Cờ này tắt tính toán xác minh trên thiết bị trong quá trình cập nhật OTA.
Giúp giảm thời gian cài đặt qua mạng không dây, nhưng lại tăng kích thước gói thông qua mạng không dây. Nếu thiết bị của bạn không
bật dm-verity, việc chuyển cờ này sẽ không có hiệu lực.
Các công cụ xây dựng nhất quán
Vấn đề: Các công cụ tạo ra tệp được cài đặt phải nhất quán (một giá trị đầu vào phải luôn tạo ra cùng một đầu ra).
Giải pháp/Ví dụ: Các thay đổi cần thiết trong các công cụ xây dựng sau đây:
- Người tạo tệp THÔNG BÁO. Người tạo tệp THÔNG BÁO đã được thay đổi để tạo thu thập THÔNG BÁO có thể tái tạo. Tham khảo CL: https://android.googlesource.com/platform/build/+/8ae4984c2c8009e7a08e2a76b1762c2837ad4f64.
- Bộ trình biên dịch Android Java (Jack). Chuỗi công cụ Jack yêu cầu cập nhật để xử lý các thay đổi thỉnh thoảng trong thứ tự hàm khởi tạo được tạo. Trình truy cập xác định cho hàm khởi tạo được thêm vào chuỗi công cụ: https://android.googlesource.com/toolchain/jack/+/056a5425b3ef57935206c19ecb198a89221ca64b.
- Trình biên dịch AOT ART (dex2oat). Tệp nhị phân trình biên dịch ART đã nhận được một bản cập nhật đã thêm tuỳ chọn tạo hình ảnh xác định: https://android.googlesource.com/platform/art/+/ace0dc1dd5480ad458e622085e51583653853fb9.
-
Tệp libpac.so (V8). Mỗi công trình tạo ra một
/system/lib/libpac.so
vì bản tổng quan nhanh V8 thay đổi theo từng bản dựng. Chiến lược phát hành đĩa đơn đó là xoá ảnh chụp nhanh: https://android.googlesource.com/platform/external/v8/+/e537f38c36600fd0f3026adba6b3f4cbcee1fb29. - Tệp pre-dexopt (.odex) của ứng dụng. Các tệp pre-dexopt (.odex) chứa khoảng đệm chưa khởi tạo trên hệ thống 64 bit. Điều này đã được khắc phục: https://android.googlesource.com/platform/art/+/34ed3myaccount41820c72a3c0ab9770be66b6668aa029.
Sử dụng công cụ bản dựng khác biệt
Đối với trường hợp không thể loại bỏ những thay đổi về tệp liên quan đến bản dựng, AOSP bao gồm một
công cụ so sánh bản dựng,
target_files_diff.py
để sử dụng trong việc so sánh hai gói tệp. Công cụ này thực hiện sự khác biệt đệ quy giữa hai
bản dựng, ngoại trừ những thay đổi phổ biến về tệp liên quan đến bản dựng, chẳng hạn như
- Những thay đổi dự kiến trong kết quả của bản dựng (ví dụ: do thay đổi số bản dựng).
- Thay đổi do các vấn đề đã biết trong hệ thống xây dựng hiện tại.
Để sử dụng công cụ bản dựng diff, hãy chạy lệnh sau:
target_files_diff.py dir1 dir2
dir1
và dir2
là các thư mục cơ sở chứa đích được trích xuất
cho từng bản dựng.
Giữ phân bổ khối nhất quán
Đối với một tệp nhất định, mặc dù nội dung của tệp đó vẫn giữ nguyên giữa hai bản dựng, nhưng các khối thực tế nơi lưu giữ dữ liệu có thể đã thay đổi. Do đó, trình cập nhật phải thực hiện I/O không cần thiết để di chuyển các khối để cập nhật OTA.
Trong bản cập nhật A/B OTA không cần thiết, I/O không cần thiết có thể làm tăng đáng kể dung lượng lưu trữ cần thiết để lưu trữ ảnh chụp nhanh có thể sao chép khi ghi. Trong bản cập nhật OTA không phải A/B, việc di chuyển các khối cho một Bản cập nhật OTA đóng góp vào thời gian cập nhật vì có nhiều I/O hơn do việc di chuyển khối.
Để giải quyết vấn đề này, trong Android 7.0, Google đã mở rộng công cụ make_ext4fs
cho
đảm bảo phân bổ khối nhất quán trên các bản dựng. Công cụ make_ext4fs
chấp nhận
một cờ -d base_fs
(không bắt buộc) cố gắng phân bổ các tệp cho cùng một khối
khi tạo hình ảnh ext4
. Bạn có thể trích xuất các tệp ánh xạ khối (như
base_fs
tệp bản đồ) từ các tệp đích của bản dựng trước zip. Đối với mỗi
Phân vùng ext4
, có một tệp .map
trong
Thư mục IMAGES
(ví dụ: IMAGES/system.map
tương ứng với
system
). Sau đó, bạn có thể xác nhận và xác nhận các tệp base_fs
này
được chỉ định qua PRODUCT_<partition>_BASE_FS_PATH
, như trong ví dụ này:
PRODUCT_SYSTEM_BASE_FS_PATH := path/to/base_fs_files/base_system.map PRODUCT_SYSTEM_EXT_BASE_FS_PATH := path/to/base_fs_files/base_system_ext.map PRODUCT_SERVICES_BASE_FS_PATH := path/to/base_fs_files/base_vendor.map PRODUCT_PRODUCT_BASE_FS_PATH := path/to/base_fs_files/base_product.map PRODUCT_ODM_BASE_FS_PATH := path/to/base_fs_files/base_odm.map
Mặc dù không giúp giảm tổng kích thước gói OTA, nhưng nó có thể cải thiện quá trình cập nhật qua mạng không dây bằng cách giảm số lượng I/O. Đối với cập nhật A/B ảo, tính năng này giúp giảm đáng kể dung lượng lưu trữ cần thiết để áp dụng OTA.
Tránh cập nhật ứng dụng
Ngoài việc giảm thiểu sự khác biệt về bản dựng, bạn có thể giảm kích thước của bản cập nhật qua mạng không dây bằng cách loại trừ các bản cập nhật cho các ứng dụng nhận được bản cập nhật thông qua cửa hàng ứng dụng. APK thường chiếm một phần đáng kể nhiều phân vùng trên một thiết bị. Bao gồm các phiên bản mới nhất của ứng dụng được cập nhật theo ứng dụng các cửa hàng trong bản cập nhật OTA có thể tác động đáng kể đến các gói OTA và khiến ít người dùng lợi ích khác. Vào thời điểm người dùng nhận được gói OTA, họ có thể đã cập nhật ứng dụng, hoặc một phiên bản mới hơn, nhận được trực tiếp từ các cửa hàng ứng dụng.