Xác định kích thước phân vùng siêu

Việc định cỡ phân vùng super một cách chính xác là rất quan trọng để thiết bị có thể cập nhật. Kích thước ảnh hưởng trực tiếp đến số lượng bản cập nhật mà thiết bị có thể nhận được và số lượng người dùng có thể nhận được những bản cập nhật đó.

Bạn cần cân nhắc một số biến số quan trọng. Đầu tiên là kích thước gốc, đây 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. Thứ hai là tốc độ tăng trưởng, tức là tỷ lệ phần trăm kích thước hệ điều hành tăng lên trong toàn bộ thời gian có thể cập nhật của thiết bị.

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) 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 nhất định, 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 /data, chỉ cần tạo super đủ lớn.

Dưới đây là một số mô hình giúp hướng dẫn bạn phân vùng kích thước super dựa trên các biến số này.

Dựa vào /data

Thử nghiệm A/B ảo khuyến khích việc giảm super để tăng kích thước của /data. Bạn cần có một phần dung lượng đó trong quá trình cập nhật. Để hiểu rõ 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ó lượng dung lượng trống đó theo thời gian. Việc xác định 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, 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 để cập nhật). Đối với thiết bị này, bạn có thể điều chỉnh kích thướ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 bằng 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 để cập nhật). Đối với thiết bị này, super có thể được điều chỉnh kích thước 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 trưở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, cách 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ó tính năng 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, cách 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 chỉ là ướ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ì mức nén bổ sung từ Virtual A/B 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 với nhau. Các hình ảnh phân vùng động AOSP là:

  • system.img
  • vendor.img
  • product.img
  • system_ext.img
  • vendor_dlkm.img
  • system_dlkm.img

Hãy nhớ tính toán kích thước dựa trên hình ảnh không thưa. Khi tạo Android 12 trở xuống, các hình ảnh sẽ được phân tán theo mặc định và có thể được phân tán bằng simg2img.

Bạn cũng có thể tính toán kích thước phân vùng từ một gói OTA. Thao tác này cũng ước tính kích thước của ả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 bất kỳ 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 trưởng.