Super 크기 조정 방법

super 파티션의 크기를 올바르게 조정하는 것은 기기 업데이트 가능성을 위해 중요합니다. 파티션의 크기는 기기가 수용할 수 있는 업데이트 횟수와 그 업데이트를 성공적으로 받을 수 있는 사용자 수에 직접적인 영향을 주기 때문입니다.

Super 크기 조정에는 몇 가지 중요한 변수가 있습니다. 첫 번째는 팩토리 크기로 기기가 처음 플래시될 때 동적으로 할당되는 모든 파티션의 크기입니다. 두 번째는 성장률로 기기를 업데이트할 수 있는 전체 기간 대비 OS 크기가 증가하는 비율입니다.

또한 가상 A/B 기기는 업데이트 중에 /data에 공간을 사용할 수 있으므로 이는 super의 크기를 조정할 때 고려해야 합니다. /data에 공간이 너무 많이 필요하면 일부 사용자는 업데이트를 받을 수 없거나 받지 않으려고 합니다. 하지만, 대부분의 사용자에게 일정 비율의 여유 공간이 있다고 파악되면 기기는 super에서 이 공간을 편안하게 줄일 수 있습니다. 즉, 기기가 super를 충분히 크게 하여 /data가 필요하지 않다고 보장할 수 있습니다.

다음은 이러한 변수에 따라 super 파티션 크기를 조정하는 데 도움이 되는 몇 가지 모델입니다.

/data 사용

가상 A/B는 /data 크기를 늘리기 위해 super 축소를 유도합니다. 업데이트 중에는 이러한 공간 중 일부가 필요합니다. 업데이트 가능성에 미치는 영향을 이해하려면 시간이 지남에 따라 일정량의 여유 공간이 확보될 가능성이 있는 기기의 비율을 파악하는 것이 중요합니다. 그 숫자는 기기 하드웨어 및 기기의 사용자 동작에 따라 크게 달라집니다. 아래 예에서는 이 번호를 AllowedUserdataUse라고 합니다.

압축을 사용하지 않음

압축하지 않으면 전체 OTA는 OS와 거의 같은 크기의 스냅샷이 필요하므로 super 크기를 조정할 때 이 점을 고려해야 합니다.

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)

예를 들어, 팩토리 크기가 4GB이고 예상되는 성장률이 50%이며 거의 모든 사용자가 1GB의 여유 공간을 확보하거나 업데이트를 위해 최대 1GB까지 확보할 의향이 있는 가상 A/B 기기를 가정합니다. 이 기기의 경우 super의 크기를 다음과 같이 지정할 수 있습니다.

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)

따라서 이 기기에는 11GB의 super 파티션이 있어야 합니다.

압축 사용

압축 시 전체 OTA는 OS 크기의 약 70% 정도 되는 스냅샷이 필요합니다.

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)

예를 들어, 팩토리 크기가 4GB이고 예상되는 성장률이 50%이며 거의 모든 사용자가 1GB의 여유 공간을 확보하거나 업데이트를 위해 최대 1GB까지 확보할 의향이 있는 가상 A/B 압축으로 구성된 기기를 가정합니다. 이 기기의 경우 super의 크기를 다음과 같이 지정할 수 있습니다. 

  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

따라서 이 기기에는 9.2GB super 파티션이 있어야 합니다.

/data를 사용하지 않음

/data에 스냅샷 공간이 필요하지 않은 OTA를 만들려는 경우 super 크기 조정이 간단합니다.

압축을 사용하지 않음

압축하지 않은 가상 A/B 기기 또는 일반 A/B 기기에서 다음을 실행합니다.

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = FinalDessertSize * 2

예를 들어, 팩토리 크기가 4GB이고 예상되는 성장률이 50%인 가상 A/B 기기를 가정해 보겠습니다. 이 기기에서 OTA 스냅샷에 /data를 사용하지 않도록 하려면 다음과 같이 계산합니다.

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = FinalDessertSize * 2 = 12GB

따라서 이 기기에는 12GB super 파티션이 있어야 합니다.

압축 사용

압축을 사용하는 가상 A/B 기기의 경우 다음을 실행합니다.

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = FinalDessertSize + FinalOTASnapshotSize

예를 들어, 팩토리 크기가 4GB이고 예상되는 성장률이 50%인 가상 A/B 압축 기기를 가정해 보겠습니다. 이 기기에서 OTA 스냅샷에 /data를 사용하지 않도록 하려면 다음과 같이 계산합니다.

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = 6GB + 4.2GB = 10.2GB

따라서 이 기기에는 10.2GB super 파티션이 있어야 합니다.

주의사항

팩토리 크기가 4GB이고 최종 업데이트가 5GB인 경우 super가 10GB가 아닌 9GB여야 할 수도 있습니다. 그러나 첫 번째 업데이트와 최종 업데이트가 모두 5GB이면 최종 업데이트에서 super의 공간이 충분하지 않을 수 있습니다. 위 수식은 파티션이 언제든지 증가할 수 있다고 가정합니다. 최종 업데이트를 적용하는 데 필요한 공간은 첫 번째 업데이트를 적용하는 데 필요한 공간과 동일할 수 있습니다.

압축 비율은 추정치입니다. OS 이미지는 콘텐츠에 따라 압축이 더 잘 되거나 잘 안 될 수 있습니다. EROFS와 같은 압축된 파일 시스템을 사용하면 가상 A/B의 추가 압축은 반환 값이 감소합니다. 이 경우에는 압축되지 않은 수식 중 하나를 가이드라인으로 사용하는 것이 좋습니다.

측정

위 예에서 FinalDessertSize 값을 찾으려면 모든 동적 파티션의 크기를 합산합니다. AOSP 동적 파티션 이미지는 다음과 같습니다.

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

희소하지 않은 이미지를 기반으로 크기를 계산해야 합니다. Android 12 이하를 빌드할 때 기본적으로 이미지는 희소이며 simg2img로 희소하지 않을 수 있습니다.

OTA 패키지에서 파티션 크기를 계산할 수도 있습니다. 이렇게 하면 각 파티션의 가상 A/B 스냅샷 크기도 예측됩니다.

  python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip

또는 OTA 분석 도구를 사용할 수 있습니다. 이 도구는 파일을 업로드하지 않고 로컬에서 OTA 패키지를 분석합니다.

ExpectedGrowth 값을 확인하려면 이전에 출시된 기기를 사용하세요. 가장 초기의 기기와 최근 기기의 super 이미지를 사용하여 성장률을 계산합니다.