Zrobiłem wipe cache partition, update OTA pobrał się na nowo (swoją drogą prawie zapomniałem, że w recovery w Androidzie 4.3 jest ten błąd i trzeba wybrać "jedną opcję wcześniej" Motorola Moto G plagued by a recovery bug - GSMArena Blog ).
Niestety, podczas instalowania znowu to samo, błąd instalacji i reboot telefonu, z informacją "Aktualizacja oprogramowania nie powiodła się!"
Próbowałem też zrobić unroota, ale i to nic nie dało. Swoją drogą to dziwne, bo po operacjach root/unroot ustawienie persist.debug.wfd.enable w build.prop wróciło do wartości 0, ale pomimo to obsługa Miracast pozostała aktywna (?! - może to jest problemem dla aktalizacji)
Zapewniam też, że wielokrotnie restartowałem telefon, wierząc że może teraz to pomoże - niestety bez skutku. Natomiast factory reset wolałbym uniknąć (nie wiem czy uzasadnienie, po prostu nie korzystałem jeszcze z robienia backupów w żadnym z custom recovery, stąd obawa utraty danych).
Jeśli nic nie wykombinuję, to pozostaje chyba tylko tak jak pisze @Makarons, wgrać paczkę OTA z SD. Mam tylko pytanie: czy muszę zrestorować niebrandowaną wersję Androida 4.3 z rynku niemieckiego żeby móc skorzystać z tej paczki (czyli tak jak pisze @PiotrWpl tutaj: https://forum.android.com.pl/topic/366806-jest-jua-kitkat-dla-moto-g/ )?
Czy mogę po prostu wrzucić paczkę z updatem na SD i zainstalować z recovery, nawet jeśli mam Moto G niepochodzącą z rynku niemieckiego?
Zamieszczone przez Matticzek
Tak wspomniałeś o nie usuwaniu loga, nie chcę tworzyć nowego tematu i zapytam się jak to zrobić? Denerwuje mnie te ostrzeżenie.
Chyba mnie z kimś pomyliłeś. Nie wiem o jakim logu mówimy.
Na początku tematu wspomniałem, że odblokowałem bootloadera, ale nic więcej np. nie usunąłem loga (nie wgrywałem logo.bin), myślę że to o to było pytanie 🙂
Dla Matticzek, jeśli chcesz usunąć ostrzeżenie zajrzyj tutaj: https://forum.android.com.pl/topic/364250-moto-g-usuniecie-ostrzegajae-cego-loga-po-odblokowaniu-bootloadera/ (jest o tym napisane w FAQ)
EDIT1:
Pomyślałem chwilę, poszukałem i dowiedziałem się, że oczywiście recovery mode ma logi do każdej przeprowadzanej operacji.
W cache znalazłem kilka logów, z różnych akcji. Analizując znajdywane błędy (których szukałem na xda) dowiedziałem się, że nie mogę mieć Xposed frameworka, TWPR ani SuperSU aby zainstalować OTA (przypominam, że podczas pierwszej próby update OTA na pewno nie miałem nic takiego zainstalowanego jeszcze). Odinstalowałem te programy, ale logów z czasów pierwszych prób update niestety nie ma w cache. Czekam na kolejną próbę update OTA.
EDIT2:
Mam wielką prośbę, czy mógłby ktoś wrzucić swój plik /system/etc/install-recovery.sh (hash: 99ffe4a3d0e6612e87cd3f6a62dad642094f0169) ze stockowego romu? (Blur_Version.14.71.8.falcon_umts.Retail.en.GB)
Wnioskując z treści skryptu .sh został on podmieniony przez SuperSU, przy czym widzę że nie ma jego kopii zapasowej (choć w teorii powinna być..)
Chciałem wyciągnąć go z paczki z firmware, ale podczas próby otworzenia system.img przy użyciu ext4_unpacker ( Android ICS JB EXT4 imagefile unpacker | Free software downloads at SourceForge.net ) program przestaje odpowiadać.. 🙁 Poza tym wydaje mi się że fabryczny skrypt na trochę inną zawartość niż powinna tam być podczas używania telefonu (wyciągnąłem ten plik hexem, ale md5 się nie zgadza).
EDIT3:
Ah, co za faux pas! Suma kontrolna install-recovery.sh to nie md5 tylko sha1! Czyli jednak plik wyciągnięty z system.img przez hexa jest w porządku. Wrzucam plik, zastępując ten stworzony przez SuperSU, usuwam wszystkie dodatkowe aplikacje z xbin. Nic więcej nie znalazłem w poprzednim last_log z recovery, mam nadzieję że to już wszystko. Ściągam update OTA jeszcze raz..
FINAL:
Sukces! Telefon zaktualizowany do wersji 4.4.2.
Studium przypadku: aby włączyć Miracast potrzebowałem edytować build.prop. Z tego powodu nie chciała zainstalować się OTA (sprawdzany jest hash build.propa). Myślałem, że to wina roota i aby unrootować telefon zainstalowałem SuperSU i uruchomiłem Full unroot. Jak się później okazało ów program modyfikuje install-recovery.sh, przez co nadal nie chciał przejść update (tego pliku hash też jest sprawdzany). Sumarycznie po wielu perypetiach i dokładnym czytaniu logu udało się rozwiązać problem.
Wciąż nie wiem, czy można aktualizować przy użyciu OTA gdy ma się roota (w last_log pod opisem o błędzie były informacje o nowych aplikacjach tj. /system/xbin/daemonsu i /system/xbin/su, które też zapobiegawczo usunąłem). Nie mniej jednak nie zamierzam tego za szybko sprawdzać 🙂