Prawidłowy rozmiar super partycji jest ważny dla możliwości aktualizacji urządzenia. Rozmiar ma bezpośredni wpływ na liczbę aktualizacji, które urządzenie może pobrać i ilu użytkowników może pomyślnie pobrać te aktualizacje.
Należy wziąć pod uwagę kilka ważnych zmiennych. Pierwszy to rozmiar fabryczny , czyli rozmiar wszystkich partycji dynamicznych podczas pierwszego flashowania urządzenia. Drugi to tempo wzrostu , czyli procent wzrostu rozmiaru systemu operacyjnego w ciągu całego okresu aktualizacji urządzenia.
Ponadto wirtualne urządzenia A/B mogą podczas aktualizacji wykorzystywać miejsce w katalogu /data , co należy wziąć pod uwagę przy ustalaniu rozmiaru pliku super . Jeśli potrzeba zbyt dużo miejsca na /data , niektórzy użytkownicy nie mogą (lub nie chcą) pobrać aktualizacji. Jeśli jednak wiadomo, że większość użytkowników ma pewien procent wolnego miejsca, urządzenia mogą wygodnie odjąć to miejsce od super . Lub urządzenia mogą zagwarantować, że /data nigdy nie będzie potrzebne, po prostu tworząc wystarczająco duży super .
Poniżej znajduje się kilka modeli pomagających w określeniu rozmiaru super partycji w oparciu o te zmienne.
Poleganie na /data
Virtual A/B zachęca do zmniejszania super , aby umożliwić zwiększenie rozmiaru /data . Część tego miejsca jest potrzebna podczas aktualizacji. Aby zrozumieć wpływ na możliwość aktualizacji, należy wiedzieć, jaki procent urządzeń będzie prawdopodobnie mieć taką ilość wolnego miejsca w miarę upływu czasu. Ustalenie tej liczby w dużym stopniu zależy od sprzętu i zachowań użytkowników tego urządzenia. W poniższych przykładach numer ten nosi nazwę AllowedUserdataUse .
Bez kompresji
Bez kompresji, pełna OTA potrzebuje migawki mniej więcej tego samego rozmiaru co system operacyjny, więc należy to wziąć pod uwagę przy doborze super :
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)
Weźmy na przykład wirtualne urządzenie A/B o fabrycznym rozmiarze 4 GB, oczekiwanym wzroście na poziomie 50% i wiedzy, że prawie wszyscy użytkownicy mają 1 GB wolnego miejsca (lub są skłonni zwolnić do 1 GB miejsca na aktualizację) . W przypadku tego urządzenia super można mieć następujące rozmiary:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)
Dlatego to urządzenie powinno mieć super partycję o pojemności 11 GB.
Z kompresją
Przy kompresji pełna OTA wymaga migawki o wielkości 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 wirtualną kompresją A/B, o fabrycznym rozmiarze 4 GB, oczekiwanym wzroście na poziomie 50% i wiedzy, że prawie wszyscy użytkownicy mają 1 GB wolnego miejsca (lub są gotowi zwolnić do 1 GB miejsca na aktualizacja). W przypadku tego urządzenia super można mieć następujące rozmiary:
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
Zatem to urządzenie powinno mieć super partycję o pojemności 9,2 GB.
Bez polegania na /data
Jeśli chcesz mieć OTA, które nigdy nie wymagają miejsca na migawkę w /data , super dobór rozmiaru jest prosty.
Bez kompresji
W przypadku wirtualnego urządzenia A/B bez kompresji lub normalnego urządzenia A/B:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = FinalDessertSize * 2
Rozważmy na przykład wirtualne urządzenie A/B o fabrycznym rozmiarze 4 GB i oczekiwanym wzroście o 50%. Aby mieć pewność, że to urządzenie nigdy nie użyje /data do migawek OTA, jego obliczenia będą wyglądać następująco:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = FinalDessertSize * 2 = 12GB
Dlatego to urządzenie powinno mieć super partycję o pojemności 12 GB.
Z kompresją
W przypadku wirtualnego urządzenia A/B z kompresją:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = FinalDessertSize + FinalOTASnapshotSize
Rozważmy na przykład wirtualne urządzenie do kompresji A/B o fabrycznym rozmiarze 4 GB i oczekiwanym wzroście o 50%. Aby mieć pewność, że to urządzenie nigdy nie użyje /data do migawek OTA, jego obliczenia będą wyglądać następująco:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB Super = 6GB + 4.2GB = 10.2GB
Zatem to urządzenie powinno mieć super partycję o pojemności 10,2 GB.
Zastrzeżenia
Kuszące może być zaobserwowanie, że jeśli rozmiar fabryczny wynosi 4 GB, a ostateczna aktualizacja to 5 GB, wówczas super musi mieć 9 GB, a nie 10 GB. Jeśli jednak zarówno pierwsza, jak i ostatnia aktualizacja zajmują 5 GB, miejsce w formacie super może być niewystarczające na ostateczną aktualizację. Powyższe wzory zakładają, że wzrost partycji może nastąpić w dowolnym momencie. Miejsce potrzebne do zastosowania ostatniej aktualizacji może być takie samo, jak wymagane do zastosowania pierwszej aktualizacji.
Należy pamiętać, że współczynniki kompresji są wartościami szacunkowymi. Obraz systemu operacyjnego może kompresować się lepiej lub gorzej, w zależności od jego zawartości. Jeśli używasz skompresowanego systemu plików, takiego jak EROFS, dodatkowa kompresja z Virtual A/B przynosi malejące zyski. W takim przypadku lepiej jest zastosować jedną z nieskompresowanych formuł jako wytyczną.
Zmierzenie
Aby znaleźć wartość FinalDessertSize w powyższych przykładach, dodaj razem rozmiary wszystkich partycji dynamicznych. Obrazy partycji dynamicznych AOSP to:
-
system.img -
vendor.img -
product.img -
system_ext.img -
vendor_dlkm.img -
system_dlkm.img
Pamiętaj, aby obliczyć rozmiar na podstawie niesparsowanych obrazów. Podczas tworzenia systemu Android 12 lub starszego obrazy są domyślnie sparsowane i można je usunąć za pomocą simg2img .
Możliwe jest również obliczenie rozmiarów partycji z pakietu OTA. Spowoduje to również oszacowanie rozmiaru wirtualnej migawki A/B dla każdej partycji:
python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip
Możesz też skorzystać z narzędzia analitycznego OTA . To narzędzie nie przesyła żadnych plików i lokalnie analizuje pakiety OTA.
Aby znaleźć wartość ExpectedGrowth , użyj wcześniej wydanego urządzenia. Do obliczenia wzrostu użyj najwcześniejszego i najnowszego super .