[Galaxy S II Original Android Development] Tungstwenty:
You mean the approach of running "service call activity 79 ...", right?

Using the service call would be a "cleaner" stop since the activity would be subject to the normal lifecycle of receiving a pause(), stop(), ... requests from the activity manager.

But if the app is not responding, it might take more time - perhaps up to 20s - for it to respond and even trigger the "app is not responding" dialog. In that case, yes, the "kill <pid>" is guaranteed to work since it bypasses the userland manager and is a signal from the kernel directly to the linux process. And if even that fails (because it's a SIGTERM that allows the app to trap and respond or ignore the signal), you can issue "kill -9 <pid>" which sends a SIGKILL; non-trappable by the process so it won't even know what hit it, but there won't also be any housekeeping on open database files, etc ...

I'm guessing you only run "am start com.anddoes.launcher/.Launcher", right? I hope so, as that would easily explain the problem :)

That's only enough for mimicking simple app execution actions. For "contextualized" actions, such as opening a particular window within an app, you'll need the extra arguments.

Running "am" you'll see in the help output something like:

...
usage: am start [-D] [-W] [-P <FILE>] [--start-profiler <FILE>]
[--R COUNT] [-S] <INTENT>
...
am start: start an Activity. Options are:
-D: enable debugging
-W: wait for launch to complete
--start-profiler <FILE>: start profiler and send results to <FILE>
-P <FILE>: like above, but profiling stops when app goes idle
-R: repeat the activity launch <COUNT> times. Prior to each repeat,
the top activity will be finished.
-S: force stop the target app before starting the activity
...
<INTENT> specifications include these flags and arguments:
[-a <ACTION>] [-d <DATA_URI>] [-t <MIME_TYPE>]
[-c <CATEGORY> [-c <CATEGORY>] ...]
[-e|--es <EXTRA_KEY> <EXTRA_STRING_VALUE> ...]
[--esn <EXTRA_KEY> ...]
[--ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE> ...]
[--ei <EXTRA_KEY> <EXTRA_INT_VALUE> ...]
[--el <EXTRA_KEY> <EXTRA_LONG_VALUE> ...]
[--eu <EXTRA_KEY> <EXTRA_URI_VALUE> ...]
[--eia <EXTRA_KEY> <EXTRA_INT_VALUE>[,<EXTRA_INT_VALUE...]]
[--ela <EXTRA_KEY> <EXTRA_LONG_VALUE>[,<EXTRA_LONG_VALUE...]]
[-n <COMPONENT>] [-f <FLAGS>]
[--grant-read-uri-permission] [--grant-write-uri-permission]
[--debug-log-resolution] [--exclude-stopped-packages]
[--include-stopped-packages]
[--activity-brought-to-front] [--activity-clear-top]
[--activity-clear-when-task-reset] [--activity-exclude-from-recents]
[--activity-launched-from-history] [--activity-multiple-task]
[--activity-no-animation] [--activity-no-history]
[--activity-no-user-action] [--activity-previous-is-top]
[--activity-reorder-to-front] [--activity-reset-task-if-needed]
[--activity-single-top] [--activity-clear-task]
[--activity-task-on-home]
[--receiver-registered-only] [--receiver-replace-pending]
[--selector]
[<URI> | <PACKAGE> | <COMPONENT>]

Most of the examples use only the <COMPONENT> part of the intent, and that suffices.

For your scenario, you can pass all 3 items:

Component: com.anddoes.launcher/.Launcher

Action: com.anddoes.launcher.ACTION

Extra string argument (I'm gessing, from the "S." prefix): LAUNCHER_ACTION=APP_DRAWER

And the command line for it would be: