Rozmiar super partycji

Prawidłowe określenie rozmiaru partycji super ma znaczenie dla możliwości aktualizacji urządzenia. Rozmiar ma bezpośredni wpływ na to, ile aktualizacji może pobrać urządzenie i ile użytkowników może je pobrać.

Trzeba wziąć pod uwagę kilka ważnych zmiennych. Pierwszy to rozmiar fabryczny, czyli rozmiar wszystkich partycji dynamicznych w momencie pierwszego zaflashowania urządzenia. Drugim jest tempo wzrostu, czyli procentowy wzrost rozmiaru systemu operacyjnego w całym okresie możliwości aktualizacji urządzenia.

Dodatkowo urządzenia wirtualne A/B mogą korzystać z miejsca na /data podczas aktualizacji. Należy to wziąć pod uwagę podczas określania rozmiaru super. Jeśli na potrzeby /data potrzeba zbyt dużo miejsca, niektórzy użytkownicy nie będą mogli (lub nie będą chcieli) zaakceptować aktualizacji. Jeśli jednak wiadomo, że większość użytkowników ma pewien procent wolnego miejsca, urządzenia mogą wygodnie odjąć tę przestrzeń z super. Urządzenia mogą też zagwarantować, że /data nigdy nie będzie potrzebna, po prostu przez zwiększenie super.

Poniżej znajdziesz kilka modeli, które pomogą Ci określić rozmiar partycji super na podstawie tych zmiennych.

Używanie /data

Wirtualny test A/B zachęca do zmniejszenia super, aby umożliwić zwiększenie rozmiaru /data. Część tego miejsca jest potrzebna podczas aktualizacji. Aby zrozumieć wpływ na możliwość aktualizacji, musisz wiedzieć, jaki odsetek urządzeń ma taką ilość wolnego miejsca w czasie. Określedzenie tej liczby zależy w dużej mierze od sprzętu urządzenia i zachowania użytkowników. W przykładach poniżej ten numer jest oznaczany jako AllowedUserdataUse.

Bez kompresji

Bez kompresji pełna aktualizacja OTA wymagająca użycia zrzutu ekranu musi mieć mniej więcej taki sam rozmiar jak system operacyjny, dlatego należy to wziąć pod uwagę przy określaniu rozmiaru super:

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

Rozważmy na przykład urządzenie z Virtual A/B o fabrycznym rozmiarze 4 GB, którego rozmiar ma wzrosnąć o 50%. Wiemy też, że prawie wszyscy użytkownicy mają 1 GB wolnego miejsca (lub są gotowi zwolnić do 1 GB miejsca na potrzeby aktualizacji). W przypadku tego urządzenia super może mieć taki rozmiar:

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

Dlatego na tym urządzeniu powinna być partycja super o rozmiarze 11 GB.

Z kompresją

Po skompresowaniu pełny OTA potrzebuje zrzutu o rozmiarze około 70% rozmiaru systemu operacyjnego:

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

Rozważmy na przykład urządzenie skonfigurowane z kompresją wirtualnego A/B, którego rozmiar w fabrycznym stanie wynosi 4 GB, a spodziewany wzrost – 50%. Wiemy też, że prawie wszyscy użytkownicy mają 1 GB wolnego miejsca (lub są gotowi zwolnić do 1 GB miejsca na potrzeby aktualizacji). W przypadku tego urządzenia super może mieć taki rozmiar:

  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

Dlatego na tym urządzeniu powinna być partycja super o rozmiarze 9, 2 GB.

Bez korzystania z polecenia /data

Jeśli chcesz, aby OTA nigdy nie wymagały miejsca na /data, rozmiar super będzie prosty.

Bez kompresji

W przypadku urządzenia z wirtualnym testem A/B bez kompresji lub zwykłego testu A/B:

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

Załóżmy na przykład, że urządzenie Virtual A/B ma fabryczny rozmiar 4 GB i oczekiwany wzrost o 50%. Aby mieć pewność, że to urządzenie nigdy nie będzie używać /data do zrzutów OTA, obliczenia będą wyglądać tak:

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

Dlatego na tym urządzeniu powinna być partycja super o rozmiarze 12 GB.

Z kompresją

W przypadku urządzenia z wirtualnym testem A/B z kompresją:

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

Rozważ np. urządzenie do kompresji Virtual A/B o fabrycznym rozmiarze 4 GB i oczekiwanym wzroście o 50%. Aby mieć pewność, że to urządzenie nigdy nie będzie używać /data do migawek OTA, obliczenia będą wyglądać tak:

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

Dlatego na tym urządzeniu powinna być partycja super o rozmiarze 10, 2 GB.

Uwagi

Możesz pomyśleć, że skoro rozmiar fabryczny to 4 GB, a ostateczna aktualizacja to 5 GB, to super musi wynosić 9 GB zamiast 10 GB. Jeśli jednak pierwsza i ostatnia aktualizacja mają po 5 GB, to super może nie mieć wystarczającej ilości miejsca na ostatnią aktualizację. Podane powyżej wzory zakładają, że podział może nastąpić w dowolnym momencie. Miejsce potrzebne do zastosowania końcowej aktualizacji może być takie samo jak wymagane do zastosowania pierwszej aktualizacji.

Pamiętaj, że współczynniki kompresji są wartościami szacowanymi. Obraz systemu operacyjnego może być lepiej lub gorzej skompresowany w zależności od zawartości. Jeśli używasz skompresowanego systemu plików, takiego jak EROFS, dodatkowe skompresowanie za pomocą funkcji Virtual A/B przynosi coraz mniejsze korzyści. W takim przypadku lepiej użyć jako wskazówki jednej z formuł bez kompresji.

Obliczanie rozmiaru

Aby znaleźć wartość FinalDessertSize w powyższych przykładach, zsumuj rozmiary wszystkich dynamicznych partycji. Obrazy dynamicznych partycji AOSP:

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

Pamiętaj, aby obliczyć rozmiar na podstawie nieprzetworzonych obrazów. Podczas kompilowania Androida 12 lub starszego obrazy są domyślnie rozproszone i można je odparsować za pomocą simg2img.

Rozmiary partycji można też obliczyć na podstawie pakietu OTA. Dzięki temu możesz też oszacować rozmiar migawki z testu A/B dla poszczególnych partycji:

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

Możesz też użyć narzędzia do analizy OTA. To narzędzie nie przesyła żadnych plików i analizuje pakiety OTA lokalnie.

Aby znaleźć wartość ExpectedGrowth, użyj wcześniej wydanego urządzenia. Aby obliczyć wzrost, użyj pierwszego i najnowszego obrazu super.