Привіт, Мі-Фани!

dyASubaQeRz2mz0m8vjd0Sblwhz2bIwWp6QLqW4.jpg (53.39 KB, Downloads: 20)

2018-01-17 03:16:25 Upload

Велика доля системних параметрів Android, прихована від очей користувача, зберігається в єдиному файлі під назвою build.prop. Повноцінна зміна налаштувань допоможе вдихнути друге життя у гаджет: покращити автономність і продуктивність, оптимізувати інтерфейс. В статті ми покажем, як зручно редагувати build.prop, і приведемо приклади корисних твіків, а також ті, які переходять із статті в статтю на різних ресурсах, але насправді не працюють.
Для чого редагувати build.prop?
Файл build.prop функціонує таким чином: при запуску смартфона з нього зчитується вміст, який в тій чи іншій мірі впливає на логіку роботи коду операційної системи. Серед таких прихованих від користувача налаштувань є як глибинні системні, які краще не торкати, так і ті, які можуть бути безболісно змінені. Наприклад, додаючи кілька рядків у build.prop ви зможете прискорити завантаження гаджета, усунути затримку при вхідному виклику або увімкнути автоматичне відображення на екрані блокування. Як це зробити? Зараз ми все розкажемо.
Як редагувати build.prop?
Все, що вам потрібно для внесення змін — редактор текстових файлів і права суперкористувача (root). Дізнатися, як отримати root, можна на нашому форумі, за посиланням: Отримання ROOT-прав на MIUI. Для безпосередніх змін у файлі можна користуватися звичайним текстовим редактором — для цього треба самостійно знайти файл по шляху /system/build.prop. Але набагато зручніше вносити зміни за допомогою спеціалізованої програми, наприклад BuildProp Editor:
Завантажити:
Google Play
Build_Prop_Editor_v1.1.9_RUS.apk (738.36 KB, Downloads: 9) 2018-01-17 02:40:56 Upload Click on the file to download the attachment
Read permissions: 10

dyASuOz2HpHKZiuUodA3cevTOGGkUv9.png (64.19 KB, Downloads: 19)

2018-01-17 03:16:30 Upload

Перед тим, як приступити до експерименту, необхідно обов’язково зробити резервну копію файлу. Редактор BuildProp зберігає оригінал автоматично при першому запуску. Якщо ж ви вирішите користуватися звичайним текстовим редактором, то не забудьте зробити копію вручну. Якщо щось піде не так, то вам буде достатньо замінити «пошкодженний» build.prop резервної копією, щоб повернути все на свої місця.

dyASu0Ffz2ltLxyKZC8cVd1nMBAtXvf.png (11.19 KB, Downloads: 21)

2018-01-17 03:16:21 Upload

dyASuCNLPGtrhq01P9590TdnNyWbJe.png (12.56 KB, Downloads: 20)

2018-01-17 03:16:25 Upload

Покращення інтерфейсу
Для зручності ми розбили твіки на кілька категорій. Перша — вдосконалення інтерфейсу. Такі твіки найбільш наглядні, оскільки вони впливають не тільки на параметри системи, але й на її зовнішній вигляд.

• Миттєвий звук виклику

Залежно від моделі смартфона та встановленої прошивки при запуску дзвінка гаджет може витратити деякий час на перевірку з’єднання, перш ніж запустить мелодію. Для користувача це виглядає таким чином: спочатку у пристрої просто включений дисплей, і тільки через секунду з невеликим відображається сам дзвінок. Виправити таку поведінку можна шляхом введення в build.prop двох рядків:

ro.telephony.call_ring.delay = 0
ring.delay = 0
Після перезавантаження пристрою всі дзвінки будуть поступати миттєво.

• Автоповорот екрана блокування

За виключенням планшетів, практично жодний пристрій на Android не дає можливості вільно повертати екран блокування при повороті смартфона. Так, ця функція потрібна рідко, але якщо гаджет встановлений горизонтально в автомобільному тримачі, то спроба введення пароля або графічного ключа перетворюється в справжню еквілібрику. Все, що необхідно, це дописати декілька рядків у build.prop
lockscreen.rot_override = true
log.tag.launcher_force_rotate = VERBOSE
Результат:

