I just wrote up a bash completion script, this goes into `/etc/bash_completion.d/` then the next time you launch `/bin/bash`, `pidcat` will have full, interactive completion, including automatic fetching of device serials and package names, i.e.:
```bash
pidcat --serial e [Tab]
pidcat --serial emulator-5554
```
and
```bash
pidcat info.g [Tab]
pidcat info.guardianproject.o [Tab]
pidcat info.guardianproject.otr.app.im
```
Use under whatever free software license you want: (GPL, LGPL, MIT, BSD, Apache, public domain, etc)
Some phones (like my samsung) do not log the 'Start proc ...' line in
logcat to indicate process start. In my case it does log a line like
E/dalvikvm(pid): >>>>>> com.my.package [ more stuff ]
This commit adds support for that format to pidcat.
This specifically handles the case where you get a log snippet that may
not have any pid creation lines in it and pidcat ends up filtering
everything out. In this case we just print the line if we haven't seen
any pids yet.
An alternative would be allowing filter by pid, however I find grep
works fine for that.
Summary: The regexes for process exits were no matching secondary processes, which makes it understandably hard to track their
lifecycles. Fix it by including ':' in the process name match groups, as in the process start regex.
Test Plan: Run, match the chrome process name, com.android.chrome, see its secondary processes start reporting their death.
Summary: Android apps can use multiple processes (eg, chrome), which are identified as <package_name>:<process_name> in logs. The names are defined in the manifest.
The main process is referred to as simply <package_name> by android.
Add the ability to specify a target process as part of what was until now the package name in pidcat, or all processes if no process is specified.
Usage:
* pidcat <package_name> will match all of an app's processes (catchall).
* pidcat <package_name>:<process_name> will match a given named process.
** In particular, pidcat <package_name>: will ensure only the app's main/default process is matched.
Test Plan: Run the script, try out with no process, empty (aka default) process, named process. Try multiple entries.
Summary: Making sense of a birth/death message is made easier by specifying which process it applies to, and not just the component or the pid.
Test Plan: Run, monitor message lines when cycling a multi-process app, inject None as a process name to check resilience.