I'm trying to redirect the getevent command in Android to a file on the device.
I tried. getevent > /path/to/file, but that didn't work. When I CTRL+C'd, the file was empty.
After further investigation, I discovered that it works if I use getevent's -c flag, which tells the process to terminate after a certain number of events are received. This leads me to believe that the problem is related to the fact that I'm killing the process. When I use tee instead of a >, I can see that the output does not show in stdout until the process finishes gracefully.
The problem of course is that getevent never terminates, and I can't use the -c flag because I won't know beforehand how many events are going to be received.
How can I redirect the getevent to a file in such a way that it is there even when the process is killed?
It's fine if the solution requires the device to be rooted.
Edit: I've discovered through further investigation, that if I ensure that at least 25 events have been sent, it writes to the file. But if I ensure 30 events have been sent, only those 25 events will be written to the file. This confirmed my suspicion, that it's a buffer issue.
In the end, I had to write a script calling getevent -c 1 in a loop.
Suppose we have an Android device, and on that device are 1+ apps capable of creating their own floating windows (e.g., hold the SYSTEM_ALERT_WINDOW permission). Plus, of course, there can be other windows that are not necessarily independently floating (Spinner, Dialog, etc. all create their own windows via WindowManager, just for display over an existing activity).
Given that I know from developer tools a pixel coordinate inside a window, how can I determine the process or app that created the window containing that pixel? IOW, how can I find out who to blame for the existence of a given window?
I thought that perhaps adb shell dumpsys window would have that information, but if it does, I'm not seeing it.
Note that I am happy to settle for a solution involving development tools. I would hope that determining this information at runtime would be difficult or impossible without special privileges.
Running this command adb shell dumpsys input gives me the following output:
[...bunch of stuff...]
6: name='Window{5e9310c u0 com.example.overlayservice/com.example.overlayservice.MainActivity}',
displayId=0, paused=false, hasFocus=true, hasWallpaper=false,
visible=true, canReceiveKeys=true, flags=0x81810120, type=0x00000001, layer=21010,
frame=[0,0][1440,2560], scale=1.000000, touchableRegion=[0,0][1440,2560],
inputFeatures=0x00000000, ownerPid=4086, ownerUid=10083, dispatchingTimeout=5000.000ms
[...bunch more stuff..]
Since I am backing into this, I know that the app is "Overlay Service" that simply shows a system window. The "frame" information would bound the pixel and "ownerUid" would give more info about the owner. (I am thinking that this command is more than a disguised dumpsys window command that is not working for you.)
Although it is not exactly a "this pixel to this app" mapping, assuming that you are seeing the same information on your device, this technique can help to trim down the targets.
Alternate
The following is a more direct approach if you have access to the device or are on an emulator.
According to the documentation for dumpsys under the category of Input Dispatcher State,
Input dispatcher state
The InputDispatcher is responsible for sending input events to applications. As shown in the sample output below, its state dump shows information about which window is being touched, the state of the input queue, whether an ANR is in progress, and so on.
Reading further:
After touching the touch screen and running dumpsys at the same time, the TouchStates line correctly identifies the window that you are touching.
Specifically, the string "TouchStates: ..." will identify the window that we are touching at the time we run dumpsys.
So, we should be able to run dumpsys input and look for the string TouchStates and print the following few lines to identify the window. Here is my Windows command line:
timeout 3 & adb shell dumpsys input | grep TouchStates -A 5
And here is the output that identifies Window{e3cd95d u0 com.example.overlayservice/com.example.overlayservice.MainActivity}' as the window being touched.
TouchStatesByDisplay:
0: down=true, split=true, deviceId=0, source=0x00001002
Windows:
0: name='Window{e3cd95d u0 com.example.overlayservice/com.example.overlayservice.MainActivity}', pointerIds=0x80000000, targetFlags=0x107
Windows:
0: name='Window{ef28ce5 u0 NavigationBar}', displayId=0, paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x21840068
, type=0x000007e3, layer=231000, frame=[0,1794][1080,1920], scale=1.000000, touchableRegion=[0,1794][1080,1920], inputFeatures=0x00000000, ownerPid=1632, ownerUid=
10027, dispatchingTimeout=5000.000ms
If no window is being touched, then you will see TouchStates: <no displays touched>.
How about this option: adb shell dumpsys window windows visible-apps?
It prints the list of visible windows with the following fields for each one:
mOwnerUid, package, mFrame, mShownPosition, mIsFloatingLayer, etc.
From adb shell dumpsys window:
Window #3 Window{41b85d98 u10 com.example.app}:
mDisplayId=0 mSession=Session{41bc2e38 10536:u10a10030} mClient=android.os.BinderProxy#41b064c0
mOwnerUid=1010030 mShowToOwnerOnly=true package=com.example.app appop=SYSTEM_ALERT_WINDOW
mAttrs=WM.LayoutParams{(0,0)(395x110) gr=#55 sim=#20 ty=2003 fl=#20008 fmt=-3}
Requested w=395 h=110 mLayoutSeq=1200
mHasSurface=true mShownFrame=[885.0,642.0][1280.0,752.0] isReadyForDisplay()=true
WindowStateAnimator{41d4d2a8 }:
Surface: shown=true layer=91000 alpha=1.0 rect=(885.0,642.0) 395.0 x 110.0
It looks to me that mShownFrame variable holds the data you need to determine if a pixel is contained by a window.
I would hope that determining this information at runtime would be
difficult or impossible without special privileges
The most recent Android release is heavily locked down to prevent malware spoofing "trusted" applications such as online banking applications.
Even knowing what other processes are running via the /proc filesystem is now restricted, so it seems unlikely you will be able to know pixel ownership without rooting the platform (that would be a back-door to get the same information as /proc would expose about the current foreground process).
I have searched about it, But unable to find any good documentation on it.
Adding android.intent.category.MONKEY to activity means that
This activity may be exercised by the monkey or other automated test
tools.
Reference
How to use it?
The Monkey is a program that runs on your emulator or device and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events. You can use the Monkey to stress-test applications that you are developing, in a random yet repeatable manner. check here.
The simplest way to use the monkey is with the following command, which launches your application and sends 500 pseudo-random events to it.
adb shell monkey -v -p your.package.name 500
It means that the activity should be launched by the automated testing tool Monkey.
I am looking for a way to use ADB to dismiss the keyguard in order to automate some tasks.
I would like to start an ACTIVITY (perhaps to call the public method disableKeyguard in android.app.KeyguardManager.KeyguardLock), because I assume that it will work on all (or most) Android devices, but I am unsure of the syntax.
I do not wish to use MonkeyRunner, because it is not present (or perhaps, callable) on all devices. I also cannot send a MENU keycode (adb shell input keycode 82), because this does not dismiss the keyguard on all devices.
Currently I am sending events (low-level touch events), but this needs to be customized for each device, so it is a time consuming task.
Does anyone have a suggestion?
The "Activity Testing" article has a section called Unlocking the emulator or device that addresses this situation.
In short, there isn't a way to do it directly with adb but using disableKeyguard() isn't complicated (see the three lines of example code in the article linked to above). You could easily put together a little app that does nothing but disable the keyguard. It would then just be a matter of
adb install <apk>
adb shell am start <package>/.<activity>
# Whatever you need to automate
adb uninstall <package>
(Where <apk>, <package>, and <activity> all refer to the tiny app that just disables the keyguard.)
I have this snippet of shell script:
am start -n com.android.gallery3d/com.android.gallery3d.app.MovieActivity -d /sdcard/movie.mp4
sleep 5
input keyevent 4
This script basically reads as follow:
1. Open the gallery application to start movie.mp4
2. Sleep 5 seconds
3. Press back key
When I run this script through adb shell, things work out as expected which is the video plays only for the first 5 seconds and then the back key is pressed which essentially quits the gallery app.
However, when I run this though runtime.exec()
The gallery does start, but then nothing else happen. It seems like the system prevents me from running the script when the application is in the background.
Anybody happens to know any work around? Or is there any way to use INTENT to achieve the same result?
Thanks in advance
A script run by an application runs as the application userid, which does not have the extra
debug privileges that the adb shell (running as shell or even root) does.
For security reasons, applications are not supposed to be able to feed fake keystrokes to other applications and especially not to the system itself.
Perhaps instead of backing out of the gallery, you should try to start something else with an Intent.