# Aktualizacja OTA Source: https://ordergroup.co/pl/slownik/aktualizacja-ota/ Last updated: 2026-10-10 > Aktualizacje OTA i FOTA dla firm, które wysyłają urządzenia w teren: podpisywanie, sloty A/B, pakiety pełne i przyrostowe, stopniowe wydania i rola backendu. [IoT i urządzenia](https://ordergroup.co/pl/slownik/iot/) 5 min czytania # Aktualizacja OTA Over-the-air update Inne nazwy: aktualizacja over-the-air, FOTA, aktualizacja oprogramowania przez sieć, aktualizacja firmware OTA, stopniowe wydanie Definicja Aktualizacja OTA to aktualizacja oprogramowania lub firmware'u, którą urządzenie pobiera i instaluje przez sieć, bez kabla i wizyty serwisu. FOTA to przypadek firmware'u. Pakiet musi być podpisany, sprawdzony na urządzeniu i odwracalny, gdy instalacja się nie uda. Cytuj hasło Tekst "Aktualizacja OTA". Order Group, Słownik oprogramowania, 10 października 2026. https://ordergroup.co/pl/slownik/aktualizacja-ota/ HTML `Aktualizacja OTA - Order Group` Sprawdzone przez [Maciej Sułek](https://ordergroup.co/pl/autorzy/maciej-sulek/), Współzałożyciel i CTO Ostatni przegląd 10 października 2026 ## Jak działa aktualizacja OTA Aktualizacja OTA przenosi nowy obraz oprogramowania od producenta do urządzenia w terenie przez sieć. RFC 9019, architektura IETF dla aktualizacji firmware'u urządzeń IoT, dzieli tę pracę na role. Autor buduje obraz. Status tracker ogłasza, że jest nowa wersja, zbiera informacje o sprzęcie i oprogramowaniu każdego urządzenia i uruchamia aktualizację. Odbiorca firmware'u na urządzeniu odczytuje i weryfikuje manifest, a potem zapisuje obraz. Manifest ma numer sekwencyjny. Według RFC 9019 urządzenie, które dostanie stary, ale poprawny manifest, nie może zainstalować tej wersji, bo stare wersje mogą mieć znane podatności. Android, na którym opiera się większość własnych systemów dla telefonów i terminali, pokazuje ten sam łańcuch w szczegółach. Pakiet OTA musi być podpisany jednym z kluczy, których oczekuje system, inaczej instalacja go odrzuci. W urządzeniach bez A/B pakiety odebrane przez system są zwykle sprawdzane dwa razy: najpierw przez system kluczami z pliku otacerts.zip, potem jeszcze raz przez recovery. Domyślnie buildy podpisuje się kluczami testowymi, a dokumentacja AOSP ostrzega, że klucze testowe są publicznie znane, więc każdy wydawany obraz potrzebuje własnych kluczy produkcyjnych. Są dwa rodzaje pakietów. Pakiet pełny zawiera cały docelowy stan urządzenia i instaluje się niezależnie od tego, jaką wersję urządzenie ma teraz. Pakiet przyrostowy (incremental) zawiera binarne łatki do plików, które już są na urządzeniu. Jest mniejszy, ale zainstaluje się tylko na dokładnie tym buildzie źródłowym, z którego go zbudowano. Na każdym innym instalacja kończy się błędem, a urządzenie dalej działa na starym systemie. W obecnych urządzeniach z Androidem sama instalacja korzysta ze slotów A/B. Demon update_engine zapisuje nową wersję w nieużywanym slocie w tle, kiedy użytkownik normalnie pracuje, a bootloader przełącza slot przy następnym restarcie. Jeśli nowy slot się nie uruchomi, urządzenie wraca do starego. Nowy slot zostaje oznaczony jako poprawny dopiero wtedy, gdy się uruchomi i przejdzie kontrole. Od Androida 11 standardem jest Virtual A/B, a aktualizacje bez A/B są od Androida 15 wycofywane. ## Co aktualizacje OTA oznaczają dla oprogramowania Większość pracy przy OTA dzieje się w backendzie i w procedurze wydawania wersji. To one decydują, czy nowa wersja dotrze do floty, czy zostawi urządzenia, które się nie uruchamiają. Wymagania dla systemu, który wysyła aktualizacje do floty: - Klucze podpisujące to infrastruktura produkcyjna. Klucze produkcyjne są oddzielone od testowych, nie leżą na laptopach programistów ani w logach CI i mają wskazanego właściciela. Kto ma klucz, ten może wgrać kod na każde urządzenie. - Graf wersji to dane. Dla każdej wersji docelowej backend przechowuje pakiet pełny, wersje źródłowe, dla których istnieje pakiet przyrostowy, oraz adresy pakietów. Każda para wersja źródłowa - wersja docelowa jest unikalna i pilnuje tego baza danych. - Każdy wymiar buildu jest jawny: region, wersja podpisana albo niepodpisana, wariant user albo userdebug. Pakiet przyrostowy zbudowany dla złego wariantu nie zainstaluje się na żadnym urządzeniu, które go dostanie, więc backend przed publikacją sprawdza, czy wersja źródłowa i docelowa do siebie pasują. - Gdy instalacja przyrostowa się nie uda, urządzenie przechodzi na pakiet pełny, zapisuje kod błędu i raportuje, jaki typ aktualizacji próbowało zainstalować. - Wersja trafia do floty w stopniowym wydaniu (rollout): najpierw do grupy testowej, a potem według harmonogramu do coraz większego odsetka urządzeń w każdej grupie, z możliwością wstrzymania i zatrzymania. Wstrzymanie musi też zatrzymać harmonogram, a urządzenie, które już zaczęło instalację, musi móc ją dokończyć. - Urządzenia raportują stan. Bez wersji i kodów błędów z każdego urządzenia operator nie odróżni powolnego stopniowego wydania od nieudanego. - Migracja danych o wydaniach jest tak samo ryzykowna jak samo wydanie. Stany stopniowych wydań, przypisania grup i warianty buildów muszą przetrwać przeniesienie na nowy backend, a migracja potrzebuje osobnej rundy testów. - Stare wersje pozostają zablokowane. Backend i urządzenie odmawiają powrotu do wersji ze znanymi podatnościami. Piszesz specyfikację? Dodaj Aktualizacja OTA do checklisty wymagań Zbierz hasła, których dotyczy Twój projekt, i dostań ich wymagania wobec systemu w jednym mailu, gotowe do zapytania ofertowego. Mechanizmy aktualizacji i to, co musi śledzić backend MechanizmCo robiOgraniczenieCo śledzi backend Pełny pakiet OTAZawiera cały docelowy stan urządzeniaDuży plik do pobraniaJeden pakiet na wersję docelową, region i wariantPrzyrostowy pakiet OTABinarne łatki do plików na urządzeniuInstaluje się tylko na dokładnym buildzie źródłowymPary wersja źródłowa - docelowa, przejście na pakiet pełnySloty A/B (Virtual A/B)Zapisuje aktualizację w nieużywanym slocie, stary slot nadal się uruchamiaPamięć urządzenia i układ partycjiRaporty o udanym i nieudanym uruchomieniuStopniowe wydanieUdostępnia wersję coraz większej części urządzeń w czasieWymaga grup urządzeń i losowego wyboruHarmonogram faz, stan wstrzymania i zatrzymania, liczba objętych urządzeńOchrona przed cofnięciem wersjiOdrzuca starsze wersjeWymaga numeru wersji lub numeru sekwencyjnego w manifeścieMinimalna dozwolona wersja dla linii urządzeń ## Przepisy i standardy W UE akt o cyberodporności (Cyber Resilience Act), rozporządzenie (UE) 2024/2847, robi z możliwości aktualizacji wymóg prawny dla produktów z elementami cyfrowymi. Załącznik I wymaga, żeby podatności dało się usuwać aktualizacjami bezpieczeństwa, w tym, tam gdzie to ma zastosowanie, automatycznymi aktualizacjami bezpieczeństwa włączonymi domyślnie, z jasnym sposobem rezygnacji, powiadamianiem o dostępnych aktualizacjach i możliwością ich odroczenia. Producent musi zapewnić mechanizmy bezpiecznej dystrybucji aktualizacji, a aktualizacje usuwające wykryte problemy bezpieczeństwa muszą trafiać do użytkowników bez zwłoki i, o ile przy produkcie robionym na zamówienie nie uzgodniono inaczej, bezpłatnie. Załącznik I część II pkt 2 wymaga, żeby nowe aktualizacje bezpieczeństwa, gdy jest to technicznie wykonalne, były udostępniane oddzielnie od aktualizacji funkcji. Art. 13 ust. 8 ustala okres wsparcia na co najmniej pięć lat; jeśli produkt ma być używany krócej niż pięć lat, okres wsparcia odpowiada przewidywanemu czasowi używania. Rozporządzenie stosuje się od 11 grudnia 2027 r., a obowiązki zgłaszania z art. 14 obowiązują od 11 września 2026 r. RFC 9019 to informacyjny dokument IETF: opisuje architekturę i uzasadnia potrzebę manifestu niezależnego od sposobu transportu, który opisuje i chroni aktualizacje. ## Z naszych projektów W [projekcie systemu Raw Control](https://ordergroup.co/pl/case-studies/raw-cyber-system-operacyjny-android/) prace nad aktualizacjami zaczęły się w 2019 r. od środowiska testowego, w którym analizowaliśmy i ocenialiśmy bezpieczeństwo aktualizacji Androida publikowanych przez Google, zanim trafiły do systemu. Wersję produkcyjną systemu przygotowaliśmy razem z testem OTA i przekazaliśmy klientowi do weryfikacji, a kolejne buildy OTA wydawaliśmy na prośbę klienta. Serwis OTA po stronie backendu został w 2021 r. rozpisany, ale w tym projekcie go nie ukończono. Dla Mudity w 2026 r. budujemy drugi etap platformy OTA dla jej telefonów, razem z nowym panelem administracyjnym. Systemu operacyjnego Mudity nie budowaliśmy. Zakres obejmuje publikację aktualizacji przyrostowych, przy których pakiet pełny jest zawsze dostępny jako zapasowy, a powiązanie każdej wersji z poprzednią jest unikalne; automatyczne generowanie pakietów przyrostowych w pipelinie buildów, z nazwami plików zawierającymi region, wersję, podpis, wariant buildu i wersję źródłową; sprawdzanie poprzednich wersji przy konfiguracji nowej; oraz scenariusze stopniowego wydania. Scenariusz ma od 1 do 10 faz, a każda faza to liczba godzin od wydania (od 0 do 720) i odsetek urządzeń w grupie, przy czym ostatnia faza obejmuje 100%. Przykład: 5% od razu, 20% po 48 godzinach, 50% po 120, 75% po 168 i 100% po 240. Urządzenia do każdej fazy są wybierane losowo. We wrześniu 2026 r. testowa migracja do nowego panelu zatrzymała wszystkie stopniowe wydania opublikowanych wersji; na produkcji zablokowałoby to każdą aktualizację. Błąd naprawiono. W toku jest audyt bezpieczeństwa frontendu i backendu platformy. Z naszych projektów [RAW Cyber - bezpieczny system operacyjny oparty na Androidzie Jak Order Group i RAW Cyber zbudowali bezpieczny mobilny system operacyjny: własny system oparty na Androidzie, wzmocniony CopperheadOS.](https://ordergroup.co/pl/case-studies/raw-cyber-system-operacyjny-android/) ## Powiązane hasła - [Głęboka inspekcja pakietów (DPI)](https://ordergroup.co/pl/slownik/dpi/) Deep packet inspection Głęboka inspekcja pakietów (DPI) to metoda analizy ruchu sieciowego, która czyta treść pakietów, a nie tylko adresy IP i porty. Pozwala rozpoznać protokół lub aplikację, wydobyć pola takie jak nazwa hosta i według polityki przepuścić, zablokować albo zapisać ruch. - [MDM](https://ordergroup.co/pl/slownik/mdm/) Mobile device management MDM, czyli zarządzanie urządzeniami mobilnymi, to oprogramowanie, które pozwala organizacji z jednej konsoli rejestrować, konfigurować, monitorować, blokować i zdalnie wymazywać telefony, tablety i inne urządzenia, wysyłając polityki do agenta albo do interfejsu zarządzania systemu. ## Źródła 1. [A/B (seamless) system updates](https://source.android.com/docs/core/ota/ab) - Android Open Source Project 2. [Build OTA packages](https://source.android.com/docs/core/ota/tools) - Android Open Source Project 3. [Sign builds for release](https://source.android.com/docs/core/ota/sign_builds) - Android Open Source Project 4. [RFC 9019: A Firmware Update Architecture for Internet of Things](https://www.rfc-editor.org/rfc/rfc9019.html) - IETF 5. [Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) - EUR-Lex To hasło sprawdza Maciej Sułek. Zapytaj, co oznacza w Twoim projekcie. [Zapytaj inżyniera](https://ordergroup.co/pl/kontakt/) ## Najczęstsze pytania ![Maciej Sułek](https://ordergroup.co/media/images/T02DHCC1Z-U04AVB19V-45105f88ff4a-512.format-webp.webp) Maciej Sułek Co-founder & CTO [Porozmawiaj z inżynierem](https://ordergroup.co/pl/kontakt/) ### Czym się różni OTA od FOTA? FOTA to OTA zastosowane do firmware'u. OTA obejmuje też system operacyjny, aplikacje i konfigurację. Wymagania są te same: podpisany pakiet, weryfikacja na urządzeniu, powrót do działającej wersji, gdy instalacja się nie uda, i backend, który wie, na jakiej wersji jest każde urządzenie. ### Czy każda aktualizacja powinna być przyrostowa? Nie. Pakiet przyrostowy zainstaluje się tylko na dokładnie tym buildzie, z którego go zbudowano, więc dla każdej wersji trzymaj pakiet pełny i przechodź na niego automatycznie. Pakiety przyrostowe zmniejszają rozmiar pobierania urządzeniom, które są na oczekiwanej wersji. ### Czy nasze urządzenia potrzebują partycji A/B? W Androidzie aktualizacje bez A/B są od Androida 15 wycofywane, więc nowe urządzenia powinny korzystać z Virtual A/B. W urządzeniach na mikrokontrolerach RFC 9019 opisuje dwa sposoby wyjścia z błędnego obrazu: przełączenie na inny poprawny obraz albo pobranie nowego. Oba wymagają miejsca w pamięci flash na więcej niż jeden obraz. ### Czy akt o cyberodporności (CRA) wymaga automatycznych aktualizacji? Tam, gdzie to ma zastosowanie, tak: załącznik I wymaga automatycznych aktualizacji bezpieczeństwa włączonych domyślnie, z jasnym sposobem rezygnacji i możliwością odroczenia. Rozporządzenie stosuje się od 11 grudnia 2027 r., więc urządzenia projektowane dziś będą sprzedawane już w czasie, gdy zacznie obowiązywać. Budujesz system, w którym liczy się Aktualizacja OTA? Zobacz, jak budujemy oprogramowanie w tej dziedzinie: case studies i technologie, których używamy. [Zobacz: Tworzenie oprogramowania IoT i urządzeń](https://ordergroup.co/pl/tworzenie-oprogramowania-iot/) Checklista wymagań Do każdego hasła wyślemy definicję i to, czego wymaga od Twojego oprogramowania. Bezpłatnie, bez rozmowy handlowej. Checklista jest pusta. Dodaj hasło plusem przy jego nazwie.