Is anyone aware of a program that would allow me to automate a series of "touch" events on Android to test an app I have written. Something controlled by ADB I would assume.
For example;
Touch @ X axis = 500 Y axis = 200;
Wait 0.5 seconds;
Release touch;
Wait 1.9 seconds;
Touch @ X axis = 300 Y axis = 400;
Wait 0.5 seconds;
Release touch;
etc.
Related
Initially i downloaded Wiimote off the market and found that i could not connect my controller without the hassle of a passkey or pin. Well they offer 0000 or 1234 as options for the standard pass and those did not work. After a few minutes i downloaded a second one to see if it had an option to bypass it and sure enough it did. It's called "SimpleWiiController" and it's FREEEEEE! So i installed that and turned on my bluetooth. When you open the application it gives and option to enable it, select input, and connect. Well ENABLE, Select input to remote, and as you ENABLE connect hold 1&2 on remote or red button in battery door. Once connected you will see success or you will see test input received signals for each button you press. Needless to say i was excited because the virtual keyboard annoys me. So i started snesoid and started playing mario.
For best results:
-ENABLE "USE INPUT METHOD" in snesoid. Close to bottom of screen.
-disable virtual keyboard (enabling fullscreen)
-map keys (key mapping)
-turn remote in desired direction
My Setup:
- Up = up
- Down = down
- left = left
- right = right
- select = minus
- Start = plus
- A = 2
- X (essentially B button on snes) = 1 (speedrun setup just like controller)
- B (spin) = A
If i had a camera i'd post a youtube video or something. but i do not . If any help is needed using these two pairings i'd be glad to help. But as far as NES and PSX i have no idea.
im waiting until we can pair out PS3 controllers to our Nexus Ones via bluetooth
Yea i'd try my roommates but if i messed anything up in it i'd be out $50.
The problem hangs boot! Help!
Install android 2.2 for instructions.
Androida stitch boot and reboot the phone vibrates 2 times, there is a white screen with white letters and black penguin after 1-2 seconds stops and load weight. Tried everything possible nbh, who collected himself in atools. In general the white screen with white penguin only works on kernel 2.6.32 with the following parameters polaris-240x320-Froyo-1-2.6.32.
SCREEN: hxtp://i56.tinypic.com/1y3ebt.jpg (hxtp ->http)
Black screen with the penguin got the normal parameters of polaris-240x320-Froyo-3-2.6.32 but the download just hangs like a white screen. At the core of 2.6.25 for all pereprobovanyh me Parameter only color bars. What's the problem? Who knows how to solve it?
Decided to hold a small exeperimental. I had an old build android-1.5-2009-07-09, which run in the past from Presov to small exeperimental. I had an old build android-1.5-2009-07-09, which run in the past out of Haret normal, with a black boot. This assembly contains:
1) with parameters default.tht
(# Alloctest 0x2000
set RAMSIZE 0x08000000
set MTYPE 1723
set KERNEL zImage
set initrd initrd.gz
#
# The following kernel parameters are useful
# Ppp.username - The username used to connect to the network when dialing
# Ppp.password - The password used to connect to the network when dialing
# Ppp.apn - Set apn of your provider
# Ppp.nostart - Set ppp.nostart = 1 to disable starting the ppp connection on boot
# Msm_sdcc.msmsdcc_fmax - The maximum frequency (in Hz) used by the SD controller
# Pm.sleep_mode - The mode used when the phone is off
# 0 = Power Collapse Suspend, 1 = Power Collapse, 2 = Apps Sleep,
# 3 = Slow Clock and Wait for Interrupt 4 = Wait for Interrupt
# Default is 1, use one for best power savings
# Board-htcpolaris.panel_type - Panel type used to power the panel off and on
# 0 = Don't power off the panel (Default)
# 1 2 = Sony = Topoly 3 = Topoly (probably just the same as 2)
# Lcd.density - Defaults to 160, 128, shows more on screen
#
set cmdline "board-htcpolaris.panel_type = 0 ppp.apn = wxw.vodafone.net.nz ppp.username = none ppp.password = none pm.sleep_mode = 1 mddi.width = 324 mddi.height = 432 no_console_suspend board-htcpolaris -battery.battery_capacity = 1350 mddi_client_vogue.vsync = 0 "
bottles)
2) haret.ehe,
3) initrd.gz,
4) resources.zip,
5) system.img,
6) zImage
Try to start the assembly with diabetes. In the beginning is all fine, black boot, but then hangs up and says: Varning ---
sisten.img not found on the CD.
It's weird, because sisten.img lies on CD.
Poshamaniv to build its atools Fail default with the following parameters:
set RAMSIZE 0x07300000
set MTYPE 1723
set KERNEL zImage
set initrd initrd.lzma
set cmdline "no_console_suspend board-htcpolaris-battery.battery_capacity = 1350 ppp.nostart = 0 hw3d.version = 1 mddi.width = 324 mddi.height = 432 clock-7x00.mddi = 0xa51 board-htcpolaris.panel_type = a board-htcpolaris . no_boot_vibration = 1 mddi_client_vogue.vsync = 0 sys_partition = / sdcard / andboot / system.img data_partition = / sdcard / andboot / data.img fstype = 2 "
boot
Try to run the assembly Froyo [2.2.2] My Modified Fresh Froyo Release 20-2-2011 with these parameters is out of Haret. The loader is still a white background. That's what vydalood Haret. This assembly contains: hxtp://i53.tinypic.com/20z9y8k.jpg (hxtp ->http)
Those who have any ideas? Why download the old version, so good with black boot and Froyo not?
I climbed a lot of forums and for some reason or where there is no answer to this question, although people with the same problem there. I have a broken display and I replaced it with a new one, after that there was such key problems.
On one of the branches of the forum says that they say it is because the display problem and needed origenalny. But after analyzing all available information, I think that probably in problemma HARD-SPL 2.20Olix!!! This SPL does not support the display non-origenalnogo.
I think that this key problems to be solved, because sooner or later and your display may break mashines and I think you do not want to buy origenalny display for $ 50-100 for this old devaysa.
By this I beg you, help me to find someone who could create a new HARD-SPL for HTC Polaris. Maybe someone knows and understands the programming and be able to make himself SPL. Please respond to all!
I'm trying to use a gamepad with my Galaxy S3. I've tried both a wireless Xbox 360 controller, and a wired original Xbox controller. They both have the same problem, which is the trigger axes are too noisy, and it is impossible to manually map axes to functions in games that require it, like Dead Trigger or SG: Shadowgun. I try to map a button? Nope, instantly mapped to right trigger! Try to map the left stick to the move function? Nope, also instantly mapped to the right trigger! Holding down the right trigger, or the left trigger, nothing seems to fix it. This happens on BOTH controllers, on BOTH games. So this is clearly a problem with android; it doesn't map deadzones.
So far, I've tried Pokejoy's USB/BT Joy Gold IME, GameKeyboard, Tincore Keymapper, and a couple other gamepad IME apps. None of them have given me what I want, which is to add a deadzone to the existing gamepad driver. I don't want to map the gamepad to the touchscreen to fool the game, because my games already support gamepads out of the box.
And I know for a fact it is POSSIBLE to get these controllers working, because the SuperGNES snes emulator app works great with both controllers, and maps the move function to the left stick just fine, without interference from the noisy triggers.
Any suggestions?
annnnnybody? This is really bugging me. I've seen so many videos of people using their xbox 360 controllers on their Androids, but it is impossible for me, because I can't remap the axes in the games, because they are instantly assigned to the trigger axis, because it is too noisy and has no dead zone! I need a way to force a dead zone on my gamepad!
Not to mention it is completely impossible to search for answers to my question on XDA or Google, because the assholes that made Shadowgun decided to release a sequel called "SG: Deadzone", so as soon as you search for "gamepad android deadzone", all you get are people looking to use their gamepad on that freakin game.
Well I fixed the issue myself. After some digging, it seems the axis mapping for gamepads is stored in /system/usr/keylayout/*.kl files. To figure out which file my gamepad was using, I read the logcat. It was using generic.kl. The axis mappings are at the bottom, after all the keyboard stuff.
I replaced this:
Code:
# Joystick and game controller axes.
# Axes that are not mapped will be assigned generic axis numbers by the input subsystem.
axis 0x00 X
axis 0x01 Y
axis 0x02 Z
axis 0x03 RX
axis 0x04 RY
axis 0x05 RZ
axis 0x06 THROTTLE
axis 0x07 RUDDER
axis 0x08 WHEEL
axis 0x09 GAS
axis 0x0a BRAKE
axis 0x10 HAT_X
axis 0x11 HAT_Y
with this, stolen from Vendor_045e_Product_028e.kl, which is the KL file for the Xbox 360 Wired USB controller:
Code:
# Left and right stick.
# The reported value for flat is 128 out of a range from -32767 to 32768, which is absurd.
# This confuses applications that rely on the flat value because the joystick actually
# settles in a flat range of +/- 4096 or so.
axis 0x00 X flat 4096
axis 0x01 Y flat 4096
axis 0x03 Z flat 4096
axis 0x04 RZ flat 4096
# Triggers.
axis 0x02 LTRIGGER
axis 0x05 RTRIGGER
# Hat.
axis 0x10 HAT_X
axis 0x11 HAT_Y
Even though I am using an original xbox controller and not an xbox 360 controller, the axis mappings were consistent, and this change alone fixed my issue. The default mappings in games were now useable, and I was able to remap axes without them being instantly assigned to the trigger axis.
I also learned that the "flat" value is the size of the deadzone. As the comments suggest, the default of 128 is too small, but their replacement of 4096 is, in my opinion, way too large. I settled on 1024 for my flat values, and it is a perfectly sized deadzone.
Note that I had to do this to get my wireless xbox 360 controller working too, because it was ALSO assigned to 'generic.kl'.
same problem
I also has the same problem, don't know whether use the IME can solve. trying
O MY GOD!
I have also same problems whit my OnePlus One (whit CM11s) and two Xbox360 Wired USB Controller buyed from Gamestop..... i have two of this:
https://www.gamestop.it/Xbox360/Games/20390/controller-wired-black-xbox-360
It's perfectly working and correctly assigned when i attach to my OPO using a OTG Cable... but i have try to use whit two games:
*** On Reckless Racing 3 ****
The controller working good.... but when the analog stick it's on center the car tends to skid a little to the left...... nothing serious but cause some problems
*** I have also try this to use with Little Big Adventure ***
Like upper problems but in this case the games it's unplayabe...... my character keeps making lateral movements to the left
Usually i used this same Controllers on windows 7.... here it's present a tools to make a calibration and some games have the option to set the DeadZone center area for resolve this problems but on Android i never found a APP to obtain a similar things.
Now i have found this thread and i have some question:
When i attach my controller on my OnePlus One.... how i can know what file it's been used or it's been loaded ?!?!? I have watched in the folder and i have so much file .kl and i don't know what it's the exact .kl i need to edit or similar things.... someone can help or explain this ?
moeburn said:
Well I fixed the issue myself. After some digging, it seems the axis mapping for gamepads is stored in /system/usr/keylayout/*.kl files. To figure out which file my gamepad was using, I read the logcat. It was using generic.kl. The axis mappings are at the bottom, after all the keyboard stuff.
I replaced this:
Code:
# Joystick and game controller axes.
# Axes that are not mapped will be assigned generic axis numbers by the input subsystem.
axis 0x00 X
axis 0x01 Y
axis 0x02 Z
axis 0x03 RX
axis 0x04 RY
axis 0x05 RZ
axis 0x06 THROTTLE
axis 0x07 RUDDER
axis 0x08 WHEEL
axis 0x09 GAS
axis 0x0a BRAKE
axis 0x10 HAT_X
axis 0x11 HAT_Y
with this, stolen from Vendor_045e_Product_028e.kl, which is the KL file for the Xbox 360 Wired USB controller:
Code:
# Left and right stick.
# The reported value for flat is 128 out of a range from -32767 to 32768, which is absurd.
# This confuses applications that rely on the flat value because the joystick actually
# settles in a flat range of +/- 4096 or so.
axis 0x00 X flat 4096
axis 0x01 Y flat 4096
axis 0x03 Z flat 4096
axis 0x04 RZ flat 4096
# Triggers.
axis 0x02 LTRIGGER
axis 0x05 RTRIGGER
# Hat.
axis 0x10 HAT_X
axis 0x11 HAT_Y
Even though I am using an original xbox controller and not an xbox 360 controller, the axis mappings were consistent, and this change alone fixed my issue. The default mappings in games were now useable, and I was able to remap axes without them being instantly assigned to the trigger axis.
I also learned that the "flat" value is the size of the deadzone. As the comments suggest, the default of 128 is too small, but their replacement of 4096 is, in my opinion, way too large. I settled on 1024 for my flat values, and it is a perfectly sized deadzone.
Note that I had to do this to get my wireless xbox 360 controller working too, because it was ALSO assigned to 'generic.kl'.
Click to expand...
Click to collapse
I need to be quoted and i need you help! How i can know what's the exact KL using my device when i attach my xbox controller !?!??!
I have read the logcat using a terminal emulator and i can find nothing inside it.... you can help me ?!??!?
---------- Post added at 07:02 PM ---------- Previous post was at 06:09 PM ----------
Sorry Mod....... but i need to make another consecutive reply but i have found a solution here:
http://forum.xda-developers.com/showpost.php?p=58239101&postcount=16
If someone want at this point you can join this my 3 reply......
I'm struggling with calibration of a touchscreen on Android plataform.
It is an USB Single-Touch Touchscreen from vendor 0dfc and product 0001 as checked with dmesg:
Code:
<6>[ 4118.091541] input: USB Touchscreen 0dfc:0001 as /devices/platform/usb20_host/usb2/2-1/2-1.3/2-1.3:1.0/input/input23
I'm pushing the Vendor_0dfc_Product_0001.idc file /data/system/devices/idc/ (following the documentation from android source - IDC)
I got the touch device with all requirements for single touch events:
Code:
[email protected]:/ # getevent -il /dev/input/event3
add device 1: /dev/input/event3
bus: 0003
vendor 0dfc
product 0001
version 0202
name: "USB Touchscreen 0dfc:0001"
location: "usb-usb20_host-1.3/input0"
id: ""
version: 1.0.1
events:
KEY (0001): BTN_TOUCH
ABS (0003): ABS_X : value 540, min 0, max 32767, fuzz 0, flat 0, resolution 0
ABS_Y : value 289, min 0, max 32767, fuzz 0, flat 0, resolution 0
input props:
<none>
I also enabled the Pointer Location option from Developer options (Android settings) in order to debug this stage of calibration.
Setup 1
Code:
touch.deviceType = touchScreen
With this setup (1) all the gestures on the touchscreen take place at the up-left corner - just a few pixels left/right/up/down no matter the gesture (swipe). All the touchscreen get events. All the gestures are reversed - when swipe left the pointer goes right; when swipe up, the pointer goes down.
Setup 2
Code:
touch.deviceType = pointer
touch.gestureMode = pointer
With this setup (2), as expected, it shows a pointer, placed at the position from the last pointer device left (mouse). All the gestures on the touchscreen (no matter the swipe size) keep beaving like setup 1 - move only a few pixels with each swipe event, and with reversed axis.
Setup 3
Code:
touch.deviceType = pointer
touch.gestureMode = spots
With this setup (3) the result is the same as setup 2. I just did that to prove that the IDC file is being interpreted correctly.
At this stage, as you can check by now, I have a working IDC file (setup 1) requiring calibration for this touch device.
I tried a lot of combinations from other IDC files (internet samples) and from android source - IDC - ANY OTHER PROPERTY TOOK EFFECT (NOT A SINGLE ONE) - raw.*, output.*, touch.size.*
Does anyone knows how to calibrate properly a touch screen in Android that could guide me in this process?
Thank you
In ye olde day we had u-boot as the last bit before loading an Android image.
If you had access to the UART on the SoC you could hook a terminal and hit any key to pause the loading.
Then you had a simple command line interface with access to low-level diagnostics and selection of boot options.
Nowadays we have abl (formerly aboot).
There doesn't seem to be a lot of source code floating around for this.
If you have Qualcomm's SecureBoot (or other equivalent) you can't modify abl easily.
Recently I did a deep dive into the abl for the Onyx Poke3 ereader, which is fortunately not SecureBoot.
Between disassembling and patching I got a fairly good idea of what it's doing.
While there may not be any direct applicability to other models there might be some hints here.
The first thing is that the key detection is not built on ASCII, but VT-100 control/escape sequences.
Only five keys are directly noticed.
Code:
Keyboard Hex Chars Value
--------------------- -------------- ------- -----
Arrow up 0x1b 0x5b 0x41 Esc [ A 0x01
Arrow down 0x1b 0x5b 0x42 Esc [ B 0x02
Arrow right 0x1b 0x5b 0x43 Esc [ C 0x03
Arrow left 0x1b 0x5b 0x44 Esc [ D 0x04
Backspace (as VT-100) 0x7f 0x08
Backspace (as ASCII) 0x08 nope
The values are seen in the terminal under "KeyPress".
In fact three of the KeyPresses are ignored and two are synonyms.
Either Arrow down or Backspace (as 0x7f) are the only things recognized.
If either is hit after the abl boots, the abl will pause for up to 10 seconds.
There is a strange key read function that gets a key but will not return for 100 mS even if a character is available.
If 100 Arrow/Backspace (+1 for the initial "stopper") are received the abl will boot to recovery.
If 50 to 99 Arrow/Backspace (+1 for the inital "stopper") are received the abl will boot to EDL mode.
You're probably saying, "Well if I have open access to the UART, I can just hit the EDL mode test points."
Yup, in many cases.
Now comes the wrinkle with this key stuff.
If you reboot your device and just hit and hold the Arrow/Backspace key down there's a buffer that will fill up and you will get >100 and it will go to recovery.
If you try to get to EDL manually by hitting a key 50 times you will fail if there is any gap of 1/10 of a second.
Plus, it only starts counting at a particular point.
So I wrote a little utility that listens to the log output, waits for the right spot and injects 60 or 110 Backspaces (0x7f).
Code:
C:\>abltest /r com3
Listening...
Starting
Jabbering...
Detecting...
Going to recovery!
Done
C:\>abltest com3
Listening...
Starting
Jabbering...
Detecting...
Going to EDL mode!
Done
FInally, there is separate detection for the power button being held.
The loading will pause for this then detect five presses of the power button to go to recovery.
This device has no volume/other buttons, so these are the only possibilities.
Has anybody seen this style? Or any other style?
Renate said:
In ye olde day we had u-boot as the last bit before loading an Android image.
If you had access to the UART on the SoC you could hook a terminal and hit any key to pause the loading.
Then you had a simple command line interface with access to low-level diagnostics and selection of boot options.
Nowadays we have abl (formerly aboot).
There doesn't seem to be a lot of source code floating around for this.
If you have Qualcomm's SecureBoot (or other equivalent) you can't modify abl easily.
Recently I did a deep dive into the abl for the Onyx Poke3 ereader, which is fortunately not SecureBoot.
Between disassembling and patching I got a fairly good idea of what it's doing.
While there may not be any direct applicability to other models there might be some hints here.
The first thing is that the key detection is not built on ASCII, but VT-100 control/escape sequences.
Only five keys are directly noticed.
Code:
Keyboard Hex Chars Value
--------------------- -------------- ------- -----
Arrow up 0x1b 0x5b 0x41 Esc [ A 0x01
Arrow down 0x1b 0x5b 0x42 Esc [ B 0x02
Arrow right 0x1b 0x5b 0x43 Esc [ C 0x03
Arrow left 0x1b 0x5b 0x44 Esc [ D 0x04
Backspace (as VT-100) 0x7f 0x08
Backspace (as ASCII) 0x08 nope
The values are seen in the terminal under "KeyPress".
In fact three of the KeyPresses are ignored and two are synonyms.
Either Arrow down or Backspace (as 0x7f) are the only things recognized.
If either is hit after the abl boots, the abl will pause for up to 10 seconds.
There is a strange key read function that gets a key but will not return for 100 mS even if a character is available.
If 100 Arrow/Backspace (+1 for the initial "stopper") are received the abl will boot to recovery.
If 50 to 99 Arrow/Backspace (+1 for the inital "stopper") are received the abl will boot to EDL mode.
You're probably saying, "Well if I have open access to the UART, I can just hit the EDL mode test points."
Yup, in many cases.
Now comes the wrinkle with this key stuff.
If you reboot your device and just hit and hold the Arrow/Backspace key down there's a buffer that will fill up and you will get >100 and it will go to recovery.
If you try to get to EDL manually by hitting a key 50 times you will fail if there is any gap of 1/10 of a second.
Plus, it only starts counting at a particular point.
So I wrote a little utility that listens to the log output, waits for the right spot and injects 60 or 110 Backspaces (0x7f).
Code:
C:\>abltest /r com3
Listening...
Starting
Jabbering...
Detecting...
Going to recovery!
Done
C:\>abltest com3
Listening...
Starting
Jabbering...
Detecting...
Going to EDL mode!
Done
FInally, there is separate detection for the power button being held.
The loading will pause for this then detect five presses of the power button to go to recovery.
This device has no volume/other buttons, so these are the only possibilities.
Has anybody seen this style? Or any other style?
Click to expand...
Click to collapse
the program is awesome! if the motherboard logic level is 3v3, you can use a respberry pi pico to set a pin to high and low (button) in a loop once the log output on uart bus is detected
$cronos_ said:
the program is awesome! if the motherboard logic level is 3v3, you can use a respberry pi pico to set a pin to high and low (button) in a loop once the log output on uart bus is detected
Click to expand...
Click to collapse
Most processors today use I/O voltages of less than 3.3 V. 1.8V is pretty typical.
What I was saying above was based on the abl on my device. I'm pretty sure there is a lot of variety there.
You'd have to hook up a USB UART to your own device to see how relevent that is.
You can use a RPi Pico, RPi Zero, Arduino Leonardo or another Android as a USB peripheral to control an Android.
For instance, with a broken touch screen it would be very difficult with a mouse to activate a swipe pattern since a mouse is by definition relative. A digitizer could work if you knew the scaling.
Here's something I did with one Android to login swipe another Android:
https://forum.xda-developers.com/t/accessing-my-phone-with-a-dead-screen.4542763/post-88013171
Renate said:
Most processors today use I/O voltages of less than 3.3 V. 1.8V is pretty typical.
What I was saying above was based on the abl on my device. I'm pretty sure there is a lot of variety there.
You'd have to hook up a USB UART to your own device to see how relevent that is.
You can use a RPi Pico, RPi Zero, Arduino Leonardo or another Android as a USB peripheral to control an Android.
For instance, with a broken touch screen it would be very difficult with a mouse to activate a swipe pattern since a mouse is by definition relative. A digitizer could work if you knew the scaling.
Here's something I did with one Android to login swipe another Android:
https://forum.xda-developers.com/t/accessing-my-phone-with-a-dead-screen.4542763/post-88013171
Click to expand...
Click to collapse
oh ok, so i would need a logic level shifter?
$cronos_ said:
oh ok, so i would need a logic level shifter?
Click to expand...
Click to collapse
You'd need either a level shifter or a USB UART that works at that voltage.
Here's one USB UART that has selectable logic level: https://www.amazon.com/DSD-TECH-SH-U09C5-Converter-Support/dp/B07WX2DSVB
And a photo of one level shifter I threw together for 1.8V to 3.3V to use with a 3.3V USB UART.
Renate said:
You'd need either a level shifter or a USB UART that works at that voltage.
Here's one USB UART that has selectable logic level: https://www.amazon.com/DSD-TECH-SH-U09C5-Converter-Support/dp/B07WX2DSVB
And a photo of one level shifter I threw together for 1.8V to 3.3V to use with a 3.3V USB UART.
Click to expand...
Click to collapse
Yooo i have the dsd tech one