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.
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):
A few notes:
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.