Full support was provided by the respected
username11 where I sometimes just pressed buttons, following a set of his wise advice.
This example is offtopic! : D because the tasker does not participate in it. Totally. Only shell, only hardcore. An example of a working way))
Since this is just an example, everyone can drag it into many pieces and use the necessary parts in conjunction with their needs.
In general, there will be a lot of text, because I am a talker ..
Let's get down to business. Here is the resulting example, and immediately write what it does, and then parse:
(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>/ dev / null 2>/ dev / null &
So, this line (this is ONE line) launched in the terminal, or through the Tasker Task "Run script" runs into memory (and hangs there! The terminal can be closed) and does the following: It
keeps track of pressing the hardware button Volume Down (I think most Xperia will work, too, officially debugged under Xperia Ray)
when the screen is off, and turns on (and off) the flashlight .
Let's start with the interception buttons. As the most interesting public opportunity. We must not forget here that regular phone functions that occur when you press a button, the phone caught in parallel and work out the function. So, hang only "their" poleznyashki to pressing will not work. Why do I have simplified the process of studying the interception itself the task - I just react buttons when the screen is off. When regular lock the phone does not respond to the volume button when the screen is off.
In general, it turns out beautifully: you press the volume rocker and INSTANTLY the lamp turns on, and the screen remains off.
Debugging the script, this is actually 99.9 percent of the total time spent on it, so it is much more convenient to “chat” in wired or wireless adb. Turning debugging options through the phone terminal is tiring. (there will be a lot of debugging).
Part 1. Interception. Theory. So,
intercept . Spy on pressing the buttons, we will be the program (console text program) "GetEvent",
getevent . You can simply type (with root rights) in the terminal the name of the command and bewitched to look at the running lines))
#
getevent The output will begin to pour like this:
/ 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
in this case, events come from ALL phone devices, we need to figure out where our hardware buttons are. And to receive "interruptions" only from them, that it would be easier to process the arriving codes, and, of course, to "wake up" once more from any-each position sensor (for example) - we do not need the battery to quickly stop. (Especially, if the result of waking up then rests on the "fat" tasker).
When starting the command
geteventat the very beginning it gives a list of all available devices and then it begins to pour in lines of events. After starting, you can quickly press Ctrl-C so that the list of devices does not leave the screen. Or you can use the '-S' command key, and the command will show all valid events and end:
#
getevent -S output of the command in my case:
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
In this case, we are interested in the hardware buttons; it was experimentally found out that this device
pm8058-keypad, i.e. device path '/ dev / input / event1'. Behind this, we study the components of event providers. (and there is both a compass, and separately a power button, and a touch screen ..).
Now you can narrow the request to the system to the target. The fact is that on different devices these eventN are all different. In what order they are programmed by the manufacturer, so they are shown. (I mean, it’s not possible to copy the lines here, I’ll have to look for it myself for my phone).
So / dev / input / event1 ..
#
getevent / dev / input / event1 (and in the console silence .. :) duck buttons must be pressed! I have three of them: a house, and two volumes). For each press and for each release, we get a pack of codes. To press one, to release - another:
one press and one release of the Volume Down button
Yes, these are the packs oneveryact!
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
So the system (and we pry for the real codes that the system handles) distinguishes between pressing, pressing, and also __ pressing if there are any. That is, if you catch the "Long Volume Down" - then this is all handles, you first detect the pressure yourself, and what was the pause before release, well, before holding, yes. And only then cause your action. I haven’t reached my hands yet, but there is such a key '-t' - to show the time stamps of each flown code.
Having pushed all my three buttons)) I came to the conclusion that
sufficiency in my particular casecatching the code '0004 0004 00000004', although it happens in the press and in the release, but we will catch and take this into account.
username11 writes that the first action line serves the real action code (clicks, messing around the sensor, some other sensor), and the rest is the "echo of the system" for the first action - some, as I understand it, generating already "soft" additional codes for other system traps. What would happen in another desired process also triggered by the action. In addition: by
my Logically, bundle codes of zeros are the completion of the "description" of the code. That is, each zero ('0000 0000 00000000') is the end of the logical "string" of the event. In any case, this is a lire., You can’t sew it down, but you’ll have to catch codes))
So, I chose to catch the Volume Down button with just one line of code '0004 0004 00000004', which is unique within the pm8058-keypad (/ dev / input / event1) device.
Next comes the team
readin the mix with the team
while, in this form:
formalized:
"data entry | while read var1; do [our line-by-line processing]; done" analysis: data inputin this case, it is our data provider, "getevent / dev / input / event1"
vertical stickthis is redirection of console output (what we see as lines appearing after the getevent command) to another command for processing further. (yes, I write for those boots like me)).
while reada set of commands that do the following:
while("bye") provides us with an infinite loop of reading the lines "from under" the getevent, and
read("read") each line of the form '0004 0004 0000001c' pushes through the variables of the shell, whose names are indicated after the word '
read'.
For example. The command "enter_data | while read dev code" the first "word" BEFORE THE DIVIDER (we have this space) will put in a variable
dev, and the rest of the tail (until the end of the line) in the variable
code. (We will then call $ dev and $ code in the shell in the shell values). And they will be equal to dev = '0004', code = '0004 0000001c'. And if we say three variables: "input_data | while read dev code1 code2", then our example, given to the input of the command, it spreads like this: dev = '0004', code1 = '0004', code2 = '0000001c'. Truth be?
I myself came to the local conclusion that
to meIt's easier to catch the ALL string ('0004 0004 00000004') in one variable, that is, I have it 'while read code'. And one variable $ code is already compared to the desired value.
All that follows the semicolon (semicolon, so to speak) after the command
read, this is the command for processing the result of "pushing" _each_ lines with codes arriving from
getevent.
Local output: That is, we ordered interrupts from the event1 device, hardware buttons, and everything, everything is "hanging" and inactive. The system is sleeping. Pressing the button (any) awakens the system (it works itself) and sends it to
getevent a stack of lines with the event that occurred. We scatter the resulting lines with
while read on the components and leave for further processing
each lines separately, comparing, whether this is ours, the required line, or not. And then we launch the combat load, perform some kind of action (turn on the flashlight, like me, or call the tasker task right away). (Basically, here is the whole solution). But, about it all in due time, more low, for now the whole series of ambushes waited for me:
Part 2. Workarounds. The first encounter with practice. Immediately after I rushed into battle, nothing worked for me. Simple verification team:
#
getevent / dev / input / event1 | while read code; do echo $ code; done .. did not show anything!
(the meaning of the command: we get from
geteventarray of strings using
while read variabledragging the array into strings and just in each cycle with the command
echowe derive
valuevariable (the bucks icon in front of the name), in this case, the entire line in one gulp, it is in a single variable
code).
Miraculously, I discovered that it shows the result, if you press the button many times. It turned out the following. On the "stick" is buffering! That is, redirecting data flow from under
geteventit works, of course, but the system buffers the data - it collects them in a heap and gives it away only after accumulating a certain amount, apparently about 4k. AND
username11 gives the following advice: take the bizybox command
script and frame it with the above line. As I understand,
script tells the system to know the "output device" as (conditionally) tty, not a block device. And pushing every byte through the "stick" immediately, without waiting for the accumulation of the full buffer.
That is, the following verification team has worked well:
#
script -q -c 'getevent / dev / input / event1' / dev / null | while read code1 code2 code3; do echo "code1: $ code1, code2: $ code2, code3: $ code3"; done (Yes,
conclusionteams
scripthad to remember to lower in
toilet/ dev / null)
(this example displays, when pressing buttons, bundles of strings of the form: "code1: 0004, code2: 0004, code3: 00000004" is no longer slouching too deeply, IMMEDIATELY after pressing, without putting anything in the drawer).
However, it is time to parse the results of clicks and screenings that are needed, it was absolutely fresh for me)) This resulted, after many days (unhurried) study of the Internet of man-faks-havtushek, into the following:
#
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 (the line is already "wow", yes. So, what I do is: tear each line into three parts, code1-3, and then compare successively the value
code1from 0004, and so on, and as a result I bring out the result ONLY to the pressure I need (the && sign indicates that the command
echowill be executed only if the whole comparison is performed in square brackets)).
DOES NOT WORK! ((
I again to the authorities. (moreover, as I later found out in the process of sorting through various options, the first two comparisons work! plugging in the third). For a long time I pooped until I was instructed on the command of cognitive data output:
# script -q -c 'getevent / dev / input / event1' / dev / null |
od -cb (it displays the byte values ​​of the text in different formats, well, like line 12345 will look like 31 32 33 34 35). And right after it was discovered that at the end, behind the last 00000004, apart from the regular Linux sign, the line break 0D was still worried (completely DOSovsky) 0A. And of course
while readlawfully shoves him into the last variable, in my case in
code3. And we have a comparison before the sign, if at the end of the line the left tail, the comparison does not work.
The chief offered me (already on the verge of my understanding of the Linux com line) options for this next round, I stopped at this:
here are the first checks]
&& echo "$ code3" | grep -q '^ 00000004. $' && echo "code1: $ code1 (and at the end went output via
echo )
Earned!
(as I understood, search for a string through
grepwith the key '-q' gives the value true / false in our
dupea cascade of double ampersands && for comparing the comparison logic. Circumflex and buck with a point are already OUT the limits of my understanding, but I believe that this is a search from the beginning of the line and the omission of an arbitrary end, the one that stuck out of the signs 0D and 0A).
Thus, a complete search for my sequence (recall, '0004 0004 000000004') WITHOUT a combat load, began to look like this:
(
codeI again, pampered with splitting the line into pieces, made a heap, still I still have one full-line 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 (and threw out the square brackets, still the main result gives
grep)
Here, the first result. In the terminal, one line is displayed for pressing the button I need, and one for pressing. Nothing is displayed on the other buttons. You can screw on / off the lamp!
Part 3. Flashlight. Long road in the dunes. Well, here I am still decently lost my head, the Chief suggested how easier it is to make a "switch" on the command line, from 0 to 1 and back, the _one_ command. (as I asked: "how to make xor ax, 1"))) It turned out:
a = $ (expr 1 - $ a).
I knew in advance the "variable" of the flashlight, for me (I think, at all xperias as well) it is / sys / class / leds / torch / brightness. A value of 0 does not shine, 255 - shines. (and all intermediate from 3 to 255 work, but yes, the flashlight is beautifully smoothly turned on, and as I wrote a binary on C for the android right on the phone, this is a separate tale)).
I also needed to find whether the screen is currently on or not, because getting control at the point
echo code: $ codeI resolutely (so far) did not imagine what was happening with the screen. And if it is on, this is a regular system volume change, and at this moment it is not necessary to turn on the flashlight.
Climbing, I found. Beside. / sys / class / leds / lcd-backlight / brightness too, 0-255, or something. At least the turned off screen is "0", turned on - NOT zero.
Iiii .. I gash. The full script you saw at the beginning. Oh, no, that's not all)))
Part 4. The last ambush Eventually
username11 taught me to frame everything with brackets, behind which to write a single ampersand, &. A sign that the script should remain hanging in the memory of the system, remain a resident. And give control to the command line. And then there was the last ambush - it is worth filling the script with a resident, he stopped working! So it works, but the resident does not! As it turned out after the command
ps (a list of all processes), that my script is in memory is hanging, but it wants I / O, (I didn’t find what the "wants" command is), so the system slows it down and doesn’t give it anything.
As a result, I had to write at the end to solve this problem (another, last, crutch)):
# (all my strip)
</ dev / null>/ dev / null 2>/ dev / null & (that is, all the eager to communicate before the floor in the toilet).
Now it all worked.
Repeat))
#
(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>/ dev / null 2>/ dev / null & What I do in the script:
- binary switch initial for catching and unlocking
- after while read we fall into the main analysis, that for the line arrived
- I read the current value of the lamp
- I read the current value of the screen
- and further a large condition, concatenated by && from the conditions:
- this is our code
- this is a click (and not release)
- the screen is off
- inversion value lantern
and combat load:
- write a new value of the lamp (if it was turned off - turns on and vice versa)
- inversion of the push-release switch value.
Homework from
username11 I haven't done it yet ((, but here it is:
1) find out who wants I / O and eliminate.
2) remove unnecessary parentheses. every brackets is an extra shell running in cascade.
Findings. There is no takker here, as you can see. Having coped with half of this case, the absence of a tasker was already a matter of a prince)) why? when everything is "shell" and easy. A huge durilnya-tasker spoil all the beauty. And for what? Blink flashlight?
Tasker, in theory, as the Chief wrote repeatedly, should be called through
am broadcastin the "body" of the warhead.
Responsibility of the parties. Perhaps this is not what the masses have been waiting for)) but in any case, something useful can be learned.
Any tips, edits, possible future _Applications_ to this post, removal of the crumbler, homework decisions are being decidedly accepted!