Wielu użytkowników nie tylko MIUI, ale i innych nakładek, często i gęsto porusza temat aktualizacji Androida, przede wszystkim pytając się “kiedy aktualizacja do Androida X trafi na mój telefon?”. Wydawałoby się, że sprawa jest prosta: producenci stosują swoje zmiany, dodają aplikacje Google, testują te zmiany i publikują aktualizację, prawda? Oczywiście tak nie jest. Proces aktualizacji to temat żmudny i czasochłonny, lecz wiele osób o tym zwyczajnie nie wie.
Przyznam się, że sam również często upraszczałem cały proces wydawania aktualizacji; znając bowiem cykl wydawania chińskich wersji MIUI, gdzie wersje dzienne wydawane są cztery razy w tygodniu, a wydania stabilne pojawiają się zazwyczaj co kilka tygodni, często można odnieść wrażenie, że wydanie wersji globalnej, z usługami Google, nie powinno trwać aż tak długo. Myślę, że nie tylko dla mnie ciekawą i pouczającą lekturą będzie artykuł Kuby Wojciechowskiego (@Za_Raczke) poświęcony całemu procesowi wydawania aktualizacji, którego polski przekład znajdziecie poniżej. W swojej angielskiej wersji został on opublikowany na portalu Medium, a tłumaczenie zamieszczam dzięki uprzejmości autora.
Kuba to 18-letni uczeń i developer. Od kilku lat działa w społeczności Androida; tworzył on nieoficjalne oprogramowanie, czyli tzw. custom ROM-y, dla różnych urządzeń, takich jak POCO X3, Mi A3 czy Leeco Le 2. Dzięki swojej pracy poznał wiele różnych osób, od których dowiedział się różnych rzeczy dotyczących właśnie aktualizacji, ich źródeł czy związanych z nimi dokumentów. Tym wszystkim podzielił się w artykule, który będziecie mieli okazję za chwilę przeczytać.
Artykuł można także pobrać w wersji PDF.
Mała uwaga przed przeczytaniem: większość przytoczonych tu analiz i faktów nie ma swojego oparcia w powszechnie dostępnych źródłach. Tylko w ten sposób mógł powstać zarówno oryginalny artykuł, jak i to polskie tłumaczenie. Większość zagadnień poruszonych tutaj opiera się na różnego rodzaju umowach poufności.
Autor chciałby serdecznie podziękować za pomoc przy opracowywaniu artykułu, w szczególności kilku osobom: Hussonowi Pierre-Hugues (@phhusson), Mishaalowi Rahmanowi (@MishaalRahman), Kacprowi Skrzypkowi (@kacskrz), yshalsager (@yshalsager) oraz innym, którzy w jakikolwiek sposób przyczynili się do powstania tego dzieła.
Tło tematu
Osobom, które chcą zapoznać się z opisem Project Treble przeznaczonym dla mniej technicznych użytkowników, polecam artykuł Mishaala Rahmana poświęcony tej kwestii (po angielsku).
Nie możemy przejść do obecnego stanu rzeczy bez odrobiny lekcji historii Androida. Jeśli masz niezbędną wiedzę w tej materii, tę sekcję możesz śmiało pominąć.
Android 8 był najważniejszą aktualizacją wydaną w całej jego historii. Nie oferowała ona co prawda niczego rewolucyjnego pod kątem interfejsu użytkownika, lecz zmieniła fundamentalnie to, jak tworzony był Android jako platforma. Przed opublikowaniem wersji Oreo nie było bowiem szans na to, aby oddzielić od siebie komponenty związane z samym systemem, jak np. aplikacje, oraz warstwy abstrakcji przeznaczone pod konkretny hardware. Wszystko było ze sobą ściśle złączone, co sprawiało na przykład, że interfejsy między poszczególnymi warstwami abstrakcji były dość niestabilne i często zmieniały się z wersji na wersję Androida. Jak łatwo się domyślić, sprawiało to spory bałagan i utrudniało rozwój tej platformy dla konkretnego sprzętu.
Wraz z publikacją Androida 8 Google stwierdziło „Dość!” i postanowiło dokonać znaczącej zmiany w sposobie funkcjonowania systemu. Założenie było następujące: zamiast twardego połączenia przy użyciu chwiejnego interfejsu, zdecydowano się zrobić coś zupełnie przeciwnego. Komponenty po stronie systemu będą eksponować stabilny zestaw wersjonowanych interfejsów, które są niezbędne do uzyskania funkcjonalności na poziomie programowym. Nowy obraz o nazwie „vendor” zawierałby natomiast cały kod specyficzny dla sprzętu i implementowałby wszystkie niezbędne interfejsy do działania systemu dla danego urządzenia. W ten sposób rozwój tego obrazu nie miałby aż tak dużego wpływu jak dawniej na to, co dzieje się w samym systemie. Android wspierałby w swoich nowszych wersjach nawet starsze wersje interfejsów, co pozwoliłoby na aktualizowanie Androida bez konieczności jednoczesnego aktualizowania partycji vendor! Tak właśnie powstał tzw. Project Treble.
Dodatkowym efektem tego działania było to, że każdy zgodny z Project Treble obraz partycji vendor mógł działać z KAŻDYM obrazem systemu eksponującym te same interfejsy. Tak właśnie narodziły się tzw. generyczne obrazy systemu (GSI).
Był jednak jeden szkopuł: pomimo iż GSI wspierające starsze wersje obrazów vendor istniały nawet w tamtym czasie, Google wciąż wymagało od producentów smartfonów aktualizacji tejże partycji, aby dopasować ją do nowych wersji systemu Android, aż do niedawnych aktualizacji (o czym w dalszej części artykułu). Nawet pomimo tego faktu Treble zrewolucjonizowało jednak rozwój Androida i wyznaczyło nowy kierunek dla całej platformy.
Aktualizacje zabezpieczeń
Ogólnie rzecz biorąc, poprawki bezpieczeństwa można podzielić na dwa typy:
- HLOS (High Level Operating System), dotyczące samego Androida oraz jądra Linuksa,
- NON-HLOS, które dotyczą kodu działającego na znacznie niższym poziomie.
Błędy NON-HLOS są rzadsze i mogą wyrządzić znacznie więcej szkód. Zależy to jednak od konkretnego przypadku, ponieważ takich rzeczy nie da się w żaden sposób porównać między sobą.
Android X… to nie zawsze Android X, czyli aktualizacje co kwartał
Kwartalne aktualizacje platformy (w skrócie QPR) to duże poprawki do poszczególnych wersji Androida. Łatają one zauważone błędy, a także wprowadzają ulepszenia dotyczące stabilności oraz drobne dodatki do niektórych funkcji. Zazwyczaj w trakcie cyklu życia danej wersji Androida notowane są trzy takie wydania, a pierwsze z nich publikowane jest w grudniu. Wersja „QPR1″ często wnosi najważniejsze zmiany, a przede wszystkim naprawia błędy występujące zazwyczaj w pełnych bugów, początkowych wersjach danego Androida poprzez przepisanie na nowo wszystkich zmian zawartych w danej rewizji systemu.
Ostatnio Google zaczął stosować aktualizacje kwartalne jako część tzw. Pixel Feature Drops, czyli większych pakietów przeznaczonych dla urządzeń Google Pixel (choć głównie skupiają się one na nowych funkcjach zawartych w usługach Google’a, a nie na samym Androidzie).
Wersje QPR nie są obowiązkowe do wdrożenia przez producentów telefonów: mogą oni używać oprogramowania „bazowego” tak długo, jak długo integrują wymagane poprawki bezpieczeństwa. Głównie ze względu na brak takiego wymagania rzadko wydają oni zatem aktualizacje QPR. Biorąc pod uwagę zazwyczaj fatalny stan początkowych wydań niemal każdego wypuszczonego do tej pory Androida, należałoby uznać to działanie za co najmniej wstydliwe.
Mocno promowany Android 12L (wewnętrznie „Sv2″) jest tak naprawdę tylko aktualizacją „QPR2” dla Androida 12 (co oznacza, że zostanie ona finalnie wydana już w marcu bieżącego roku). Przynosi ona bezprecedensową ilość zmian, jeśli chodzi o wydania QPR, w tym wiele poprawek błędów, ogromne ulepszenia dla urządzeń z dużymi ekranami takich jak tablety czy składane smartfony, nowe funkcje, a nawet zmieniony poziom SDK (Android 12 ma poziom SDK 31, zaś 12L – 32).
Czy Twój Android to tak naprawdę ten sam Android, co gdzieś indziej?
Nawet jeśli wydaje Ci się, że Twój telefon działa na „czystym” Androidzie (czyli takim, jakim określa się AOSP), to prawda jest zazwyczaj zupełnie inna.
Wszyscy główni producenci procesorów utrzymują swoje własne modyfikacje dostarczanego przez Google kodu Android Open Source Project (AOSP). Jak to zazwyczaj działa? Producent procesora stosuje swoje zmiany w ramach posiadanego przez siebie zmodyfikowanego kodu AOSP, a Google pomaga mu później zintegrować nowe aktualizacje Androida (czyli poprawki bezpieczeństwa, wydania QPR i główne aktualizacje platformy) z tym zmodyfikowanym kodem w ramach współpracy zwanej „Keystone”.
Jedną z najbardziej znanych odmian AOSP jest ta utrzymywana przez Qualcomma — powszechnie określana jako „Codeaurora” lub „CAF”. Obecna „gałąź” tego kodu została zapoczątkowana gdzieś w okolicach Androida 9. Od tego czasu wszystkie nowe aktualizacje platformy Google’a są wydawane na jej podstawie. Taka polityka prowadzi czasem do różnych błędów czy niechlujnego, bądź niekompatybilnego z samym AOSP kodu, lecz pozwala również wprowadzić pewne ulepszenia, takie jak lepsze wsparcie dla operatorów lub wzrost wydajności w niektórych scenariuszach.
Należy zaznaczyć, że chociaż większość producentów smartfonów używa zmodyfikowanych wersji Androida dostarczanych przez dostawców procesorów, nie jest to wymóg. Jeśli tylko twórcy smartfonów tego zapragną, mogą bezpośrednio wykorzystywać w swoim oprogramowaniu kod AOSP.
Notacja “N+x”
W tym artykule będę używał notacji „N+x”. Jest ona wykorzystywana wśród niektórych geeków, gdy mówi się właśnie o aktualizacjach. Zatem: co ona oznacza? Sygnalizuje ona, ile aktualizacji platformy zostało wydanych na dane urządzenie.
Posłużę się przykładem. Jeśli urządzenie zostało zaprezentowane z Androidem 9 na pokładzie i ostatnią wersją Androida, jaką otrzymało, był Android 11, możemy powiedzieć, że zostało ono zaktualizowane do wersji N+2 (ponieważ otrzymało aktualizację do Androida 10 i Androida 11). Można również zastąpić „N” wersją bazową Androida, aby obliczyć ostatnią opublikowaną aktualizację, np. 9+2=11.
Skoro mamy już powtórkę za sobą, przejdźmy do właściwej części tego artykułu, czyli samego procesu aktualizacji.
Proces aktualizacji
Dostępność kodu źródłowego
Pierwszym tematem, który jest powszechnie niezrozumiany w kwestii aktualizacji, jest dostęp producentów telefonów do kodu źródłowego przed jego oficjalnym wydaniem. Temat jest trochę skomplikowany, więc podzieliłem go na 3 części.
Poprawki bezpieczeństwa
Jak być może wiesz, publiczne biuletyny bezpieczeństwa Androida są zazwyczaj wydawane w pierwszy poniedziałek miesiąca. Często też pojawiają się wtedy już pierwsze aktualizacje zawierające właśnie te poprawki. Powstaje zatem pytanie: kiedy producenci smartfonów mają dostęp do ich wersji poglądowych i mogą je zaimplementować?
Aby odpowiedzieć na to pytanie, najpierw trzeba wiedzieć, że istnieją 2 „warianty” biuletynów bezpieczeństwa: YYYY-MM-01 i YYYY-MM-05. Pierwszy z nich zawiera tylko poprawki po stronie kodu AOSP, podczas gdy drugi niesie również poprawki od partnerów takich jak Qualcomm czy MediaTek. Producenci mogą wydać dowolny z nich, jednak jeśli wybiorą oni wersję -01, nadal będą musieli dostosować się do zmian z aktualizacji -05 z poprzedniego miesiąca (przykład: producent wypuszcza wersję 2021-12-01, a następnie 2022-01-01 w następnym miesiącu — wtedy styczniowa aktualizacja musi być zgodna także ze zmianami z wariantu 2021-12-05).
Mając to wszystko na uwadze, przejdźmy w końcu do odpowiedzi na postawione pytanie. Łatki AOSP są wydawane w pierwszej kolejności w ramach biuletynów partnerskich. Ramy czasowe wydawania poszczególnych wydań są bardzo różne w poszczególnych miesiącach, ale ogólnie rzecz biorąc, pierwsza wersja poglądowa poprawek jest publikowana w pierwszym lub drugim tygodniu poprzedzającego je miesiąca. Nie jest to jednak ostateczna rewizja: może ona jeszcze ulec zmianie, jeśli zostaną znalezione nowe problemy o dużym znaczeniu.
Jeśli natomiast chodzi o łatki od partnerów, nie ma sztywnego harmonogramu. Mogą oni wydać poprawki, kiedy tylko chcą. W przypadku niektórych z nich, na przykład Qualcomma, gdzie jest wiele platform dzielących sporo kodu (i luk), producenci smartfonów mogą nawet nie otrzymać poprawek przed zniesieniem na nie embarga!
Takowe embargo jest znoszone zazwyczaj o godzinie 11:00 czasu pacyficznego wybranego dnia. Wtedy producenci mogą zacząć mówić o łatkach i wypuszczać swoje kompilacje. Czasami daty embarga są łamane przez niektórych producentów; częstym przypadkiem pod tym względem jest Samsung. Nie oznacza to jednak, że są oni szybsi od Google’a, lecz tylko to, że nie przestrzegają oni ustalonej daty embarga.
Google dodaje poprawki bezpieczeństwa Androida w ramach starszych wersji platformy przez 3 lata od momentu ich wydania, przynajmniej w przypadku systemu mobilnego (o czym wspomniano w tym dokumencie Android Automotive).
Aktualizacje wersji Androida
Większość osób będzie zainteresowana zapewne przede wszystkim tym elementem aktualizacji. Niemal każdy chce przecież mieć jak najwyższą wersję w Informacjach o telefonie. Za tym „numerkiem” idą jednak konkretne rzeczy, jakie musi zrobić producent.
Takie aktualizacje są bowiem znacznie trudniejsze do dostosowania i przeniesienia na urządzenia niż regularne poprawki bezpieczeństwa. Google utrzymuje je w większej tajemnicy i angażuje w cały proces tylko niektórych producentów smartfonów. Spójrzmy na przykładową oś czasu wydania kodu źródłowego właśnie dla nich.
- Okolice grudnia — duże firmy współpracujące blisko z Google otrzymują bezpośredni dostęp do źródła nowej wersji systemu. Szczegóły tego typu wydania są w dużej mierze nieznane, ale najprawdopodobniej jest ono ograniczone do największych graczy na rynku. W tym momencie kolejna rewizja Androida jest wciąż w bardzo początkowej fazie, a większość funkcji dopiero zaczyna być rozwijana.
- Okolice marca — producenci smartfonów mogą zacząć ubiegać się o dostęp do źródeł dostawców procesorów. Ten rodzaj umowy nazywany jest „keystone”; podpisuje ją producent telefonu, Google i dostawca procesora (np. Qualcomm). To najczęstszy sposób uzyskiwania kodu. Aby móc zawrzeć taki kontrakt, istnieje kilka drobnych warunków (głównie dotyczących harmonogramu aktualizacji), ale nie jest to nic trudnego. Dzięki niemu producent smartfona uzyskuje dostęp do kodu źródłowego Androida tworzonego przez producenta procesora (np. wcześniej wspomniany „CAF” dla Qualcomma czy „MocorDroid” dla Unisoc), a ponadto otrzymuje niezmodyfikowany kod AOSP dla danego wydania oraz inne oprogramowanie producenta niezbędne do uruchomienia danej rewizji Androida (potocznie nazywane „BSP”). Kod źródłowy można uzyskać również bezpośrednio od Google’a w ramach programu „Early Access Preview”, jednak większość producentów smartfonów decyduje się na wspomnianą wcześniej pierwszą metodę.
- Okolice lipca — twórcy smartfonów otrzymują dostęp do wersji poglądowych zestawów testowych, aby móc przygotować swoje oprogramowanie do procesu certyfikacji Google.
- Okolice daty finalnej premiery nowej wersji Androida — publikowane są ostateczne wersje testów zgodności.
Producenci mogą poprosić Google’a o pozwolenie na korzystanie z wersji poglądowych testów zgodności dla ostatecznej kompilacji, tak aby móc ją opublikować w dniu premiery nowej wersji Androida.
Jak zatem widać, jeśli producenci wezmą się do roboty wystarczająco wcześnie, bez problemu mogą z wyprzedzeniem przygotowywać swoje aktualizacje Androida.
Wersje QPR
Jak wspomniałem wcześniej, wydania QPR to główne aktualizacje dla konkretnej wersji Androida wydawane co kwartał. Zazwyczaj przynoszą one poprawki błędów, polepszają jakość kodu i dodają różne pomniejsze funkcje.
W tym roku wersja QPR2 dla Androida 12 została właściwie wypromowana swoją własną nazwą marketingową – 12L, ponieważ wprowadza dużo więcej usprawnień niż zazwyczaj, co potwierdza nawet przeznaczenie dla niej nowej wersji SDK. Dostęp do aktualizacji kwartalnych jest zapewniany bezpośrednio przez Google. Zainteresowani producenci mogą uzyskać dostęp do rozwijanych gałęzi QPR na długo przed ich publicznym wydaniem. Ich finalizowane wersje są często „zamrożone” (nie wprowadza się do nich nowych zmian oprócz naprawiania błędów) na około miesiąc przed ich publikacją. Zazwyczaj wydawane są 3 wydania QPR w ramach danego Androida, a pierwsze z nich wnosi najwięcej zmian. Aktualizacja urządzeń z tymi łatkami nie jest wymagana (12L może być wyjątkiem, ponieważ podnosi poziom API).
Proces certyfikacji
Aby móc opublikować daną kompilację oprogramowania z usługami Google’a, producenci smartfonów muszą dokonać jej certyfikacji.
Testy
Aktualizacja otrzymuje stosowną certyfikację tylko wtedy, gdy w pełni przeszła ona różne testy zgodności.
Takie testy dostępne publicznie to:
- CTS (Compatibility Test Suite) – automatycznie sprawdza on zgodność ze standardowymi API Androida, aby zapewnić pełną kompatybilność aplikacji,
- CTSV (Compatibility Test Suite Verifier) – uzupełnienie CTS; dostarcza on testy, które wymagają ręcznej interwencji człowieka. Musi być uruchamiany tylko raz przy premierze urządzenia oraz przy głównych aktualizacjach platformy,
- VTS (Vendor Test Suite) – testuje interfejsy systemu zaimplementowane w obrazie vendor oraz jądrze producenta smartfona (tu mała uwaga: żadne zbudowane binarki nie są publicznie dostępne, ale sam kod źródłowy jak najbardziej),
- CTS-on-GSI i VTS-on-GSI – te same testy co powyżej, ale uruchamiane na generycznych obrazach systemu, aby zapewnić pełną zgodność po stronie partycji vendor. Na urządzeniach z wersją jądra 5.4 i wyżej konieczne jest uruchomienie ich z dostarczonymi przez Google obrazami boot.img zawierającymi kompilacje jądra GKI (Generic Kernel Image),
- ITS (Image Test Suite, technicznie część CTS) – weryfikuje różne wymagania związane z aparatami, które nie mogą być sprawdzone bez fizycznego testu. Wymaga on specjalnego urządzenia,
- MTS (Mainline Test Suite) – różne testy związane z programem Project Mainline.
Istnieją także testy dostępne wyłącznie dla partnerów Google’a, które również muszą zostać wykonane w celu certyfikacji danej wersji oprogramowania:
- GTS (Google Test Suite) – weryfikuje zgodność z umowami związanymi z GMS, takimi jak MADA (Mobile Application Distribution Agreement),
- BTS (Build Test Suite) – skanuje obrazy systemu, aby odnaleźć potencjalnie niebezpieczne lub złośliwe aplikacje, używając podobnej technologii jak w przypadku Google Play. W przeciwieństwie do pozostałych testów przeprowadzany jest w trybie offline, bez fizycznego urządzenia. Producenci muszą wysłać swój firmware do Google’a w celu jego analizy.
- STS (Security Test Suite) – sprawdza, czy luki, które miały być załatane w zadeklarowanym poziomie poprawek bezpieczeństwa zostały rzeczywiście poprawione.
Cały powyższy zestaw testów określa się często mianem “xTS”.
Proces właściwy
Producenci smartfonów zazwyczaj zaczynają swoją pracę od bazy dostarczonej przez dostawcę procesora. Często jest ona dość dobrze przygotowana, pod kątem pomyślnego przeprowadzenia wszystkich testów i wymaga niewielkiego wysiłku, aby uzyskać pełną zgodność. Jednakże ze względu na ich rozległość nawet proste zmiany mogą spowodować niepowodzenie. Proces certyfikacji przebiega mniej więcej tak:
- Producent przygotowuje nową wersję oprogramowania,
- Opcjonalnie uruchamia on stosowne testy lokalnie,
- W przypadku mniejszych firm kompilacja trafia do firmy zewnętrznej, która sprawdza ją i wysyła stosowne informacje bezpośrednio do Google’a, w przypadku większych firm przeprowadzane są testy we własnym zakresie już oficjalną metodą,
- Po 4-5 dniach otrzymujemy wyniki.
Najgorsze w tym procesie jest to, jak bardzo jest on czasochłonny. Pięć dni — niby niewiele, ale trzeba pamiętać, że w idealnym świecie producenci smartfonów wydawaliby kompilacje na początku każdego miesiąca. Oznacza to, że tak naprawdę mieliby oni tylko 2 tygodnie na zintegrowanie i wewnętrzne przetestowanie poprawek bezpieczeństwa, zanim musieliby je przesłać do formalnych testów.
W przypadku, gdy test nie powiedzie się tam, gdzie powinien (na przykład z powodu niewłaściwej implementacji testu dla konkretnego wymagania przez Google), producent musi złożyć wniosek o „zwolnienie” (tzw. waiver), aby móc go „pominąć” do czasu opublikowania nowej wersji stosownego pakietu. Czas uzyskania takiego zwolnienia różni się w zależności od przypadku.
Testy producentów smartfonów
Poza normalnym testowaniem producenci mogą przeprowadzić własne wewnętrzne testy. Przykładowo Google wyposaża wielu swoich pracowników w telefony Pixel z preinstalowaną kompilacją „dogfood” swojego oprogramowania, a ponadto stworzyło nowy, wewnętrzny zestaw testów o nazwie PTS („Pixel Test Suite”), zaprojektowany między innymi do testowania wydajności, temperatur, bezpieczeństwa (SELinux) i opcji dotyczących ułatwień dostępności.
Inni producenci stosują zupełnie inne podejście i pozwalają użytkownikom testować oprogramowanie przedpremierowo w półprywatny sposób. Przykładem takiej firmy jest Xiaomi z dziennymi i tygodniowymi wydaniami MIUI China (warto zauważyć, że taki cykl testowy nie byłby możliwy na ROM-ie z usługami GMS, ponieważ jego certyfikacja trwa zazwyczaj 5 dni).
Operatorzy…
W wielu krajach, np. w Stanach Zjednoczonych, ludzie nadal kupują urządzenia od swoich operatorów, więc producenci oprogramowania nie mają większego wyboru — muszą zawiązywać z nimi porozumienia, aby uzyskać dobre wyniki sprzedaży swoich urządzeń.
Aby takie urządzenie znalazło się w ofercie danego operatora, producent musi wykonać kilka rzeczy. Po pierwsze, ciąży na nim przygotowanie pełnego briefingu dotyczącego specyfikacji urządzenia i jego docelowej ceny na długo przed proponowaną premierą (zazwyczaj około pół roku wcześniej). Następnie trzeba spełnić mnóstwo wymagań. Niektóre z nich mogą dotyczyć rzeczy związanych z modemem, takich jak wsparcie dla różnych technologii (np. VoNR, VoLTE, niektóre pasma 5G, RCS, specyficzne dla danego regionu techniki połączeń alarmowych itp.), a inne mogą dotyczyć chociażby wbudowania aplikacji operatora, wdrożenia blokady karty SIM (SIM-locka) lub zgodności z różnymi wymogami bezpieczeństwa.
Operatorzy zazwyczaj wymagają tego, aby każdy build był certyfikowany przed jego wydaniem. Zazwyczaj wiąże się to z ponownym sprawdzeniem wyżej wymienionych wymagań i wykonaniem innych zadań specyficznych dla danego operatora.
Przykładowo: jeden z głównych dostawców telefonii komórkowej w USA wymaga od producentów listy wszystkich plików w systemie, wyjaśnienia ich uprawnień, opisania dostępu każdej preinstalowanej aplikacji i przekazania opisu każdej poprawki będącej częścią aktualizacji zabezpieczeń. Inne sieci mogą wymagać wymienienia wszystkich parametrów różnych rzeczy, takich jak obsługiwane funkcje sprzętowe, kodeki czy wsparcie dotyczące technologii radiowych.
Również polscy operatorzy chcą, aby producenci spełnili ich określone wymogi. Na przykład jedna z większych sieci działających na naszym rynku określa między innymi procedury związane z roamingiem krajowym, agregacją pasm czy dodaniem sygnatury określającej, z jakiej sieci pochodzi smartfon, do systemowych aplikacji poczty e-mail. Zastrzega ona także prawo do usunięcia niektórych aplikacji wykonanych przez producenta danego telefonu, jeśli będą one konkurencją dla usług właśnie tej telefonii, a także możliwość umieszczenia przez tę sieć swojego materiału w dowolnym miejscu w systemie, gdy zajdzie taka konieczność. Generalnie jednak, w porównaniu do zachodnich operatorów, wymagań krajowych sieci jest mniej.
Te zastrzeżenia często są nie tylko bezsensowne, ale też bardzo czasochłonne. Dostosowanie się do nich wszystkich nie jest proste, więc nawet producenci, którzy chcą mieć czysty firmware, tacy jak Google, często wydają wiele wariantów oprogramowania, aby spełnić to, czego żądają od nich sieci komórkowe.
Pomimo trudności, z jakimi niewątpliwie się to wiąże, można jakoś poradzić sobie ze zgodnością ze wszystkimi sieciami. O ile rzeczy wymagane przez dane telefonie różnią się między sobą, to w zasadzie lista realnie wymaganych zmian nie jest aż taka duża, żeby uczynić aktualizację niemożliwą.
Jak Google próbuje zachęcić producentów do aktualizacji swoich urządzeń?
Przez lata Google oferowało wiele programów mających na celu poprawę doświadczeń użytkowników urządzeń firm trzecich: Google Play Experience, Android One, a ostatnio program Premier Device. Niektóre z nich miały wymagania dotyczące aktualizacji.
Android One wymagał od producentów smartfonów uaktualniania urządzeń do nowych głównych wersji Androida w ciągu 90 dni od daty ich wydania przez 2 lata (N+2). Wymagał też comiesięcznych aktualizacji bezpieczeństwa przez 3 lata, przy czym każda z nich miała być publikowana w ciągu 45 dni od wydania prywatnego biuletynu (a więc generalnie w pierwszej połowie miesiąca).
W 2019 roku Google (prywatnie) ogłosiło swój program Premier Device. Jest to w zasadzie mniej restrykcyjna wersja Android One z dodatkową korzyścią w postaci dodatkowego 50-procentowego udziału w przychodach z reklam w wyszukiwarce Google (12% versus standardowe 8%). Wymaga on aktualizacji platformy w ciągu 120 dni od daty głównych wydań systemu. Przykłady urządzeń biorących udział w tym programie obejmują wybrane urządzenia Realme, OnePlus, Nokii, Xiaomi czy Motoroli.
Polityka Qualcomma
W tej sekcji opiszę pokrótce politykę aktualizacji stosowaną przez Qualcomma, albowiem jest to wciąż właściwie największy dostawca procesorów mobilnych.
Aktualizacje Qualcomma są (lub były) wciąż dobre
Jedną z rzeczy, o której słyszy się dużo w społeczności Androida jest to, jak bardzo Qualcomm jest źródłem wszelkiego zła i utrudnia aktualizację smartfonów przez ich producentów. Nie jest to prawda. Okres wsparcia oferowany przez Qualcomma jest (lub był) całkiem dobry.
Weźmy na przykład typowy mainstreamowy procesor. Snapdragon 730 to średniopółkowy układ z początku 2019 roku. Został on wydany z Androidem Pie (9). Obecnie nadal jest wspierany przez Androida 12 (N+3) i prawdopodobnie otrzyma również wsparcie dla Androida 13. Oznacza to, że producenci mogliby spokojnie zapewnić standardowo co najmniej 3 duże aktualizacje platformy. Jakie urządzenie ma taki sam cykl aktualizacji? Zgadliście — Google Pixel 6.
Weźmy za przykład inny układ, tym razem pod kątem wsparcia absolutnie niezwykły. Snapdragon 660 został wydany w 2017 roku z Androidem 7.x. Do dziś jest wspierany na Androidzie 12 (choć jest to wsparcie rozszerzone; więcej o tym później). Oznacza to, że ten układ otrzymuje aktualizacje od wersji N do N+6!
Nie przesadzę zatem stwierdzając, że polityka aktualizacji firmy Qualcomm jest (lub była) zawsze co najmniej przyzwoita. Być może zastanawiacie się nad formami przeszłymi, które umieściłem w nawiasach; porozmawiamy o tym później.
Co otrzymuje aktualnie producent?
Licencjobiorcy Qualcomma otrzymują za cenę ogólnej licencji na oprogramowanie (która, według różnych źródeł, waha się od około pół miliona do kilku milionów dolarów) kilka podstawowych rzeczy:
- dostęp do kodu BSP dla oprogramowania po stronie partycji vendor na konkretnej wersji Androida,
- a także BSP dla samego systemu (tzw. QSSI).
Ta konkretna kombinacja ma przejść testy xTS Google’a po wyjęciu z pudełka (i często tak się dzieje). Jednakże producenci mogą również obrać bardziej „ryzykowną” drogę i odrzucić QSSI, zamiast tego decydując się na system oparty na AOSP. Odbiera to korzyści z posiadania przetestowanego już pod kątem testów xTS zestawu i zmusza producenta do portowania części kodu BSP systemu QSSI. To właśnie robią gracze tacy jak Google.
Koniec oficjalnego wsparcia — i co dalej?
Nawet jeśli skończyło się oficjalne wsparcie, a nadal producent chce wspierać dane urządzenie, może on przeportować kod BSP swojego dostawcy procesora ponad kod AOSP. Chociaż nie jest to tak proste jak oficjalne oprogramowanie Qualcomma, wciąż jest wykonalne, i to nawet bez wsparcia dotyczącego pomyślnego przechodzenia testów xTS. Jednym z przykładów takiego podejścia jest Fairphone 2, gdzie firma przeportowała kod BSP Qualcomma oparty na Androidzie 7 do Androida 10.
Płatne wsparcie
Qualcomm oferuje kilka rodzajów dodatkowego, płatnego wsparcia oprogramowania:
- Wsparcie „podstawowe” – Qualcomm zapewnia poprawki bezpieczeństwa dla ostatniego wydania platformy wybranego przez producenta smartfona przez dłuższy czas, być może nawet lata. Ten wariant może czasami zawierać tylko łatki dla części BSP zawierającej firmware.
- Wsparcie „dostosowywalne” – w pełni konfigurowalne. Jednym z klientów korzystających z tego typu wsparcia jest Google, które otrzymuje od Qualcomma gałęzie „.c9″. Nie tylko są one wspierane dłużej, ale także testowane pod kątem budowania na ich bazie kompilacji w ramach AOSP (jako że zarówno partycja vendor, jak i system od Google’a są oparte na kodzie AOSP).
- Wsparcie „platformowe” – Qualcomm zapewnia dodatkowe lata aktualizacji platformy, czasami również zawierające duże zmiany w zakresie publikowanych wersji jądra. Doskonałym tego przykładem jest wspomniany wcześniej Snapdragon 660 po zakończeniu oficjalnego wsparcia na Androidzie 10 (obecnie kod dla tego procesora jest oparty na 6 głównych wersjach Androida, wliczając rozszerzone wsparcie). Z tego co wiemy, taki rodzaj wsparcia często kosztuje nawet milion dolarów na jedną platformę dla danego producenta smartfona (wiele urządzeń może korzystać z tego samego planu rozszerzonego wsparcia, jeśli znajdują się one na tej samej platformie). Jest ono dostępne tylko dla wybranych procesorów.
Podsumowanie: aktualizacje z perspektywy producenta telefonu
Cały proces
Dla aktualizacji zabezpieczeń proces wygląda następująco:
- Otrzymanie poprawek od Google’a, zazwyczaj około pierwszego tygodnia poprzedzającego je miesiąca,
- Integracja poprawek, wykonanie kompilacji,
- Przetestowanie buildu pod kątem regresji, czyli sprawdzenie, czy dokonywane zmiany nie spowodowały, że inna część oprogramowania przestała działać w taki sposób, w jaki została zaprojektowana,
- Przygotowanie i przesłanie wydania do współpracujących z producentem operatorów (bardzo różny czas trwania),
- Wysłanie kompilacji do Google’a w celu certyfikacji (zazwyczaj około 5 dni),
- Opublikowanie aktualizacji.
Dla dużych aktualizacji platformy Androida nieco się on różni:
- Podpisanie umowy, która pozwoli producentowi na dostęp do kodu źródłowego nowej wersji Androida przed jej publicznym wydaniem,
- Integracja swoich zmian z poprzedniej rewizji Androida w ramach rozwijanej gałęzi AOSP,
- Wdrażanie nowych poprawek z kodu AOSP, gdy się one pojawią,
- Rozpoczęcie testowania swoich kompilacji wewnętrznie i/lub zewnętrznie,
- Uruchomienie testów xTS w momencie, gdy Google wyda ich finalne wersje,
- Certyfikacja finalnej kompilacji,
- Opublikowanie aktualizacji.
xSSI, czyli dobry zamysł, który w praktyce się nie udał
Gdzieś w okolicach Androida 9 Google wpadło na pomysł, aby w końcu zacząć wykorzystywać stworzoną wcześniej architekturę Androida z podziałem na partycje vendor i system do stworzenia czegoś, co realnie odciąży producentów smartfonów od wykonywania nadmiarowej pracy.
Mianowicie: zaproponowało ono producentom procesorów oddzielenie docelowych buildów systemu od istniejących obrazów vendor. Pomysł został nazwany „Single System Images”. Mógłby on pozwolić całym liniom urządzeń na uruchomienie dokładnie tego samego obrazu systemu, redukując koszty i niepotrzebne kłopoty z aktualizacją.
Zarówno Qualcomm, jak i MediaTek zaimplementowały ten pomysł (jako „Qualcomm Single System Image”/”QSSI” i „MediaTek Single System Image”/”MSSI”) i… nic. W zasadzie żaden producent smartfonów nie wykorzystał tego schematu, zamiast tego nadal tworząc kompilacje systemu specyficzne dla danego urządzenia.
Jak trudno obecnie aktualizować urządzenie?
Nie jest to trudne. Można nawet rzec, że to bardzo proste. Ogólnie rzecz biorąc, im więcej producent ma zobowiązań (od operatorów, partnerów itp.), tym trudniej, ale nie jest też tak, że w ogóle nie da się tego wykonać. Prawdziwa trudność może polegać przede wszystkim na uzasadnieniu tego działania ekonomicznie. Producent może się pokusić o to, aby zaoszczędzić trochę pieniędzy poprzez przeniesienie inżynierów pracujących nad starszymi projektami do nowych zadań. I wielu graczy niestety to robi. Taka jest smutna prawda o aktualizacjach od wielkich korporacji, takich jak na przykład Motorola/Lenovo.
Jakie zatem problemy nękają teraz Androida?
„Trójkąt miłosny”: Pixel-AOSP-Google
„Pixel to po prostu kolejny producent smartfonów” – to stanowisko, które forsuje Google. Chciałoby, aby wszyscy uwierzyli, że skórka Pixela znajdująca się na samej górze AOSP to „referencyjna implementacja” tego, co mogą zrobić producenci smartfonów. Zatem: czy to prawda?
AOSP jest stworzony przede wszystkim dla Pixeli. Aspekt „otwartości” ma drugorzędne znaczenie w kontekście stworzenia produktu, który Google będzie mogło sprzedawać.
Przykład? Cała sprawa dotycząca Monet/Material You. Cały interfejs Androida został przeprojektowany wokół rozszerzonych możliwości tematycznych. Były one reklamowane jako jedna z flagowych funkcji Androida 12, podczas gdy Google był jedynym graczem, który je posiadał, ponieważ nie wydał kodu odpowiedzialnego za nie innym producentom (aż do niedawna).
Kolejny dowód? Całe fiasko początkowego wydania Androida 12. Ten system był bardzo opóźniony z powodu ogromnych zmian, które przyniósł, a także długotrwałych skutków pandemii. Realnie rzecz biorąc, powinien być nadal przesuwany w czasie i ostatecznie dostarczony w formie, w jakiej zapewne zostanie wydany Android 12L. Jedynym powodem, dla którego Google wydało tę wersję w takim stanie w październiku zeszłego roku, była premiera Pixela 6. Pixel 6 był zaprojektowany pod kątem Androida 12, więc musieli oni opublikować tę rewizję akurat w tym momencie po to, aby móc zaprezentować swój telefon z tym systemem. Efekty, szczególnie na „szóstce”, widać.
Praktycznie wszystkie funkcje w AOSP są opracowane dla Pixeli, a Android 12 został wręcz dosłownie zaprojektowany dla Pixela 6. Nie jest to zatem kolejny producent, jakich wielu — to gigant z nieskończoną przewagą i wkładem w to, co nazywamy „Androidem”.
GRF, czyli niby lepiej… ale nie do końca
Wprowadzenie
Czym jest GRF? To skrót od „Google Requirement Freeze”, lecz zapewne wielu z Was nawet o tej nazwie nie słyszało. Jedyne publiczne źródło, które zagłębia się w to, z czym to się wiąże, to wpis na blogu Google’a.
Jeśli czytaliście ten artykuł do tej pory uważnie, to wiecie, że w celu przeprowadzenia aktualizacji urządzenia z wersji N do N+1 producenci musieli:
- wykonać obraz systemu N+1, który przejdzie testy xTS,
- a także obraz partycji vendor N+1 zgodny z częścią wymagań vendora N+1 i kilkoma wymaganiami z wersji N, na której dane urządzenie rozpoczynało swój żywot.
W zasadzie oznaczało to, że aby przejść z wersji N na N+1, trzeba było zaktualizować cały stos oprogramowania. Google postanowiło to zmienić.
Zamysł jest prosty: pojedynczy obraz vendor zbudowany dla wersji N będzie teraz certyfikowany aż do wersji N+3. Będzie musiał tylko przejść testy dla wersji, dla której został zbudowany oryginalnie (nazywane VSR-N – Vendor Software Requirements for version N). Producenci procesorów będą aktualizować kod BSP dla partycji vendor za pomocą aktualizacji bezpieczeństwa i dostarczać producentom smartfonów BSP dla systemu aż do wersji N+3.
Zauważcie, że producent procesora MOŻE zaktualizować obraz vendor w późniejszym czasie, aby potencjalnie móc dokonać aktualizacji do więcej niż trzech wersji platformy, ale jest mało prawdopodobne, że tak się stanie. Z drugiej strony producenci smartfonów nie są zmuszeni do przyjęcia GRF i zamiast tego mogą sami przeportować partycję vendor do wersji N+x, ale producenci procesorów nie będą ich w tym zakresie wspierać, więc twórcy smartfonów są zdani w tej sytuacji na siebie.
Pierwsze urządzenia z GRF już znajdują się na rynku: wszystkie urządzenia oparte na układach Qualcomma, z wyjątkiem tych opartych na nowym Snapdragonie 8 Gen 1, a także Pixeli, używają obrazu vendor Androida 11 także na Androidzie 12.
Problemy
Po pierwsze, łatwo można zauważyć pewien problem dotyczący premiery nowych telefonów: urządzenia, które zostaną wydane później z procesorem mającym obraz „zamrożony” na Androidzie w wersji N, ale same w sobie będą oparte na Androidzie M=N+1, będą mogły przejść tylko z rewizji M na M+2, ponieważ wybrany układ nie będzie już wspierany w wersjach nowszych niż N+3=M+2. Problem ten tylko wzmacnia fakt, że producenci tacy jak Qualcomm wypuszczają „odświeżenia” chipów, które są w zasadzie tymi samymi procesorami, ale z nieco wyższymi taktowaniami — „okno” wsparcia będzie takie samo jak w przypadku oryginalnej wersji!
O ile wcześniej też tak bywało, o tyle GRF znacznie utrudnia producentom smartfonów samodzielne przedłużanie wsparcia pod kątem oprogramowania. W erze „przed-GRF” byłoby to dość proste: przeportowanie kodu BSP z wersji N+3 do N+4, popracowanie nad przejściem wszystkich nowych testów i gotowe, nic trudnego. Teraz jednak będzie to o wiele trudniejsze, ponieważ producenci muszą w takiej sytuacji przeportować BSP z wersji N aż do N+4. To już 3 wersje wymagań i zmian kompatybilności, o które trzeba się martwić. O ile wcześniej nie było to wielkim problemem, to w tej chwili będzie to stanowić olbrzymie wyzwanie, które dla niejednej dużej firmy może stanowić barierę nie do przejścia, nie mówiąc już o mniejszych graczach.
Po drugie, pamiętacie sekcję dotyczącą Qualcomma, gdzie wspomniałem, że Qualcomm już dostarcza aktualizacje do wersji N+3 dla swoich chipów? No właśnie… Więc o co w tym wszystkim chodzi? Google twierdzi, że chodzi o zmniejszenie kosztów, jakie musi ponieść producent procesora, jednak moim zdaniem to głupota. Producenci smartfonów nadal muszą tworzyć niezbędne rzeczy do aktualizacji, a dostawcy procesorów wykonywali swoją pracę już wcześniej i jakoś korona im z głowy nie spadła (mała dygresja: Qualcomm zarabia 5 miliardów dolarów rocznie i nie może sobie pozwolić na aktualizację 6 platform? Poważnie?). Wyglądałoby więc na to, że Google zdecydowało odgórnie, iż wszystkie urządzenia powinny być wspierane przez co najwyżej 4 lata (lub mniej w większości przypadków), a marże już i tak chciwych dostawców sprzętu powinny jeszcze bardziej wzrosnąć.
Ostatnim (i najważniejszym) problemem jest stagnacja pod względem funkcjonalności. Wyobraźmy sobie scenariusz: mamy urządzenie, którego vendor i system znajdują się na wersji N. Google postanawia zaktualizować warstwę abstrakcji sprzętu odpowiedzialną za aparat w wersji N+1 o nową funkcję, która pozwala na sterowanie intensywnością lampy błyskowej. Jest to banalne do zaimplementowania, gdyż obecna implementacja to w zasadzie tylko „powiedzenie” jądru, aby ustawił on maksymalną jasność diody LED. Zatem urządzenie powinno otrzymać tę funkcję podczas aktualizacji do wersji N+1, prawda? NIE. Zaktualizowana definicja HAL pojawia się tylko w rewizji N+1, więc partycja vendor oparta na wersji N NIE MOŻE jej zaimplementować.
Istnieje już bardzo dobry przykład dotyczący podobnej funkcji w tej chwili: przełącznika dotyczącego sieci 2G. Wymaga on niewielkiej aktualizacji warstwy abstrakcji radia, jest w pełni programowy. Żadne z obecnych urządzeń nie otrzymało go w Androidzie 12, ponieważ „utknęły” one na poprzedniej rewizji warstwy abstrakcji; jej nowa wersja nie została zaimplementowana w obrazie partycji vendor Androida 11, którego używają. GRF już uniemożliwił wielu urządzeniom uzyskanie nowej funkcji związanej z bezpieczeństwem, a to dopiero początek.
Wpływ na producentów smartfonów
Jeśli producenci chcą podążać ścieżką wytyczoną przez GRF, w ich obowiązkach dotyczących aktualizacji nie zachodzą wielkie zmiany. Nadal muszą oni aktualizować system, integrować ze swoim portfolio wydania BSP i pracować nad przejściem testów xTS. Jedyna różnica polega na wprowadzaniu nowych wydań platformy, gdzie GRF faktycznie nieco ułatwia sprawę właśnie ze względu na „zamrożenie” obrazu vendor.
Z drugiej strony, jeśli producenci chcą zignorować GRF i pójść własną drogą, jest to o wiele trudniejsze, o czym wspominałem powyżej.
Producenci próbujący być lepsi niż są pod względem aktualizacji
Nie jest to, co prawda, problem dotykający aktualizacji Androida jako całości, lecz wciąż w mojej opinii jest on wart uwagi.
Fairphone (3 i 4)
Fairphone kiedyś naprawdę dbał o aktualizacje Androida. Inżynierzy tej firmy tworzyli własne oprogramowanie, a następnie je aktualizowali we własnym zakresie. Fairphone 2 przeszedł z wersji N aż na wersję N+6, do Androida 10!
Od Fairphone’a 3 wszystko zaczęło się jednak zmieniać. Oprogramowanie działające na tym urządzeniu zostało wykonane przez ODM (tę samą firmę, której zlecono wykonanie sprzętu). Model ten wystartował z Androidem 9 i został zaktualizowany do wersji 10. Aktualizacja do Androida 11 jest planowana gdzieś w 2022 roku, co najmniej kilka miesięcy po opublikowaniu Androida 12. Nie dostanie on „dwunastki”, bo decydenci wybrali stary, niewspierany procesor. Tak, to prawda! Urządzenie może łaskawie liczyć tylko na aktualizację z wersji N do N+2 od firmy, która szczyci się… długim wsparciem. Za swoje dziwne decyzje Fairphone obarczał w pewnym sensie Qualcomma.
Ten sam producent zaprezentował smartfon Fairphone 4 tuż przed premierą Androida 12. Na pokładzie znalazł się Snapdragon 750G (którego początkową platformą był Android 10). Pod względem aktualizacji Fairphone był już w tyle od momentu premiery! Początkowo zadeklarowano tylko aktualizację do Androida 12, później korygując te zapowiedzi do Androida 12 i 13. Winiono jednocześnie Qualcomma za brak Androida 14 i wyżej dla tego procesora, podczas gdy ponownie wynikało to głównie z powodu swoich własnych wyborów. Oznacza to, że to urządzenie ponownie otrzyma aktualizację tylko z wersji N do N+2 (efektywnie N → N+1 w porównaniu do innych telefonów zaprezentowanych w tym samym czasie, ponieważ Android 12 powinien być zainstalowany na tym urządzeniu już po wyjęciu z pudełka).
Google (Pixel 6)
Pixel 6 to pierwsza generacja telefonów Google z „własnym” procesorem — Tensorem. Pomiędzy momentem, w którym Google postanowiło przejąć kontrolę nad wyciekami, po prostu pokazując swój telefon, a faktyczną premierą, pojawiło się wiele spekulacji dotyczących wyznaczonej żywotności urządzenia pod względem aktualizacji. Niektórzy hejterzy Qualcomma wywnioskowali, że skoro Google nie używa już chipa od „samego źródła wszelkiego zła”, to musi zapewnić dłuższe wsparcie niż wcześniej (co dotyczyło N+3). I co? I nic! Google Pixel 6 nadal będzie oferować aktualizacje tylko do wersji N+3 z dwoma dodatkowymi latami aktualizacji zabezpieczeń. Czy zatem to Qualcomm ponosi winę za wszystko, co złe w branży Androida? Nie sądzę.
Podsumowanie — co dalej?
Aktualizacje Androida przechodzą rewolucję już teraz. Czy to jednak pozytywna rzecz? Zobaczymy. Skupienie się przez Google na wersji N+3 Androida dla wszystkich urządzeń może sprawić, że producenci smartfonów będą częściej udostępniać 2 lub 3 aktualizacje platformy Androida, ale z drugiej strony w przypadkach, gdy zechcą oni dostarczyć więcej uaktualnień, niż się od nich oczekuje, stanie się to znacznie bardziej skomplikowane niż kiedykolwiek wcześniej. Może to również spowodować stagnację funkcji, pozbawiając użytkowników przydatnych ulepszeń. Dokąd zaprowadzi nas Google? Nie wiem, ale myślę, że wkrótce się tego dowiemy.
Serdecznie dziękuję Kubie za możliwość udostępnienia tego artykułu na naszym portalu. Jeśli macie pytania dotyczące tej publikacji bądź propozycje dotyczące innych kwestii związanych z Androidem lub MIUI, które mogłyby zostać u nas wyjaśnione, napiszcie o nich w komentarzu pod tym artykułem. Będziemy wdzięczni!