dyASua7TDoYqeoFPblwfGLJ3A9HUPv.png (155.38 KB, Downloads: 19)

2018-01-17 03:16:24 Upload

Покращення продуктивності
До цієї категорії ми віднесли твіки, які тим або іншим чином збільшать швидкість роботи вашого гаджета.

• Пришвидшення завантаження

Сучасні смартфони частіше завантажуються, деколи довше, ніж звичайні ПК. Трішки змінивши налаштування у build.prop, можна з легкістю збільшити швидкість завантаження гаджета у півтора-два рази! В цьому допоможуть наступні налаштування:
debug.sf.nobootanimation = 1
ro.config.hw_quickpoweron = true
Після внесення цих налаштувань буде змінено режим виключення гаджета, а також відключена завантажувальна анімація розробника програмного забезпечення. В результаті при завантаженні смартфона ви якийсь час не будете нічого спостерігати на екрані. Лякатися цього не потрібно: саме завдяки вимкненню непотрібних анімацій тестовий смартфон став завантажуватися всього за 30 секунд замість попередніх 50 секунд.

• Прискорення роботи із пам’яттю

За замовчуванням Android логує безліч дій в спеціальний файл, однак він потрібен лише для розробників для дебага додатків. Звичайним користувачам цей лог не знадобиться, а тому варто його вимкнути, додаючи рядок у build.prop
logcat.live=disable
Відключення лога зменшує кількість дискових операцій, що позитивно впливає на швидкість роботи внутрішньої пам’яті смартфона. Правда, різниця буде замітною лише на гаджетах із слабкими типами пам’яті: у нашому випадку швидкість послідовного запису збільшилася на 2 МБ / с.

dyASuKdjLkK3ymAGoBWmFbBz2CcvQJ8.png (23.33 KB, Downloads: 20)

2018-01-17 03:16:28 Upload

dyASuGlvtxL0wz2IiKq0W7HvYvN2G2Z.png (23.25 KB, Downloads: 19)

2018-01-17 03:16:26 Upload

• Прискорення мережі

Цей твік збільшує розміри TCP-буферів, що допоможе збільшити швидкість повільного інтернет-з’єднання, особливо при використанні мобільних мереж. Ну а прописування DNS-серверів Google в деяких випадках дозволяє знизити час пінгу.
net.tcp.buffersize.default = 4096,87380,256960,4096, +16384,256960
net.tcp.buffersize.wifi = 4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts = 4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs = 4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge = 4096,87380,256960,4096,16384,256960
net.rmnet0.dns1 = 8.8.8.8
net.rmnet0.dns2 = 8.8.4.4
net.dns1 = 8.8.8.8
net.dns2 = 8.8.4.4
У нас різниця виявилася відчутною, але не варто забувати, що найбільший вплив на швидкість викликаэ завантаження базових станцій.

Швидкість до зміни

dyASuWF9ldZtkz0Nb3GQvOXXUz2ugK8I.png (108.75 KB, Downloads: 19)

2018-01-17 03:16:32 Upload

Швидкість після зміни

dyASu4tUgkqJqae5JuUJvoFrz0z0Z3ie.png (108.93 KB, Downloads: 20)

2018-01-17 03:16:22 Upload

• Збільшення автономності

На жаль, чудес не буває — дворазового збільшення автономності досягти не вдасться жодними твіком. Але додати зайві 30-60 хвилин до часу роботи гаджета цілком можливо.
Збільшення інтервалів сканування Wi-Fi. За замовчуванням Android сканує навколишні мережі Wi-Fi кожні 20-90 секунд. Причому робить це навіть тоді, коли Wi-Fi вимкнений, але дозволений фоновий пошук мереж для збільшення точності визначення місця розташування. Щоб розширити даний інтервал, необхідно додати в файл build.prop рядок:
wifi.supplicant_scan_interval=200
Тут число 200 і є інтервалом сканування мереж в секундах.
Ще більше корисних твиков ви можете знайти на форумі 4PDA:

