Отложенный запуск скриптов на 4.2

[ZigZag]

На 4pda в соответствующей теме для решения проблемы с невыполнением (или слишком ранним выполнением) скриптов запускаемых через системный сервис (скрипт) был предложен костыль с until и getprop sys.boot_completed, только вот до 5-ки этого intent'a не было и как выкрутиться на более ранних андроидах непонятно Есть у кого какие мысли на этот счёт ?

[Zyxmon]

А если sleep добавить (число секунд подобрать)?

[Александр Рыжов]

Zyxmon, тогда это будет не event driven, а timeout driven действие, коих по возможности надо избегать.

[ZigZag]

А если sleep добавить (число секунд подобрать)?

ну если добавить sleep, то там по моему затормозится всё что следует за инициализирующим системным скриптом (у меня это install-sercovery.sh) + sleep должен быть немаленьким. В until по крайней мере можно поставить небольшой таймаут + getprop sys.boot_completed и пусть себе долбится, пока значение интента не сменится.

Пока видится пара вариантов - найти ведроидную тулзу, которая позволяет подцепить shell-скрипт при запуске и через run-parts городить огород (по моему Tasker умеет подобное), либо затолкать в install-recovery.sh всё тот же until с небольшим таймаутом, но в качестве условия проверки выбрать что-то другое. К примеру наличие определённого процесса.

[ZigZag]

В принципе вариант с Tasker'ом выгорел. Профиль Событие -> Система -> Загрузка окончена. Действие run shell + таймаут запуска 10 секунд (может позже подкручу в сторону уменьшения).

Из всего списка команд не запустился только socat, который натравлен на мониторинг определённого порта и выхлопом содержимого STDOUT в файл, ну да на досуге поразбираюсь, чем Tasker не устроил socat ...

[kaztost]

Источник цитаты был предложен костыль с until и getprop sys.boot_completed, только вот до 5-ки этого intent'a не было

Если совсем не хотите костылей: исправляйте init.rc в рамдиске, используя конструкцию on property. Вам тогда init сам все запустит, когда надо. Но таки это не intent, а свойство!

Для старых андроидов может сработать свойство dev.bootcomplete. Хоть в костыльном, хоть в бескостыльном вариантах.

[ZigZag]

Если совсем не хотите костылей: исправляйте init.rc в рамдиске, используя конструкцию on property.

Это трудно назвать "plug-n-play" решением, да и не настолько у меня прокачан скилл в этом плане.

Но таки это не intent, а свойство!

Не силён в нюансах ведра, так что могу местами ошибаться

Для старых андроидов может сработать свойство dev.bootcomplete. Хоть в костыльном, хоть в бескостыльном вариантах.

Спасибо

В getprop оно есть, так что на досуге попробую. Пока на отлично справляется Tasker (почти)

[kaztost]

Источник цитаты Это трудно назвать "plug-n-play"

В данном случае, правильного "plug-n-play" решения нет. Ну, кроме явного использования ява-машины.

Кстати, если вы на 4.2, у вас как, getprop нормально работает в ssh-сессии? Насколько я помню, в некоторых случаях dropbear удалял файловый дескриптор свойств и getprop переставал работать. Не замечали?

На новых версиях проблем с этим уже нет.

[ZigZag]

Кстати , если вы на 4.2, у вас как, getprop нормально работает в ssh-сессии? Насколько я помню, в некоторых случаях dropbear удалял файловый дескриптор свойств и getprop переставал работать. Не замечали?

Я хз, но как-то не довелось юзать dropbear из entware на том смарте. Юзаю sshdroid, там тот же dropbear + меньшее количество возни. Там с getprop проблем вроде не было, но могу проверить

[ZigZag]

Как выяснилось, у автозагрузки через tasker есть один минус - когда память андроида переполняется, он грохает tasker и вместе с ним паровозиком валятся запущенные им демоны. Радует, что это происходит крайне редко.