I know that many people already sent questions similar to this. However, this is a little different.
I have to try to get the current activity from an android app, but it is not possible. Normally, I interact with the app and execute this: adb shell dumpsys window windows | grep -E 'mCurrentFocus|mFocusedApp'. However, it always shows MainActivity. I checked the activity list on APK Info and this list is so little
So, there is some way to start a specific screen of apps similar to this?
With "adb shell settings get global autofill_compat_mode_allowed_packages" you can see all the whitelisted apps that require compatibility mode for the autofill service.
I'm wondering how that list gets pre populated.
I am not able to find any documentation about this list.
I have two queries mentioned below:
how can I add my own app to this list without using "adb shell settings put global autofill_compat_mode_allowed_packages pkg1[resId1]:pkg2[resId1,resId2]" all the time as it requires root access?
Is there any way to do that programmatically, i.e. once my app starts it will be added to the whitelist. It seems like this list is a predefined list from Android. Am I right?
Looking forward for to some inputs.
adb shell settings put global autofill_compat_mode_allowed_packages pkg1[resId1]:pkg2[resId1,resId2]
See here for more information here.
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).
Is there any way of finding when an application is closed (either by user or system) i.e the application can only be restarted by the user by pressing the application launcher icon.
I think it is only possible if Android system broadcast any Intent when a name of a process is removed from getRunningAppProcesses().
I have read all the possible Q&A on the SO and the question is not related with the ActivityLifecycle.
Generally, waiting for a user to "exit" an app is a bad idea, since:
The user never actually exists the app, they simply leave it on the activity stack and come back to it later.
A user might do anything during your database update, such as reenter the app.
You can't really detect this without very hacky solutions; this is by design of the API, because you shouldn't need to do these kinds of things.
Because of this, I think any solution based on waiting for the app to "die" is a bad one. Instead, you should come up with a solution that respects the semantics of the application. For example, if you are entering data in one of its content providers then it should handle consistency (across fragments in the app, for example).
Hmm.. You can manually monitor /proc on the filesystem to see if the process id is present for the application you care about.
From your terminal window try the following. For example :
> MYPID=(`adb shell ps | grep com.mydomain.myapp | awk '{print $2}'`)
> adb shell [ -d /proc/$MYPID ] && echo "PID $MYPID Exists"
Replace com.mydomain.myapp with your apps package name
There are several apps available to monitor processes on android.
Take a look at http://code.google.com/p/android-os-monitor/
The android-os-monitor project uses a JNI layer to implement the interaction with /proc
http://code.google.com/p/android-os-monitor/source/browse/OSMonitor/jni/process.c?repo=osmonitor
http://code.google.com/p/android-os-monitor/source/browse/OSMonitor/src/com/eolwral/osmonitor/JNIInterface.java?repo=osmonitor
http://code.google.com/p/android-os-monitor/source/browse/OSMonitor/src/com/eolwral/osmonitor/processes/ProcessList.java?repo=osmonitor
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.)