• Даремні твики, які нічого не покращують

Крім дійсно працюючих твіків, наведених в цій статті, існує чимало таких, які широко розійшлися по мережі, але насправді не мають жодного впливу на роботу системи. Відповідне дослідження провів один з користувачів ресурсу xda. Він проаналізував вихідний код AOSP і CyanogenMod і з’ясував, що безліч популярних твіків просто не згадані у вихідному коді Android. Серед них є найрізноманітніші записи.
Твіки, що не заощаджують заряд:
ro.ril.disable.power.collapse
ro.mot.eri.losalert.delay
ro.config.hw_fast_dormancy
ro.config.hw_power_saving
Твіки, що не прискорюють роботу:
windowsmgr.max_events_per_sec
persist.cust.tel.eons
ro.max.fling_velocity
ro.min.fling_velocity
debug.performance.tuning
video.accelerate.hw

• Інші даремні твики

Вони призначені для відключення перевірки байт-коду Dalvik і заборони вивантаження лончера з оперативної пам’яті. Колись вони дійсно працювали, але абсолютно не актуальні для сучасних версій Android через зміну внутрішньої архітектури ОС:
dalvik.vm.verify-bytecode
ro.HOME_APP_ADJ
І ще трохи різних не працюючих твіків:
ro.media.dec.jpeg.memcap
ro.config.nocheckin
profiler.force_disable_ulog
profiler.force_disable_err_rpt
persist.sys.shutdown.mode
ro.kernel.checkjni
Цікаво, що хоча деякі з цих записів і були корисні для старих версій Android, деякі не працювали взагалі ніколи, будучи свого роду плацебо. А чому подібні записи взагалі виникли — зараз уже й не відомо. Втім, від внесення таких записів в build.prop смартфон не стане гірше працювати — всі недійсні записи просто будуть проігноровані.
ВИСНОВОК
Навіть незважаючи на те, що багато хто з рекомендованих на форумах і різних сайтах твики взагалі не функціонують, файл build.prop залишається непоганою можливістю поліпшити інтерфейс і роботу вашого смартфона. Так що отримуйте права суперкористувача, робіть резервну копію налаштувань і сміливо експериментуйте!

Всесторонняя поддержка была оказана уважаемым username11, где я порой только нажимал на кнопки, следуя множеству его мудрых советов.
Данный пример — оффтоп! 😀 потому что таскер в нём не участвует. Совсем. Только шелл, только хардкор. Пример кстати рабочий))
Так как это только пример, каждый может растащить его на множество кусочков и использовать нужные части в связке со своими нуждами.
Вообще, текста будет много, потому что я болтун..
Приступим к делу. Вот результирующий пример, и сразу напишу, что он делает, а потом разбор:

