Работа с cron под Android и добавление shell-скрипта в автозапуск при загрузке устройства
В связи с тем, что мобильные устройства уже давно имеют обширный функционал, то задачи автоматизации можно смело переносить и на них. И, как нельзя лучше, здесь так же хорошо подходит cron для их выполнения. Но если в «обычных» Linux системах настройка cron занимает мало времени, то Android устройство требует более сложной работы по его настройке.
Если тебе интересна тема автоматизации и ты хочешь, чтобы твои shell-скрипты запускались сразу же после загрузки устройства, да еще и могли бы запускаться по таймеру — добро пожаловать под кат!
Предисловие
Я занимаюсь автоматизацией мобильных устройств под Android. И во время выполнения автоматических скриптов происходит множество непредвиденных ситуаций, даже если для тестирования используются одинаковые устройства.
Самые популярные проблемы:
0. Скрипт автоматизации выполняет не то, что ты хотел
1. Мобильное приложение автоматически выгружается
2. Автоматическая перезагрузка телефона
3. Мобильное приложение автоматически не запускается после перезапуска
4. Wi-Fi модуль произвольно отключается, не находит сеть, не подключается к сети
5. Мобильная сеть неожиданно пропала
6. Телефон ушел в спящий режим
7. Отпал прокси или сам сервер или сервер вернул странный ответ
Из-за этого приходится постоянно следить за устройством и отлавливать эти непредвиденные ситуации.
Таким образом, я пришел к тому, что cron с «правильными» скриптами позволит отследить программные сбои и восстановить скрипт автоматизации или запустить его заново. Но как оказалось, хотя Android содержит ядро Linux, но есть особые нюансы, с которыми пришлось разбираться. Итак, давайте приступим к настройке!
Настройка Cron
Настраиваем окружение
Настройка ручного запуска
Как видно из последней строки, инструкции по умолчанию должны храниться в директории /var/spool/cron/crontabs, которая автоматически не создается и если мы запустим команду и потом проверим запустился ли процесс через , то его там может и не быть, т.к. он не смог получить какие-либо инструкции. Поэтому давайте выполним команду и посмотрим в чем причина. Скорее всего у вас будет подобная ошибка:
crond: can’t change directory to ‘/var/spool/cron/crontabs’: No such file or directory . В данном случае это нормально, т.к. в будущем мы сами укажем путь до исолняемого crontab файла.
4. Создадим простой crontab файл:
Теперь у нас есть задание, которое каждую минуту будет добавлять слово text в файл /sdcard/test.txt
Запускаем: и получаем следующий лог:
Конечно, немного удивляет, ведь если мы выполним команду whoami то в результате она вернёт root.
5. Добавим пользователя root, раз crond просит:
Из-за отсутствия данного файла, я понял, что в Android системе он совсем не задействован. Если вы уверены в том, где вы будете хранить свои crontab файлы, то вы можете заменить строку /system/etc/crontabs на нужную вам. Снова выполняем команду
И получаем следующее:
Хотя, если верить логу задача в crond прописалась, но в моем случае файл не создался. Решить проблему можно очень просто:
Ну хочет он, чтобы существовала там директория, кто мы такие, чтобы ему запрещать! Запускаем снова и видим:
Ошибки ушли, и появилась строка crond: child running /system/bin/sh. Наконец-то cron у нас успешно завелся, и можно переходить ко второй части!
Автоматическая загрузка shell-скрипта
В Linux системе есть директория init.d, которая отвечает за автозапуск сразу же после загрузки системы, поэтому попробуем идти по этому пути!
1. Проверяем, существует ли данная директория у вас на устройстве (это /etc/init.d либо /system/etc/init.d — это тот же смонтированный раздел etc ). В моем случае её нет. Ну что, тогда создаем:
Теперь добавим туда какой-нибудь простенький скрипт, например:
Перезагружаем устройство и смотрим, случилось ли чудо… К сожалению, у меня файл не появился.
Исследуем систему дальше и ищем какой-нибудь init файл, который может запускать скрипты после запуска. У меня на устройстве оказался файл в /init.rc. Ну что, попробуем его изменить и перезагрузим устройство:
Но файл опять не создался. Идем смотреть на файл /init.rc и наша запись пропала и файл как бы и не менялся, т.к. дата создания стоит совсем какая-то странная (в моем случае 01 янв. 70 05:00:00).
Продолжаем разбираться, и оказывается что данный файл храниться в boot.img, и каждый раз достается из него. И для того, чтобы изменить функционал файла init.rc нужно выполнить все это.
Но есть более простой способ, который поможет решить данную задачу. Для этого способа мы можем использовать следующий shell-скрипт (скажем спасибо Ryuinferno):
Приступаем к внедрению скрипта! В моем случае он будет называться init.sh.
1. Загружаем файл на sdcard мобильного устройства:
2. Копируем в память мобильного устройства и устанавливаем нужные права:
3. Запускаем на выполнение:
И обращаем внимание на лог, который выводится. Вот мой лог:
Как видим из лога, ошибок нет, поэтому смело перезагружаем устройство! Возможно у кого-то уже все заработало и вы смогли найти файл /data/Test.log, но у меня его нет. Проверим директорию /system/etc/init.d используя команду ls:
Как видим, задачи успешно созданы. Возможно все же придется менять boot.img, но давайте в начале проверим, а где у нас файл install-recovery.sh с помощью команды
Как можем заметить, у нас 2 файла, которые лежат в разных местах. По дате создания мы можем заметить, что скрипт создал файл в директории /system/etc/install-recovery.sh, хотя, возможно, в некоторых случаях он должен создавать его в /system/etc. Давайте переименуем файл в bin и скопируем файл из etc:
UPD: Обратите внимание, что контекст безопасности у обоих файлов должен совпадать. И если вдруг при копировании у вас он сбился (хотя по идее, такого быть не должно), вам необходимо его будет восстановить (например, через утилиту chcon). Посмотреть полную информацию по файлу можно с помощью ls -lZ:
Тут u:object_r:system_file:s0 и является контекстов безопасности.
И снова перезагружаем устройство… И вот, наконец-то долгожданный УСПЕХ! Файл /data/Test.log появился!
Раз все работает, идем в /system/etc/init.d и создаем shell-скрипт. А в нем как-раз запустим наш crond на выполнение:
После загрузки проверяем, запустился ли crond:
И на этом могли бы мы уже закончить, но давайте подождем минуту и посмотрим, произошла ли запись в наш файл… Ну как вы уже поняли, опять ни чего не сработало. Дело в том, что данный процесс нужно запустить от супер пользователя. Изменим скрипт в файле 99cronstart:
UPD: Возможно в вашем случае su будет иметь другой путь, тогда воспользуйтесь командой which su и замените путь, на ваш.
Теперь наше Android устройство поддерживает и задачи cron и может содержать shell-скрипты для автоматического запуска!
Ну и напоследок, скрипт, который будет запускать наше приложение, если его нет в процессах и сохранять информацию о том, что находилось на главном экране до запуска нашего приложения:
Источник
Run scripts on android
Скрипты на shell под Android
Тема посвящена созданию, отладке скриптов на шелле, а также освоению и изучению всевозможных утилит командной строки Андроида.
Для полноценной реализации желаемого под Андроидом как правило понадобятся root-права и busybox.
Данная тема выросла из темы Tasker (родительская тема), поэтому не удивляйтесь, если Вас внезапно отправят туда. (Tasker — это шелл в Андроиде.) Из данной темы выросла дочерняя тема Ядро Linux изнутри, все вопросы по ядру следует задавать в ней.
В теме нет куратора. Если в теме есть пользователь, желающий стать Куратором и соответствующий Требованиям для кандидатов, он может подать заявку в теме Хочу стать Куратором (предварительно изучив шапку темы и все материалы для кураторов).
До назначения куратора, по вопросам наполнения шапки, обращайтесь к модераторам раздела через кнопку 
под сообщениями, на которые необходимо добавить ссылки.
Сообщение отредактировал derak1129 — 22.06.20, 23:05
Для начала перетащу своё сообщение из темы Таскера для лучшего понимания вопроса, о чём речь, и как можно применить.
# помощь урок таскер tasker пример шелл shell перехват аппаратных кнопок
Описание примера Работа shell-скрипта для перехвата аппаратных кнопок телефона.
Знатокам команд ОС linux и их специфики — не смеяться.
Нужен рут и busybox .
Всесторонняя поддержка была оказана уважаемым username11, где я порой только нажимал на кнопки, следуя множеству его мудрых советов.
Данный пример — оффтоп! 😀 потому что таскер в нём не участвует. Совсем. Только шелл, только хардкор. Пример кстати рабочий))
Так как это только пример, каждый может растащить его на множество кусочков и использовать нужные части в связке со своими нуждами.
Вообще, текста будет много, потому что я болтун..
Приступим к делу. Вот результирующий пример, и сразу напишу, что он делает, а потом разбор:
Итак, эта строчка (это ОДНА строчка) запущенная в терминале, или через Задачу Таскера «Run script» запускается в память (и висит там! терминал можно закрывать) и делает следующее: Она отслеживает нажатие аппаратной кнопки Громкость Вниз (думаю на большинстве Xperia заработает тоже, официально отлажено под Xperia Ray) при выключенном экране, и включает (и выключает) фонарик.
Начнём, пожалуй, с перехвата кнопок. Как наиболее интересующую общественность возможность. Надо не забывать при этом, что штатные функции телефона, происходящие при нажатии той или иной кнопки, телефоном параллельно ловятся и функции отрабатывают. Так что, повесить исключительно «свои» полезняшки на нажатия не получится. Почему я и упростил в процессе изучения перехвата себе задачу — реагирую я на кнопки только при выключенном экране. При штатной блокировке телефон не реагирует на кнопки громкости при выключенном экране.
Вообще, получается красиво: нажимаешь качельку громкости и МГНОВЕННО включается фонарь, а экран при этом остаётся выключенным.
Отладка скрипта, это собственно 99.9 процента всего времени, потраченного на, поэтому гораздо удобнее «общение» будет проводить в проводном или беспроводном adb. Вертеть варианты отладки через терминал телефона утомительно. (а отладки будет много).
Часть 1. Перехват. Теория.
Итак, перехват. Подглядывать за нажатиями кнопок мы будем программой (консольной текстовой программой) «ПолучитьСобытие», getevent. Можно просто набрать (с рут правами) в терминале имя команды и завороженно смотреть на бегущие строки))
# getevent
Да, вот такие пачки на каждое действие!
0004 0004 00000004
0001 0072 00000001
0000 0000 00000000
0004 0004 0000000c
0000 0000 00000000
0004 0004 00000014
0000 0000 00000000
0004 0004 0000001c
0000 0000 00000000
0004 0004 00000024
0000 0000 00000000
0004 0004 00000024
0000 0000 00000000
0004 0004 00000004
0001 0072 00000000
0000 0000 00000000
0004 0004 0000000c
0000 0000 00000000
0004 0004 00000014
0000 0000 00000000
0004 0004 0000001c
0000 0000 00000000
Так система (а мы подглядываем за реальными кодами, которые обрабатывает и система) различает нажатия, отжатия, а так же — _долгие_ нажатия, если они есть. То есть, если ловить «Долгую громкость вниз» — то это всё ручками, самим засекать сначала нажатие, и какая была пауза до отжатия, ну, до удержания, да. А только потом вызывать своё действие. До этого у меня пока руки не дошли, но есть такой ключик ‘-t’ — показывать временные отметки каждого прилетевшего кода.
Понажимав все свои три кнопки)) я пришёл к выводу о достаточности в моём частном случае ловли кода ‘0004 0004 00000004’, правда он случается и в нажатии и в отжатии, но это мы поймаем и учтём.
username11 пишет, что реальным кодом действия (нажатия, возни по тачу, еще какой датчик) служит первая строка, а остальные это «эхо системы» на первое действие — какие-то, как я понял, генерации уже «софтовые», дополнительных кодов для других системных ловушек. Что бы в другом нужном процессе тоже возникло срабатывание на действие. В добавок: по моей логике, коды-пачки нулей — это есть завершение «описания» кода. То есть, каждый ноль (‘0000 0000 00000000’) это конец логической «строки» event’а. В любом случае это лир.отступление, к делу его не пришьёшь, а коды ловить придётся))
Итак, я выбрал для ловли кнопки Громкость Вниз код всего лишь одной строки ‘0004 0004 00000004’, который уникален в пределах устройства pm8058-keypad (/dev/input/event1).
Дальше в дело вступает команда read в замесе с командой while, в таком виде:
формализованно: «ввод_данных | while read var1; do [наша построчная обработка] ; done»
разбор:
ввод_данных в данном случае это наш поставщик данных, «getevent /dev/input/event1»
вертикальная палка это перенаправление вывода консоли (то, что мы видим как появляющиеся строки после команды getevent) в другую команду на обработку дальше. (да, я пишу для таких валенков, как я)).
while read совокупность команд делающих следующее: while («пока») обеспечивает нам бесконечный цикл считывания строк «из-под» getevent’а, а read («читать») каждую строку вида ‘0004 0004 0000001c’ распихивает по переменным шелла, имена которых указаны после слова ‘read‘.
Например. Команда «ввод_данных | while read dev code» первое «слово» ДО РАЗДЕЛИТЕЛЯ (у нас это пробел) положит в переменную dev, а остальной хвостик (до конца строки) в переменную code. (Обращаться в шелле к значениям переменным мы потом будет $dev и $code). И равны они будут dev=’0004′, code=’0004 0000001c’. А если переменных будет скажем три: «ввод_данных | while read dev code1 code2», то наш пример, поданный на вход команды, она раскидает так: dev=’0004′, code1=’0004′, code2=’0000001c’. Правда здоровско?
Сам я пришёл к локальному выводу, что мне проще ловить ВСЮ строку (‘0004 0004 00000004’) в одну переменную, то есть у меня это ‘while read code’. И одну переменную $code уже сравнивать на нужное значение.
Всё, что идёт за знаком «точка с запятой» (semicolon, так сказать) после команды read, это есть команды обработки результата «распихивания» _каждой_ строки с кодами, прилетающей от getevent.
Локальный вывод: То есть, заказали мы прерывания от устройства event1, аппаратных кнопок, и всё, всё «висит» и бездействует. Система спит. Нажатие кнопки (любой) пробуждает систему (она отрабатывает сама) и присылает в getevent пачку строк с произошедшими событием. Мы раскидываем полученные строки с помощью while read на составляющие и уходим на дальнейшую обработку каждой строки отдельно, сравнивая, наша ли эта, искомая, строка, или нет. И потом запускаем боевую нагрузку, выполняем какое-то действие (включаем фонарик, как я, или вызываем сразу задачу таскера). (В принципе, вот всё решение). Но, об этом всём в своё время, ниже, а пока меня ждала целая серия засад:
Часть 2. Workarounds. Первое столкновение с практикой.
Сразу же после того, как я ринулся в бой, у меня ничего не заработало. Простая проверочная команда:
# getevent /dev/input/event1 | while read code; do echo $code; done
..ничего не показывала!
(смысл команды: получаем из getevent массив строк, с помощью while read переменная растаскиваем массив на строки и просто в каждом цикле командой echo выводим значение переменной (значок бакса перед именем), в данном случае всю строчку залпом, она в единственной переменной code).
Чудом я обнаружил, что показывает она результат, если понажимать кнопки много раз. Оказалось следующее. На «палке» идёт буферизация! То есть, перенаправление потока данных из-под getevent работает, конечно же, но система буферизирует данные — собирает их в кучку и отдаёт дальше только после накопления некоего объёма, видимо около 4к. И username11 даёт следующий совет: взять команду бизибокса script и обрамить ею вышеозначенную строку. Как я понял, script велит системе знать «устройство вывода» как (условно) tty, а не блочное устройство. И просовывать через «палку» каждый байт сразу, не дожидаясь накопления полного буфера.
То есть следующая проверочная команда замечательно заработала:
# script -q -c ‘getevent /dev/input/event1’ /dev/null | while read code1 code2 code3; do echo «code1:$code1, code2:$code2, code3:$code3»; done
(да, вывод команды script пришлось не забыть спустить в унитаз /dev/null)
(этот пример выводит при нажатии кнопок пачки строк вида: «code1:0004, code2:0004, code3:00000004» теперь не сутулясь и полной грудью, СРАЗУ после нажатия, ничего не откладывая в ящик).
Однако, настало время разбора результатов нажатий и отсев нужных, это для меня было совершенно свежо)) Вылилось это, после многодневного (неспешного) изучения инет манов-факов-хавтушек в следующее:
# script -q -c ‘getevent /dev/input/event1’ /dev/null | while read code1 code2 code3; do [ «$code1» = «0004» -a «$code2» = «0004» -a «$code3» = «00000004» ] && echo «code1:$code1, code2:$code2, code3:$code3» ; done
(строчечка уже «ого», да. Значит, что я делаю: рву каждую строчку на три части, code1-3, и затем сравниваю последовательно значение code1 с 0004, и так далее, и в итоге вывожу результат ТОЛЬКО на нужное мне нажатие (знак && говорит о том, команда echo выполнится только в случае выполнения всего сравнения в квадратных скобках)).
НЕ РАБОТАЕТ! ((
Я опять к начальству. (причём, как я потом выяснил в процессе перебирания разных вариантов, два первых сравнения работают! затык в третьем). Долго я мыкался, пока не был наставлен на команду познакового вывода данных:
# script -q -c ‘getevent /dev/input/event1’ /dev/null | od -cb
(она выводит значения байтов текста в разных форматах, ну, типа строчка 12345 будет выглядеть как 31 32 33 34 35). И сразу после было обнаружено, что в конце, за последним 00000004 кроме штатного линуксячьего знака переноса строки 0D, еще затесался (совершенно «ДОСовский») 0A. И конечно while read законно пихает его в последнюю переменную, в моём случае в code3. А сравнение-то у нас до знака, если в конце строки левый хвостик, то сравнение и не получается.
Начальник напредлагал мне (уже на грани моего понимания линуксовой ком.строки) вариантов этого очередного обхода, я остановился на вот таком:
тут первые проверки ] && echo «$code3» | grep -q ‘^00000004.$’ && echo «code1:$code1 (а в конце пошёл вывод через echo)
Заработало!
(как я понял, поиск строки через grep с ключом ‘-q’ даёт значение true/false в наш боян каскад двойных амперсендов && по сборке логики сравнения. Циркумфлекс и бакс с точкой остались уже ЗА пределами моего понимания, но верю, что это поиск от начала строки и опускание произвольного конца, того самого, что прилепился из знаков 0D и 0A).
Таким образом, полный поиск моей последовательности (напомню, ‘0004 0004 000000004’) БЕЗ боевой пока нагрузки, стал выглядеть так:
(code я опять, набаловавшись с дроблением строки на части, слепил в кучу, всё равно у меня пока один полностроковый код)
# script -q -c ‘getevent /dev/input/event1’ /dev/null | while read code; do echo «$code» | grep -q ‘^0004 0004 00000004.$’ && echo «code:$code»; done
(и выкинул квадратные скобки, всё равно основной результат даёт grep)
Вот, первый результат. В терминале выводится одна строчка на нажатие нужной мне кнопки, и одна на отжатие. На другие кнопки ничего не выводится. Можно привинчивать включение/выключение фонаря!
Часть 3. Фонарик. Долгая дорога в дюнах.
Ну, тут я прилично еще поплутал, Начальник подсказал, как проще сделать «переключалку» на командной строке, из 0 в 1 и обратно, _одной_ командой. (как я спросил: «как сделать xor ax,1» ))) Оказалось: а=$(expr 1 — $a).
Я заранее знал «переменную» включения фонаря, у меня (думаю, и на всех xperias так же) это /sys/class/leds/torch/brightness. Значение 0 не светит, 255 — светит. (и все промежуточные от 3 до 255 работают, но да про красиво-плавно включаемый фонарик и как я писал бинарь на си для андроида прямо на телефоне, это сказ отдельный)).
Еще мне нужно было найти, включен экран в данный момент или нет, потому что получая управление в точке echo code:$code я решительно (пока) не представлял, что с экраном. А если он включен, это штатное системное изменение громкости, и в ДАННЫЙ момент включать фонарик совершенно не обязательно.
Полазив, я нашёл. Рядом. /sys/class/leds/lcd-backlight/brightness тоже, 0-255, что ли. По крайней мере выключенный экран «0», включенный — НЕ ноль.
Ииии.. я запилил. Полный скрипт вы видели уже в начале. Ой, нет, это еще не всё)))
Часть 4. Последняя засада
В итоге username11 научил меня обрамлять всё скобками, за которыми писать одиночный амперсенд, &. Признак того, что скрипт должен остаься висеть в памяти системы, остаться резидентом. И отдать управление в командную строку. И тут была последняя засада — стоит напустить скрипт резидентом, он переставал работать! Так работает, а резидентом — нет! Как выяснилось после команды ps (список всех процессов), что мой скрипт в памяти-то висит, а хочет ввода-вывода, (я так ине нашёл, что за команда «хочет»), поэтому система его тормозит и ничего делать ему не даёт.
В итоге мне пришлось в конце для решения этой проблемы (еще один, последний, костыль)) написать:
# ( весь мой стрипт ) /dev/null 2>/dev/null &
(то есть всех охочих до общения спустить в унитаз).
Теперь всё заработало.
Повторим))
# (rep=0; script -q -c ‘getevent /dev/input/event1’ /dev/null | while read code; do torch=`cat /sys/class/leds/torch/brightness`; screen=`cat /sys/class/leds/lcd-backlight/brightness`; (echo «$code» | grep -q ‘^0004 0004 00000004.$’) && [ «$rep» = «0» ] && [ «$screen» = «0» ] && ( torch=$(expr 255 — $torch); echo «$torch» > /sys/class/leds/torch/brightness ); rep=$( expr 1 — $rep ); done ) /dev/null 2>/dev/null &
Что я делаю в скрипте:
— инит двоичной переключалки для ловли нажатия и отжатия
— после while read попадаем в основной разбор, что за строка прилетела
— читаю текущее значение фонаря
— читаю текущее значение экрана
— и дальше большое условие, сконкатенированное по && из условий:
— это наш код
— это нажатие (а не отжатие)
— экран выключен
— инверсия значения фонаря
и боевая нагрузка:
— запись нового значения фонаря (если был выключен — включает и наоборот)
— инверсия значения переключалки нажатия-отжатия.
Домашнее задание от username11 я так пока и не выполнил((, а оно вот:
1) выяснить, кто хочет ввода-вывода и устранить.
2) убрать лишние круглые скобки. каждые скобки, это лишний шелл запущенный каскадом.
Такскера тут вообще нет, как вы видите. Справившись с половиной этого дела, отсутствие таскера было уже делом принцпа)) зачем? когда всё «шелльно» и легко. А огромная дурильня-таскер испортит всю красоту. Да и для чего? Мигнуть фонариком?
Таскер по идее, как Начальник неоднократно писал, должен вызываться через am broadcast в «теле» боевой части.
Возможно, это не то, чего ждали массы)) но в любом случае, что-то почерпнуть полезное можно.
Любые советы, правки, возможные будущие _Приложения_ к этому сообщению, снятие костылинга, решения домашнего задания — решительно принимаются!
Сообщение отредактировал username11 — 23.02.20, 15:49
Источник
