Việc định cỡ phân vùng super đúng cách là rất quan trọng để thiết bị có thể cập nhật. Kích thước này ảnh hưởng trực tiếp đến số lượng bản cập nhật mà một thiết bị có thể nhận và số lượng người dùng có thể nhận thành công các bản cập nhật đó.
Bạn cần cân nhắc một số biến quan trọng. Biến đầu tiên là kích thước ban đầu, tức là kích thước của tất cả các phân vùng động khi thiết bị được flash lần đầu. Biến thứ hai là tỷ lệ tăng trưởng, tức là tỷ lệ phần trăm mà kích thước hệ điều hành tăng lên trong toàn bộ thời gian thiết bị có thể cập nhật.
Ngoài ra, các thiết bị A/B ảo có thể sử dụng dung lượng trên /data trong quá trình cập nhật và bạn phải cân nhắc điều này khi định cỡ super. Nếu cần quá nhiều dung lượng trên /data, thì một số người dùng sẽ không thể (hoặc không muốn) nhận bản cập nhật. Tuy nhiên, nếu biết rằng hầu hết người dùng đều có một tỷ lệ phần trăm dung lượng trống, thì các thiết bị có thể thoải mái trừ dung lượng đó khỏi super. Hoặc các thiết bị có thể đảm bảo rằng không bao giờ cần đến /data bằng cách chỉ cần tạo super đủ lớn.
Dưới đây là một số mô hình giúp hướng dẫn định cỡ phân vùng super dựa trên các biến này.
Dựa vào /data
A/B ảo khuyến khích việc thu nhỏ super để cho phép tăng kích thước của /data. Bạn cần một phần dung lượng đó trong quá trình cập nhật. Để hiểu tác động đến khả năng cập nhật, bạn cần biết tỷ lệ phần trăm thiết bị có khả năng có dung lượng trống đó theo thời gian. Việc xác định con số này phụ thuộc rất nhiều vào phần cứng của thiết bị và hành vi của người dùng đối với thiết bị đó. Trong các ví dụ bên dưới, con số này được gọi là AllowedUserdataUse.
Không nén
Nếu không nén, một bản cập nhật OTA đầy đủ cần có một ảnh chụp nhanh có kích thước gần bằng với kích thước của hệ điều hành, vì vậy, bạn phải tính đến điều này khi định cỡ super:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)
Ví dụ: hãy xem xét một thiết bị A/B ảo có kích thước ban đầu là 4 GB, mức tăng dự kiến là 50% và biết rằng hầu hết người dùng đều có 1 GB dung lượng trống (hoặc sẵn sàng giải phóng tối đa 1 GB dung lượng cho bản cập nhật). Đối với thiết bị này, bạn có thể định cỡ super như sau:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)
Do đó, thiết bị này phải có phân vùng super 11 GB.
Có nén
Với tính năng nén, một bản cập nhật OTA đầy đủ cần có một ảnh chụp nhanh có kích thước bằng khoảng 70% kích thước của hệ điều hành:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)
Ví dụ: hãy xem xét một thiết bị được định cấu hình với tính năng nén A/B ảo, có kích thước ban đầu là 4 GB, mức tăng dự kiến là 50% và biết rằng hầu hết người dùng đều có 1 GB dung lượng trống (hoặc sẵn sàng giải phóng tối đa 1 GB dung lượng cho bản cập nhật). Đối với thiết bị này, bạn có thể định cỡ super như sau:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB Super = Max(6GB, 6GB + 4.2GB - 1GB) = Max(6GB, 9.2GB) = 9.2GB
Do đó, thiết bị này phải có phân vùng super 9,2 GB.
Không dựa vào /data
Nếu bạn muốn có các OTA không bao giờ yêu cầu dung lượng ảnh chụp nhanh trên /data, thì việc định cỡ super rất đơn giản.
Không nén
Đối với thiết bị A/B ảo không nén hoặc thiết bị A/B thông thường:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = FinalDessertSize * 2
Ví dụ: hãy xem xét một thiết bị A/B ảo có kích thước ban đầu là 4 GB và mức tăng dự kiến là 50%. Để đảm bảo thiết bị này không bao giờ sử dụng /data cho ảnh chụp nhanh OTA, phép tính sẽ như sau:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = FinalDessertSize * 2 = 12GB
Do đó, thiết bị này phải có phân vùng super 12 GB.
Có nén
Đối với thiết bị A/B ảo có nén:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = FinalDessertSize + FinalOTASnapshotSize
Ví dụ: hãy xem xét một thiết bị nén A/B ảo có kích thước ban đầu là 4 GB và mức tăng dự kiến là 50%. Để đảm bảo thiết bị này không bao giờ sử dụng /data cho ảnh chụp nhanh OTA, phép tính sẽ như sau:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB Super = 6GB + 4.2GB = 10.2GB
Do đó, thiết bị này phải có phân vùng super 10,2 GB.
Chú ý
Bạn có thể nhận thấy rằng nếu kích thước ban đầu là 4 GB và bản cập nhật cuối cùng là 5 GB, thì super phải là 9 GB chứ không phải 10 GB. Tuy nhiên, nếu cả bản cập nhật đầu tiên và bản cập nhật cuối cùng đều có dung lượng 5 GB, thì có thể không đủ bộ nhớ trong super cho bản cập nhật cuối cùng. Các công thức trên giả định rằng mức tăng phân vùng có thể xảy ra bất cứ lúc nào. Dung lượng cần thiết để áp dụng bản cập nhật cuối cùng có thể giống với dung lượng cần thiết để áp dụng bản cập nhật đầu tiên.
Xin lưu ý rằng tỷ lệ nén là số liệu ước tính. Hình ảnh hệ điều hành có thể nén tốt hơn hoặc kém hơn tuỳ thuộc vào nội dung của hình ảnh đó. Nếu sử dụng hệ thống tệp nén như EROFS, thì việc nén bổ sung từ A/B ảo sẽ giảm dần. Trong trường hợp này, bạn nên sử dụng một trong các công thức không nén làm nguyên tắc.
Tính kích thước
Để tìm giá trị của FactorySize trong các ví dụ trước, hãy cộng kích thước của tất cả các phân vùng động. Hình ảnh phân vùng động AOSP là:
system.imgvendor.imgproduct.imgsystem_ext.imgvendor_dlkm.imgsystem_dlkm.img
Hãy nhớ tính kích thước dựa trên hình ảnh không thưa thớt. Khi tạo Android 12 trở xuống, hình ảnh sẽ thưa thớt theo mặc định và có thể không thưa thớt bằng simg2img.
Bạn cũng có thể tính kích thước phân vùng từ gói OTA. Việc này cũng ước tính kích thước ảnh chụp nhanh A/B ảo cho từng phân vùng:
python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip
Hoặc bạn có thể sử dụng Công cụ phân tích OTA. Công cụ này không tải tệp nào lên và phân tích các gói OTA cục bộ.
Để tìm giá trị của ExpectedGrowth, hãy sử dụng một thiết bị đã phát hành trước đó. Sử dụng hình ảnh super sớm nhất và gần đây nhất để tính mức tăng.