(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.$’) && && && ( torch=$(expr 255 — $torch); echo «$torch» > /sys/class/leds/torch/brightness ); rep=$( expr 1 — $rep ); done ) < /dev/null > /dev/null 2>/dev/null &
Итак, эта строчка (это ОДНА строчка) запущенная в терминале, или через Задачу Таскера «Run script» запускается в память (и висит там! терминал можно закрывать) и делает следующее: Она отслеживает нажатие аппаратной кнопки Громкость Вниз (думаю на большинстве Xperia заработает тоже, официально отлажено под Xperia Ray) при выключенном экране, и включает (и выключает) фонарик.
Начнём, пожалуй, с перехвата кнопок. Как наиболее интересующую общественность возможность. Надо не забывать при этом, что штатные функции телефона, происходящие при нажатии той или иной кнопки, телефоном параллельно ловятся и функции отрабатывают. Так что, повесить исключительно «свои» полезняшки на нажатия не получится. Почему я и упростил в процессе изучения перехвата себе задачу — реагирую я на кнопки только при выключенном экране. При штатной блокировке телефон не реагирует на кнопки громкости при выключенном экране.
Вообще, получается красиво: нажимаешь качельку громкости и МГНОВЕННО включается фонарь, а экран при этом остаётся выключенным.
Отладка скрипта, это собственно 99.9 процента всего времени, потраченного на, поэтому гораздо удобнее «общение» будет проводить в проводном или беспроводном adb. Вертеть варианты отладки через терминал телефона утомительно. (а отладки будет много).
Часть 1. Перехват. Теория.
Итак, перехват. Подглядывать за нажатиями кнопок мы будем программой (консольной текстовой программой) «ПолучитьСобытие», getevent. Можно просто набрать (с рут правами) в терминале имя команды и завороженно смотреть на бегущие строки))
# getevent
вывод начнёт сыпать вот такой штукой: /dev/input/event7: 0003 0010 fffffed0
/dev/input/event7: 0003 0011 ffffff5a
/dev/input/event7: 0003 000a 000003ee
/dev/input/event7: 0000 0000 00000000
/dev/input/event7: 0003 0003 00001138
/dev/input/event3: 0003 0000 00000006
/dev/input/event7: 0003 0004 000000d3
/dev/input/event3: 0003 0001 00000007
/dev/input/event7: 0003 0005 000000b3
/dev/input/event3: 0003 0002 00000078
/dev/input/event7: 0003 0000 00000028
/dev/input/event3: 0003 0028 00000043
/dev/input/event7: 0003 0001 ffffffde
/dev/input/event3: 0000 0000 00000000
/dev/input/event7: 0003 0002 fffffd4d
/dev/input/event7: 0003 0010 fffffecf
/dev/input/event7: 0003 0011 ffffff60
/dev/input/event7: 0003 000a 000003f2
в данном случае события поступают от ВСЕХ устройств телефона, нам надо выяснить, где наши аппаратные кнопки. И получать «прерывания» только от них, что бы проще было обрабатывать прилетающие коды, да и, понятно, «просыпаться» лишний раз от любого-каждого датчика положения (к примеру) — нам не нужно, батарейку быстро стопчем. (тем более, если результат просыпания потом упрётся в «жирный» таскер).
При запуске команда getevent в самом начале выдаёт список всех доступных устройств и потом уже начинает сыпать строками событий. Можно после запуска быстро нажать Ctrl-C, что бы список устройств не уехал с экрана. А можно воспользоваться ключом команды ‘-S’, и команда покажет все допустимые события и завершится:
# getevent -S
вывод команды в моём случае: add device 1: /dev/input/event8
name: «atdaemon»
add device 2: /dev/input/event1
name: «pm8058-keypad»
add device 3: /dev/input/event7
name: «compass»
add device 4: /dev/input/event6
name: «simple_remote_appkey»
add device 5: /dev/input/event5
name: «simple_remote»
add device 6: /dev/input/event4
name: «apds9702»
add device 7: /dev/input/event3
name: «bma150»
add device 8: /dev/input/event2
name: «clearpad»
add device 9: /dev/input/event0
name: «msm_pmic_pwr_key»
ff00
ff00
ff00
ff00
ff00
ff00
ff00
ff00
ff00
В данном случае нас интересуют аппаратные кнопки, опытным путём выяснилось, что это устройство pm8058-keypad, то есть путь к устройству ‘/dev/input/event1’. За сим изучение составляющих поставщиков событий заканчиваем. (а там есть и компас, и отдельно кнопка выключения питания, и тач-экран..).
Теперь можно сузить запрос к системе до целевого. Дело в том, что на разных устройствах эти вот eventN все разные. В каком порядке их запрограммировал производитель, так они и показываются. (я к тому, что копировать строчки тут не получится, придётся искать самому под свой телефон).
Итак, /dev/input/event1..
# getevent /dev/input/event1
(и в консоли тишина.. 🙂 дак надо кнопки нажимать! у меня их целых три: домик, и две громкости). На каждое нажатие и на каждое отжатие мы получаем пачку кодов. На нажатие одну, на отжатие — другую:
одно нажатие и одно отжатие кнопки Громкость Вниз Да, вот такие пачки на каждое действие!
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 && 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 > /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.$’) && && && ( torch=$(expr 255 — $torch); echo «$torch» > /sys/class/leds/torch/brightness ); rep=$( expr 1 — $rep ); done ) < /dev/null > /dev/null 2>/dev/null &
Что я делаю в скрипте:
— инит двоичной переключалки для ловли нажатия и отжатия
— после while read попадаем в основной разбор, что за строка прилетела
— читаю текущее значение фонаря
— читаю текущее значение экрана
— и дальше большое условие, сконкатенированное по && из условий:
— это наш код
— это нажатие (а не отжатие)
— экран выключен
— инверсия значения фонаря
и боевая нагрузка:
— запись нового значения фонаря (если был выключен — включает и наоборот)
— инверсия значения переключалки нажатия-отжатия.
Домашнее задание от username11 я так пока и не выполнил((, а оно вот:
1) выяснить, кто хочет ввода-вывода и устранить.
2) убрать лишние круглые скобки. каждые скобки, это лишний шелл запущенный каскадом.

