@@Steve71
Skrypt może być dobry. Coś blokuje wykonanie skryptu podczas startu systemu na stock Lollipop.
Ogólnie zasada wykonywania skryptów init.d podczas startu systemu jest bardzo prosta a w dużym skrócie wygląda to tak :
Po wciśnięciu przycisku power uruchamia się bootloader on wczytuje do pamięci RAM zawartość partycji boot ( Kernel + ramdisk ).
Ramdisk to nic innego jak wszystkie te pliki które są widoczne w najwyższym katalogu /root ( to ten z którego wyżej nie da się wyjść ). Są to pliki z rozszerzeniem .rc i .sh ( np. init.rc,init.class_main.sh, init.environ.rc, init.fm_vendor.rc, init.g2m_core.rc, init.g2m_product.rc, init.g2m.rc, init.lge.bt_vendor.rc, init.lge.cmm.usb.sh, init.lge.early.rc, init.lge.log.rc, init.lge.power.rc, init.lge.rc, init.lge.svelte.rc, init.lge.usb.rc, init.lge.usb.sh, init.mdm.sh, init.qcom.class_core.sh, init.qcom.early_boot.sh, init.qcom.factory.sh, init.qcom.rc, init.qcom.sh, init.qcom.ssr.sh, init.qcom.syspart_fixup.shitd. itd.) oraz kilka innych plików i folderów.
Rozpoczyna się wykonywanie komend zawartych w plikach zaczynając od pliku init.rc. Jak zajrzysz do pliku to znajdziesz tam komendy typu service np;
service bootanim /system/bin/bootanimation
class core
user graphics
group graphics audio system
disabled
oneshot
Tu na przykładzie jest serwis bootanimacji. Czyli dopiero teraz zaczyna się bootanimacja na ekranie telefonu ( kernel i ramdisk już są w pamięci Ram).
Co jest potrzebne żeby skrypty init.d zostały wykonane ?
Minimum dwa serwisy. Pierwszy serwis to powłoka shell czyli/system/bin/sh.Drugi serwis to już bezpośrednie uruchomienie skryptów zawartych w init.d. Oryginalnie nie ma drugiego serwisu ale jak to bywa programiści z xda wymyślili że można by podpiąć pod jakiś istniejący serwis obsługę init.d i jest to przeważnie podpinane pod /system/bin/sysinit. Na stock loolipop nie ma tego serwisu ale jest drugi też działający o nazwie/system/bin/install-recovery.sh. I w nim jest podpinane uruchomienie init.d podczas dodawania wsparcia init.d metodą z pierwszego postu. W zasadzie do tego pliku jest dopisywana linijka z instrukcją wykonania przez busyboxa wszystkich skryptów z folderu /system/etc/init.d
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/xbin/run-parts /system/etc/init.d
Jeśli wszystko jest ok to czemu nie działa ? Według mnie coś blokuje na stock romie przy starcie systemu nie wykonanie init.d tylko całą powłokę shell (/system/bin/sh). Bo u mnie od razu po uruchomieniu telefonu jak wchodziłem do terminala to uruchamiał się ale jeszcze przez kilka sekund po uruchomieniu nie szło wprowadzić żadnych komend tak jakby czekał jeszcze za powłoką shell.
Gdzie to jest blokowane nie wiem pewnie gdzieś po wywołaniu sh w pliku init.rc :
service console /system/bin/sh
class core
console
disabled
user shell
group shell log
seclabel u:r:shell:s0
Dalej nie szukałem bo kernel adiutor obchodzi tą blokadę po prostu czekając tak długo aż powłoka shell jest dostępna i dopiero wtedy wykonuje skrypty. Może szło by to poprawić w ramdisku przenosząc start serwisu jak najpóźniej się da, ale nie chce mi się w to bawić.
Jeśli komuś chce się w to pobawić to dodam tylko że trzeba edytować pliki w boot.img a nie bezpośrednio w telefonie bo pliki w telefonie to kopie oryginalnych plików z boot które znikają po wyłączeniu telefonu i są na nowo wczytywane przy starcie więc ich edycja nie ma sensu.