Telefon zatrzymuje się na logo producenta, po chwili gaśnie i ponownie wyświetla ten sam ekran. Czasem pętla restartów trwa kilka sekund, czasem urządzenie próbuje uruchomić się przez kilka minut, a następnie przechodzi w kolejne samoczynne restarty. Taki objaw nazywa się bootloopem. Największy problem diagnostyczny polega na tym, że dokładnie tak samo może wyglądać przerwany proces aktualizacji, uszkodzona partycja systemowa, zużyta pamięć eMMC lub UFS, a nawet problem z zasilaniem albo połączeniami lutowanymi pod układem. [1]
Samo logo producenta nie jest więc diagnozą. To jedynie informacja, że telefon przeszedł przez początkowy etap uruchamiania i zatrzymał się przed pełnym załadowaniem systemu. Różnica między awarią programową a sprzętową ujawnia się dopiero po analizie okoliczności, zachowania trybów serwisowych, reakcji na komputer oraz tego, czy pamięć masowa przyjmuje i utrzymuje zapisane dane.
Anatomia restartu na logo: co dzieje się w telefonie przed przerwaniem rozruchu?
Sekwencja startowa od bootloadera do pulpitu
Po naciśnięciu przycisku zasilania telefon nie uruchamia od razu Androida ani ekranu blokady. Najpierw układ zarządzania energią podaje napięcia do procesora, pamięci operacyjnej i pamięci masowej. Następnie procesor wykonuje kod startowy zapisany w wydzielonym obszarze pamięci. Ten kod inicjalizuje podstawowe podzespoły, sprawdza, czy dostępne są wymagane partycje, i przekazuje sterowanie bootloaderowi.
Bootloader odpowiada między innymi za wybór trybu uruchomienia, sprawdzenie podpisu systemu oraz załadowanie kolejnych komponentów, takich jak kernel i środowisko recovery. W nowoczesnych telefonach działają mechanizmy weryfikacji integralności, na przykład Android Verified Boot. Jeżeli system wykryje, że kluczowe dane zostały zmienione, uszkodzone albo nie pasują do oczekiwanej wersji, może zablokować dalszy start.
Dopiero po załadowaniu kernela urządzenie próbuje zamontować kolejne partycje. Szczególne znaczenie ma partycja /data, w której znajdują się dane użytkownika, ustawienia aplikacji i elementy środowiska systemowego. Jeśli montowanie kończy się błędem, Android może przejść do recovery, wyświetlić komunikat o uszkodzeniu danych albo zrestartować urządzenie. Właśnie wtedy użytkownik często widzi wyłącznie logo i uznaje, że telefon „umarł”.
W uproszczeniu można wyróżnić następujący ciąg:
- uruchomienie układu zasilania i procesora,
- wykonanie kodu pierwszego poziomu startowego,
- inicjalizacja pamięci eMMC lub UFS,
- uruchomienie bootloadera,
- weryfikacja podpisów i spójności partycji,
- załadowanie kernela oraz sterowników,
- zamontowanie partycji systemowych i danych,
- uruchomienie usług Androida i interfejsu użytkownika.
Awaria na dowolnym z tych etapów może zakończyć się restartem. Logo producenta pojawia się zazwyczaj wcześnie, dlatego nie mówi, czy problem dotyczy samego bootloadera, pamięci, kernela, sterownika, partycji danych czy aplikacji uruchamianej dopiero pod koniec startu.
Dlaczego telefon restartuje się zamiast pokazać konkretny błąd?
System operacyjny telefonu jest projektowany tak, aby w razie krytycznego błędu nie pozostawiać urządzenia w nieokreślonym stanie. Jeżeli kernel nie może odczytać wymaganych danych, sterownik pamięci zgłasza błąd albo usługa odpowiedzialna za start kończy się awaryjnie, watchdog może wymusić reset. Dla producenta takie zachowanie bywa bezpieczniejsze niż pozostawienie zawieszonego procesu z aktywnym zasilaniem.
W trybie recovery lub bootloadera komunikat może być bardziej precyzyjny, ale standardowy ekran startowy zwykle nie pokazuje szczegółów. Stąd częsty scenariusz: telefon wyświetla logo, ekran gaśnie, pojawia się logo ponownie, a właściciel nie otrzymuje żadnej informacji, czy winna jest aktualizacja, pamięć UFS czy układ zasilania.
Restart może być też skutkiem błędu odczytu, który wystąpił tylko podczas korzystania z konkretnego obszaru pamięci. Telefon potrafi wtedy przejść przez logo, wejść do recovery, a nawet reagować na przyciski, lecz resetuje się w momencie próby zamontowania partycji danych. To ważna różnica diagnostyczna: sam fakt, że recovery się pojawia, nie dowodzi sprawności pamięci.
Błąd logiczny a fizyczny brak odpowiedzi pamięci
Uszkodzenie logiczne oznacza, że pamięć odpowiada, ale zapisane w niej dane są niekompletne, niespójne lub niezgodne z oczekiwanym układem. Przyczyną może być przerwana aktualizacja OTA, rozładowanie baterii podczas zapisu, błędny root, nieprawidłowy obraz systemu albo ręczne usunięcie plików z partycji systemowej. W takim przypadku program serwisowy często potrafi odczytać identyfikator pamięci, wyczyścić partycję i zapisać nowy firmware. [2]
Uszkodzenie fizyczne wygląda inaczej. Kość eMMC albo UFS może przestać odpowiadać, zgłaszać błędy odczytu i zapisu, przejść w tryb tylko do odczytu lub tracić komunikację po rozgrzaniu. Niekiedy problem leży nie w samych komórkach pamięci, lecz w połączeniach BGA pod układem. Wtedy telefon może działać przez chwilę, a następnie resetować się przy zmianie temperatury lub większym obciążeniu.
Granica nie zawsze jest oczywista. Pamięć zużyta fizycznie może początkowo pozwolić na odczyt większości danych, lecz odrzucać zapis. Z kolei uszkodzony system plików może wyglądać jak awaria pamięci, ponieważ Android wielokrotnie próbuje zamontować partycję i za każdym razem wpada w restart. Potrzebne są testy rozróżniające te scenariusze.
Dlaczego samo logo nie wystarcza do diagnozy?
Logo producenta jest wspólne dla wielu etapów startu. Ten sam obraz może pojawić się po nieudanej aktualizacji, po zalaniu, przy zużytej baterii, po błędnym odblokowaniu bootloadera i po uszkodzeniu pamięci. Wymiana kości „na ślepo” tylko dlatego, że telefon jest w bootloopie, jest kosztownym zgadywaniem.
Znacznie bardziej użyteczne są informacje dodatkowe: czy usterka pojawiła się po aktualizacji, czy telefon był wcześniej wolny, czy obudowa mocno się nagrzewała, czy można wejść do recovery, czy fastboot pozostaje stabilny, czy komputer wykrywa ADB albo port awaryjny oraz czy próba przywrócenia firmware kończy się błędem zapisu.
Trzeba też odróżnić bootloop od ciągłego wyłączania z powodu zasilania. Telefon, który gaśnie zanim pojawi się logo albo resetuje się przy podłączeniu ładowarki, może mieć problem z baterią, układem PMIC lub zwarciem. W takim przypadku pamięć eMMC/UFS może być całkowicie sprawna, choć objaw na ekranie będzie podobny.
Kiedy to prawie na pewno oprogramowanie: sytuacje, w których ratunek ma sens
Okoliczności poprzedzające usterkę jako kluczowy wskaźnik
Najsilniejszą wskazówką jest to, co wydarzyło się bezpośrednio przed bootloopem. Jeżeli telefon działał poprawnie, rozpoczął aktualizację systemu, a po ponownym uruchomieniu zatrzymał się na logo, pierwszym podejrzanym powinno być oprogramowanie. Dotyczy to zarówno aktualizacji automatycznej OTA, jak i ręcznie wgrywanego firmware.
Podobnie wygląda sytuacja po odblokowaniu bootloadera, instalacji niestandardowego recovery, rootowaniu lub modyfikacji partycji systemowej. Niekompatybilny obraz kernela, niepełny pakiet modułów albo firmware przeznaczony dla innego wariantu modelu może zakończyć się pętlą restartów, mimo że pamięć jest sprawna.
Inny typowy scenariusz to niemal całkowite zapełnienie pamięci wewnętrznej. Android potrzebuje wolnego miejsca na pliki tymczasowe, dzienniki i operacje aktualizacyjne. Gdy zabraknie przestrzeni w kluczowym momencie, system może nie dokończyć zapisu i po restarcie nie umieć zbudować prawidłowego środowiska startowego. Nie oznacza to automatycznie zużycia kości.
Wstępne podejrzenie oprogramowania jest silniejsze, gdy:
- telefon wcześniej nie zawieszał się i nie wyłączał losowo,
- usterka nastąpiła dokładnie po aktualizacji lub modyfikacji systemu,
- obudowa nie była zalana ani mocno uderzona,
- recovery i fastboot działają stabilnie przez dłuższy czas,
- komputer prawidłowo rozpoznaje urządzenie,
- program serwisowy odczytuje informacje o pamięci i pozwala rozpocząć zapis firmware.
Stabilne Recovery i Fastboot przemawiają na korzyść naprawy programowej
Recovery jest środowiskiem uruchamianym niezależnie od pełnego systemu Android. W zależności od producenta można w nim wyczyścić pamięć podręczną, wykonać reset danych, sprawdzić integralność systemu albo zastosować aktualizację z pliku. Fastboot lub tryb bootloadera służy głównie do komunikacji z komputerem i zapisu wybranych partycji.
Jeśli telefon pozostaje w recovery bez samoistnego restartu, ekran nie gaśnie, a przyciski reagują przewidywalnie, jest to korzystny sygnał. Nie daje stuprocentowej pewności, ponieważ recovery może nie korzystać z tych samych obszarów pamięci co Android, ale pokazuje, że procesor, podstawowe zasilanie i część ścieżki komunikacji działają.
Jeszcze bardziej przydatny jest test stabilności. Jednorazowe wejście do fastbootu nie wystarczy. Jeżeli urządzenie pozostaje w tym trybie przez kilka minut, komputer nie traci połączenia, a polecenia identyfikacyjne są wykonywane bez losowych resetów, rośnie prawdopodobieństwo problemu z systemem, a nie z podstawową elektroniką płyty.
Trzeba zachować ostrożność przy poleceniach kasujących. Wipe data, formatowanie partycji lub odblokowanie bootloadera może bezpowrotnie usunąć dane użytkownika. Jeśli zdjęcia, dokumenty albo wiadomości są ważniejsze niż szybkie uruchomienie telefonu, nie należy zaczynać od resetu tylko dlatego, że jest to najprostsza opcja na ekranie recovery.
ADB, Fastboot i poprawne zgłaszanie się do komputera
Jeżeli system dochodzi wystarczająco daleko, komputer może zobaczyć telefon jako urządzenie ADB. W trakcie bootloopa najczęściej nie ma jednak czasu na autoryzację i stabilną sesję ADB. Bardziej typowe jest wykrywanie fastbootu lub bootloadera. Sam fakt pojawienia się urządzenia w menedżerze nie oznacza jeszcze, że można bezpiecznie flashować dowolny plik.
Warto sprawdzić, czy połączenie nie znika przy każdym restarcie. Urządzenie widoczne przez chwilę, po czym znikające i pojawiające się ponownie, może wskazywać zarówno na normalną pętlę startową, jak i problem z pamięcią lub zasilaniem. Znaczenie ma powtarzalność: stabilna komunikacja w trybie serwisowym jest argumentem za próbą naprawy firmware.
W telefonach z procesorem Qualcomm może pojawić się tryb EDL, a w urządzeniach z układami MediaTek – Preloader, BootROM lub inny port awaryjny. Są to tryby niskiego poziomu, lecz ich dostępność nie jest równoznaczna ze sprawnością pamięci. Telefon może zgłaszać się do komputera, ale odrzucać zapis, nie przechodzić weryfikacji albo tracić komunikację podczas kasowania partycji.
Kiedy wipe data lub czysty firmware ma uzasadnienie?
Wipe data ma sens, gdy recovery działa stabilnie, a objawy wskazują na uszkodzenie danych użytkownika lub konfiguracji systemu. Jest to jednak rozwiązanie destrukcyjne. Kasuje zawartość partycji danych, a w telefonach z szyfrowaniem może zniszczyć ostatnią możliwość odzyskania plików przy użyciu standardowych metod.
Wgranie pełnego, fabrycznego oprogramowania jest rozsądne po nieudanej aktualizacji, błędnym rootowaniu albo uszkodzeniu partycji systemowej. Firmware musi być dokładnie dopasowany do modelu, wariantu regionalnego, wersji bootloadera i metody flashowania. „Prawie taki sam” plik może unieruchomić urządzenie bardziej niż pierwotny problem.
Czerwone flagi uszkodzenia eMMC/UFS: kiedy problem tkwi głęboko w krzemie
Błędy zapisu i odczytu podczas próby naprawy
Najbardziej niepokojącym sygnałem jest sytuacja, w której telefon poprawnie przechodzi do trybu serwisowego, ale nie pozwala odczytać informacji z pamięci albo przerwanie następuje dokładnie podczas zapisu firmware. Jeżeli program zgłasza błędy wejścia-wyjścia, timeouty, nieprawidłowe odpowiedzi urządzenia lub niemożność wymazania konkretnej partycji, problem może dotyczyć fizycznego stanu eMMC/UFS, a nie samego obrazu systemu. [3]
Znaczenie ma powtarzalność. Pojedynczy błąd może wynikać z wadliwego kabla, sterownika, niewłaściwego pliku, niskiego poziomu baterii albo złej procedury dla danego modelu. Jeżeli jednak ten sam błąd występuje na sprawdzonym stanowisku, przy poprawnym firmware i w tym samym miejscu zapisu, rośnie prawdopodobieństwo awarii pamięci lub jej połączeń z płytą.
Szczególnie istotne są przypadki, gdy odczyt identyfikatora kości jest możliwy, lecz próba zapisu kończy się niepowodzeniem. Pamięć może wtedy nadal odpowiadać na podstawowe komendy, ale nie przyjmować danych do zużytych lub uszkodzonych obszarów. Taki objaw bywa mylony z błędnym firmware, ponieważ telefon jest wykrywany przez komputer i pozornie „żyje”.
Utrata komunikacji i niestabilne wykrywanie pamięci
Jeżeli urządzenie znika z komputera podczas odczytu, kasowania albo zapisu, trzeba rozważyć kilka przyczyn: niestabilne zasilanie, uszkodzony przewód, wadliwy port, przegrzewanie układu, problem z kontrolerem pamięci lub przerwane połączenie BGA. Sama utrata komunikacji nie wskazuje jednoznacznie na eMMC/UFS, ale jest znacznie poważniejsza niż zwykła niespójność plików systemowych.
Czerwoną flagą jest powtarzalny schemat: urządzenie daje się zidentyfikować, rozpoczyna operację, po czym resetuje się lub przestaje odpowiadać zawsze przy podobnym etapie. Jeżeli po ponownym podłączeniu wraca do trybu awaryjnego, ale ponownie traci komunikację przy zapisie tej samej partycji, serwisant powinien zbadać pamięć oraz zasilanie pod obciążeniem, zamiast wielokrotnie ponawiać flashowanie.
Warto odnotować, czy telefon traci połączenie również wtedy, gdy pozostaje bezczynny w trybie bootloadera. Znikanie bez wykonywania operacji może sugerować zasilanie, baterię, zwarcie albo połączenie mechaniczne. Zrywanie połączenia dopiero przy intensywnym odczycie lub zapisie bardziej kieruje uwagę na pamięć, kontroler, temperaturę i ścieżki zasilające.
Przejście pamięci w tryb tylko do odczytu
Pamięć flash może w pewnym momencie przestać przyjmować zapis, aby ograniczyć dalszą utratę danych. Telefon może wtedy uruchamiać część kodu startowego, lecz nie będzie w stanie poprawnie zapisać ustawień, odbudować systemu plików ani przyjąć nowego firmware. Objawem bywa zapętlenie startu, powracające błędy montowania partycji lub pozornie udany proces, po którym urządzenie nadal zachowuje się tak samo.
Tryb tylko do odczytu nie zawsze jest widoczny dla użytkownika jako jednoznaczny komunikat. Można go podejrzewać, gdy:
- odczyt danych działa, ale kasowanie lub zapis kończy się błędem,
- zmiany wykonane w recovery nie zachowują się po ponownym uruchomieniu,
- program serwisowy nie może wyczyścić wybranej partycji,
- firmware zapisuje się bez komunikatu o błędzie, lecz po restarcie telefon wraca do identycznego stanu,
- logi wskazują na odrzucenie komend zapisu albo błędy integralności kontrolera pamięci.
Przed uznaniem tego za awarię kości należy wykluczyć blokadę zapisu wynikającą z procedury producenta, zabezpieczenia bootloadera, niewłaściwego trybu serwisowego lub braku odpowiednich uprawnień. Jeżeli jednak ograniczenie zapisu występuje niezależnie od użytego narzędzia i prawidłowej metody, dalsze próby programowe zwykle nie przynoszą poprawy.
Zależność objawów od temperatury i nacisku
Awaria nasilająca się po rozgrzaniu telefonu jest ważną wskazówką. Wysoka temperatura może pogarszać działanie zużytej pamięci, ujawniać problem z kontrolerem albo zwiększać rezystancję wadliwego połączenia pod układem BGA. Telefon może uruchamiać się na zimno, a po kilku minutach resetować podczas odczytu danych lub zapisu.
Odwrotny scenariusz również się zdarza: urządzenie chwilowo działa po ostygnięciu, lecz bootloop powraca po wzroście temperatury. Nie należy jednak traktować podgrzewania płyty jako naprawy. Krótkotrwała poprawa po ogrzaniu może jedynie zmienić warunki elektryczne połączenia i zamaskować usterkę, a dodatkowo zwiększa ryzyko uszkodzenia laminatu, układów sąsiednich i danych.
Jeżeli objaw zmienia się po delikatnym poruszeniu płytą, nacisku na osłonę układu lub zmianie temperatury, podejrzane stają się połączenia BGA. Taki test nie powinien być wykonywany przypadkowo przez użytkownika. Mechaniczne dociskanie płyty może pogłębić mikropęknięcia i utrudnić późniejszą diagnostykę.
Historia wcześniejszych objawów ma znaczenie
Fizyczna degradacja pamięci często nie zaczyna się od nagłego bootloopa. Wcześniej telefon może wyraźnie zwalniać, długo zapisywać zdjęcia, zawieszać się przy instalowaniu aplikacji, samoczynnie uruchamiać ponownie lub zgłaszać błędy podczas aktualizacji. Pojedynczy taki objaw nie przesądza o diagnozie, ale ich narastanie przed awarią zwiększa podejrzenie zużycia pamięci.
Niepokojące jest także stopniowe pogarszanie stabilności: najpierw sporadyczne restarty, później problemy z aktualizacją, następnie uruchamianie tylko po kilku próbach i w końcu stała pętla na logo. Taki przebieg bardziej pasuje do postępującej usterki sprzętowej niż do jednorazowego uszkodzenia plików systemowych.
Matryca decyzyjna: kiedy naprawa jest opłacalna, a kiedy bezpieczniej odpuścić
Kiedy warto kontynuować diagnostykę i próbę naprawy?
Naprawa ma sens, gdy objawy pojawiły się nagle po konkretnej zmianie programowej, telefon nie wykazywał wcześniej problemów z wydajnością ani stabilnością, a tryby serwisowe działają bez utraty komunikacji. Korzystna jest również sytuacja, w której pamięć można odczytać i zapisać, a błędy dotyczą wyłącznie konkretnej partycji lub konfiguracji systemu.
Warto inwestować w dalszą diagnozę także wtedy, gdy urządzenie jest stosunkowo nowe, ma wysoką wartość rynkową albo przechowuje ważne dane. W takim przypadku celem nie powinno być wyłącznie szybkie uruchomienie telefonu. Najpierw należy ustalić, czy można wykonać kopię danych lub obraz pamięci bez destrukcyjnych operacji.
| Kryterium | Przesłanka za próbą naprawy | Przesłanka przeciw pochopnym próbom |
|---|---|---|
| Historia usterki | Bootloop rozpoczął się po aktualizacji, rootowaniu lub modyfikacji systemu | Problemy narastały przez tygodnie, pojawiały się zawieszenia i restarty |
| Komunikacja | Urządzenie stabilnie zgłasza się w trybie serwisowym | Traci połączenie przy odczycie, kasowaniu lub zapisie |
| Pamięć | Odczyt i zapis przechodzą poprawnie | Powtarzają się błędy I/O, timeouty lub odmowa zapisu |
| Temperatura | Objawy nie zależą od czasu pracy i nagrzewania | Telefon działa tylko na zimno albo resetuje się po rozgrzaniu |
| Dane | Dane są zabezpieczone lub nie mają istotnej wartości | Najważniejsze są zdjęcia, dokumenty albo wiadomości bez kopii |
| Koszt | Telefon jest wartościowy, a diagnoza ma umiarkowaną cenę | Naprawa może kosztować podobnie jak sprawne urządzenie |
Kiedy należy wstrzymać się z resetem i flashowaniem?
Nie warto zaczynać od kasowania danych, gdy telefon zawiera jedyną kopię ważnych plików, a pamięć wykazuje objawy niestabilności. Każda dodatkowa operacja zapisu może pogorszyć stan zużytej kości albo nadpisać obszary potrzebne do odzyskania danych. W takiej sytuacji priorytetem jest dokumentacja objawów i konsultacja z serwisem zajmującym się odzyskiem, a nie wielokrotne próby przywracania systemu.
Ostrożność jest wskazana również wtedy, gdy urządzenie było zalane, mocno nagrzewało się podczas pracy albo ma ślady naprawy płyty. Problem pamięci może być tylko skutkiem korozji, zwarcia lub niestabilnego zasilania. Wymiana samej kości bez usunięcia przyczyny może zakończyć się ponowną awarią.
Kiedy ekonomicznie bezpieczniej zrezygnować?
Rezygnacja z naprawy płyty może być racjonalna, gdy koszt diagnostyki, pracy mikrolutowniczej i części zbliża się do ceny sprawnego telefonu, a dane nie są kluczowe. Szczególnie ostrożnie należy podchodzić do starych modeli, dla których brakuje nowych kości, dokumentacji, części dawcy lub pewnej procedury zapisu danych kalibracyjnych.
Nie oznacza to, że każdą awarię pamięci należy od razu uznać za nienaprawialną. Decyzja powinna uwzględniać wartość urządzenia, dostępność części, reputację serwisu, ryzyko utraty danych i prawdopodobieństwo trwałego rezultatu. Sama obietnica „wymiany pamięci” bez wyjaśnienia, czy obejmuje programowanie, konfigurację i testy, nie wystarcza do oceny oferty.
Techniczne metody ratunku płyty głównej: reballing, wymiana kości czy cała płyta?
Reballing przy podejrzeniu połączeń BGA
Reballing polega na usunięciu układu, oczyszczeniu pól lutowniczych, nałożeniu nowych kul lutowniczych i ponownym osadzeniu elementu. Ma sens wtedy, gdy sama pamięć jest sprawna, lecz występuje problem z połączeniem między kością a płytą. Potwierdzeniem powinny być wyniki diagnostyki, oględziny mikroskopowe i analiza zachowania urządzenia, a nie sam fakt występowania bootloopa.
Reballing nie naprawia zużytych komórek pamięci, uszkodzonego kontrolera ani błędów zapisu wynikających z degradacji kości. Jeżeli połączenia są poprawne, ponowne przylutowanie tego samego układu zwykle nie rozwiąże problemu. Źle wykonana operacja może natomiast uszkodzić pady, laminat lub sąsiednie komponenty.
Wymiana eMMC albo UFS
Wymiana pamięci jest bardziej złożona niż przełożenie układu. Nową kość trzeba dobrać pod względem typu, pojemności, obudowy, zgodności z kontrolerem i wymaganej konfiguracji. W wielu konstrukcjach konieczne jest zaprogramowanie odpowiednich obszarów, przygotowanie partycji, odtworzenie danych startowych oraz dopasowanie oprogramowania do konkretnej płyty.
Jeżeli telefon ma szyfrowanie sprzętowe, dane użytkownika nie muszą być możliwe do odzyskania po przełożeniu lub wymianie kości. Celem takiej naprawy jest zazwyczaj przywrócenie działania urządzenia, a nie odtworzenie zawartości starej pamięci. Serwis powinien jasno rozdzielić te dwa cele przed rozpoczęciem pracy.
W przypadku UFS ważna jest nie tylko sama kość, lecz także zgodność komunikacji i parametrów z płytą główną. Próba użycia przypadkowego układu dawcy może spowodować brak inicjalizacji, błędy zapisu albo problemy z późniejszym flashowaniem. Dlatego naprawa wymaga odpowiedniego programatora, mikroskopu, kontroli temperatury oraz doświadczenia z danym typem urządzenia.
Źródła
- [1] Rossmann Repair Group – Samsung Galaxy Boot Loop Data Recovery
- [2] iFixit – How to Troubleshoot Bootloop Issues in an iPhone
- [3] Telecom Sector Skill Council India – Participant Handbook – Handheld Devices (Mobile & Accessories) Technician