Выводы.
Такскера тут вообще нет, как вы видите. Справившись с половиной этого дела, отсутствие таскера было уже делом принцпа)) зачем? когда всё «шелльно» и легко. А огромная дурильня-таскер испортит всю красоту. Да и для чего? Мигнуть фонариком?
Таскер по идее, как Начальник неоднократно писал, должен вызываться через am broadcast в «теле» боевой части.
Ответственность сторон.
Возможно, это не то, чего ждали массы)) но в любом случае, что-то почерпнуть полезное можно.
Любые советы, правки, возможные будущие _Приложения_ к этому сообщению, снятие костылинга, решения домашнего задания — решительно принимаются!

Что бы оптимизировать систему Android можно использовать твики, которые используются в build.prop. Файл build.prop можно найти в папке system, для того что бы попасть в эту папку нужно иметь Root-права и файл менеджер, который позволит зайти в эту системную папку.
Примерами таких файл менеджеров являются:

1. Root Explorer
2. Es Explorer
3. Cm File Manager

Лучше всего просто копировать этот файл на компьютер, а оттуда начать редактирование с помощью простых текстовых редакторов, например, Notepad ++. Это позволит избежать повторений строк, что может привести к потери работоспособности телефона или планшета. Добавлять строки лучше всего в конце файла.
Сейчас, я покажу вам все строки которые можно добавлять в наш файл и что они означают. Начнем:
Команда для закрепления лаунчера в памяти:
ro.HOME_APP_ADJ=1
Команда для увеличения качества картинки до 100%:
ro.media.enc.jpeg.quality=100
Команда для увеличения размера HeapSize, цифра зависит от мощности вашего телефона (можно выбирать в меню Для разработчика в Android 4.0 — 4.2):
dalvik.vm.heapsize=48m
Команда для акселерации видеочипа для прорисовки системы:
debug.sf.hw=1
Команда для уменьшения «лагов» при наборе номера:
ro.telephony.call_ring.delay=0
Команда для улучшения отзывчивости экрана:
windowsmgr.max_events_per_sec=150
Команды для экономии батареи:
wifi.supplicant_scan_interval=180
pm.sleep_mode=1
ro.ril.disable.power.collapse=0
Команда для того что бы убрать иконку отладки Android:
persist.adb.notify=0
Команда для акселерации реакции на прикосновения:
debug.performance.tuning=1
video.accelerate.hw=1
Команда для улучшения качества видеозаписи:
ro.media.dec.jpeg.memcap=8000000
ro.media.enc.hprof.vid.bps=8000000
Команда для улучшения скорости сети:
net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
Команда для исправление некоторых ошибок в приложениях: