0

When decompiling an app, I find lately, that a few apps' manifests do not seem to have designated activities for the view I want. For example, if com.example.app is on the view I want and I run the following command:

dumpsys window windows | grep -E 'mCurrentFocus|mFocusedApp'

the resultant output will be something like:

mCurrentFocus=Window{9280f2a u0 com.example.app/com.example.app.MainSubMenu}
mFocusedApp=AppWindowToken{da37759 token=Token{9d56fa0 ActivityRecord{5c490a3 u0 com.example.app/.MainSubMenu t98}}}

This is fine, but when the screen I am on is obviously a subactivity/subview/fragment, dumpsys nor logcat will show me the full path to this view. In short, I would like to find the name of the fragment/view and launch directly to it. This syntax looks promising for achieving a fragment view launch (perhaps with some variation):

am start -n com.example.app/.MainSubMenu -e :android:show_fragment com.example.app.somefragmentview

but I am unsure of how to find all fragment names for each activity of the app.

SiHa
  • 7,830
  • 13
  • 34
  • 43
itsthegrimace
  • 9
  • 2
  • fragments are listed in the manifest as well. but knowing fragment names won't help you much. most of the time fragments require extras of types not supported by `am` command to be displayed properly. – Alex P. Sep 01 '17 at 03:43
  • Thank you Alex P. I discovered I was actually asking the same question presented here: https://stackoverflow.com/questions/18522733/how-to-get-extras-of-currently-running-activity-through-adb – itsthegrimace Sep 01 '17 at 09:03
  • To be more specific, logcat will output something like: I/ActivityManager(530): START u0 {cmp=com.example.app/.MainSubMenu (has extras)} from uid 10083 on display 0. I need something to dump the 'has extras' information. – itsthegrimace Sep 01 '17 at 11:00
  • Anyone? Logcat and dumpsys are mum...perhaps there are more verbose logging tools that will provide this information? – itsthegrimace Sep 02 '17 at 07:47

1 Answers1

0

I ended up using AutoInput in combination with MacroDroid to select specific elements of the app's main (launch) screen, based on text. This gets me to any screen of an app without having to rely on touch event coordinates, since developers of these apps typically switch up menu item locations with subsequent updates.

Here is the AutoInput process in detail (which I imagine can be integrated with Tasker as well):

  1. Install both aforementioned apps.
  2. When selecting an Action for MacroDroid, choose the 'Locale/Tasker Plugin' option. This will list AutoInput's options, and any other options for different plugins you've downloaded, I suppose.
  3. Choose the 'AutoInput Action' option from the list.
  4. Select 'Action' from the next screen, then 'Click'.
  5. For 'Field Type' choose 'Text', or any other piece of information you know about the menu/button/element that you would ordinarily select to get to the screen you want. We are talking about a menu/button/element that exists on the main (launch) screen of your app.
  6. Fill in 'Field Text' with the menu/button/element's text.
  7. Hit the checkmark at the top right when you are finished, and it will return you to MacroDroid.

A few notes:

  • The menu/button/element MUST be visible on the main (launch) screen for AutoInput to identify and select it. The initial menu item I was attempting to open could only be reached by scrolling down first. To remedy this, I told MacroDroid to run a script with an 'input swipe' command first to make the menu item visible.

  • If your target menu/button/element is not on the main (launch) screen, you will have to follow up your initial AutoInput Action with subsequent AutoInput Actions until you reach the menu/button/element/screen you want. The screen I wanted was twice removed from the main (launch) screen.

  • Maybe it goes without saying, but I separated each AutoInput Action with an appropriate pause (in MacroDroid, Actions-->'Wait Before Next Action') to select each menu/button/element while accounting for screen load time.

This is all a bit obtuse, I realize, but without knowing how to extract the (has extras) information from Logcat, this was the only available solution that didn't force me to rely on coordinates for touch events. Hopefully this offers a viable alternative until someone finds/offers a way to pull raw extra data from activities.

itsthegrimace
  • 9
  • 2