AndLogView
GitHub Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Filters

AndLogView provides many ways to highlight interesting log lines and hide non-interesting. This is achieved with log filtering. Filtered lines can be highlighted with a background color, hidden, or displayed in a separate window.

Creating a filter

Use “Add new filter” button to create a new filter:

Add new filter button

A filter creation dialog appears:

“Create new filter” dialog

You can then specify filter criteria here:

  • “Tags to filter” – the comma-separated list of tags to match
  • “Message text to filter” - the message substring to match
  • PIDs or app names to filter” - the comma-separated list of integer PIDs or app names.
  • “Log level” - the minimal log level to match.

If you specify multiple tags, then line need to match any of them to match. The same applies to PIDs and app names.

The filter matches the log line only if all criterias are fulfilled. For example, if the filter specifies tag=Foo and PID=143, 144 then lines with the tag Foo from PID 441 wouldn’t match.

The radio buttons determine the filter’s action. The matched lines can be:

  • Shown (all other lines will be hidden)
  • Hidden
  • Highlighted with one of four colors
  • Shown in a separate (index) window

Index window

An index window is a separate window that only shows lines matching the filter. You can double-click on line numbers in the index window to scroll the main window to them.

Index window

Filter criteria

Tags

Simple tag filters are case-insensitive and match the whole tag. For example, a filter Foo matches tags Foo, FOO and foo, but not FooBar.

You can use regular expressions to specify tag filters. Unlike simple patterns, regular expressions match substrings and are case-sensitive. For example, /Foo/ matches Foo and FooBar, but not foo.

Multiple tag patterns can be separated with a comma, for example, a filter foo, bar matches both Foo and BAR. Note that leading and trailing whitespaces, as well as whitespaces around commas are ignored. The patterns that contain commas or leading and trailing whitespace can be escaped.

You can mix regular expressions and simple patterns.

Message text

Simple message text filter is case-insensitive and matches a substring of the log message.

You can use regular expression (regexp) to specify message text filter. The regexp is case-sensitive.

PIDs and app names

Integers are always interpreted as PID patterns. Non-integers are interpreted as app name patterns. Like tags, simple app name patterns are case-insensitive and match the whole tag. For example, com.example.app matches COM.EXAMPLE.APP, but not com.example.app:boot.

You can use regular expressions to specify app name filters. Unlike simple patterns, regular expressions match substrings and are case-sensitive. For example, /com.example.app/ matches com.example.app and com.example.app:boot, but not COM.EXAMPLE.APP.

Multiple patterns can be separated with a comma, for example, a filter com.example.app, system_server matches both`. Note that leading and trailing whitespaces, as well as whitespaces around commas are ignored. The patterns that contain commas or leading and trailing whitespace can be escaped.

You can mix regular expressions and simple patterns.

Regular expressions

Tags, message and app name filters support regular expressions as patterns. To make pattern a regular expression wrap it in slashes (/…/). For example, /^[Aa]/ looks up all lines that start with lower or upper a.

Standard Java regular expression syntax is used.

Regex-based search is case-sensitive, and matches substrings. You can use ^…$ to match the whole string only.

It is safe to use the slash symbol / in the regular expression. However, commas in tag and app name patterns must be escaped by doubling it. For example, to use the pattern /foo, bar/ as a tag pattern you must enter it as /foo,, bar/. Otherwise it is going to be interpreted as two simple patterns /foo and bar/.

Interaction of multiple filters

If you have created multiple filters the following rules apply:

  1. If the log line matches by any of the hiding filters it is hidden
  2. If the log line matches by any of the show-only filters it is shown
  3. If there is at least one show-only filter and the log line is not affected by rules 1 or 2 then it is hidden
  4. If there is a highlighting filter and the log line isn’t hidden by the rules above, it is highlighted with the corresponding color
  5. If the line was added to bookmarks and isn’t hidden it is highlighted
  6. Lines that are hidden in the main window, are not visible in index windows.

Only lines in the main window are highlighted.

Filter panel

The filter panel is located to the right of the “Add new filter” button. Each filter has a corresponding button on the filter panel.

Filter panel

Double-clicking the empty space of the filter panes opens the filter creation dialog too.

The filter button can be in two states: pressed, when the filter is active, and not pressed, when the filter is temporary disabled.

If the filter’s action is “Show in index window”, then toggling the filter toggles visibility of the corresponding index window. Closing the index window unpresses the button.

A tooltip of the filter button shows a summary of the filter:

Filter button tooltip

When you have too many filters to fit in the panel, scroll buttons appear on the left and the right sides.

Scroll buttons of the filter panel

Edit or remove a filter

Use a filter button’s context menu to edit or remove the filter.

Context menu to edit or remove filter

Edited filter moves to the end of the filter panel.

Quick filters

You can quickly create a filter for PID, app name, tag, priority, or message text of the line by right-clicking on the corresponding cell in the main window.

Quick filters for PID

“Create filter for this {pid, app, priority, tag, message}…” opens the pre-filled filter creation dialog. Other actions create the filter immediately.

Escaping characters in text patterns

Slash, comma, and whitespace have special meaning when used in the patterns for tag, PID, and app name filters. When you need to use these symbols as part of a pattern, they must be escaped.

  • If a simple or regular expression pattern contains a comma, the comma symbol must be doubled: foo, bar becomes foo,, bar.
  • If a simple pattern contains a leading or trailing whitespace, the pattern must be enclosed in backticks. For example, ··foo must be entered as `··foo` (a space is represented as · for clarity).
  • Backticks can also be used to escape commas in simple patterns. For example, foo, bar can be entered as foo,, bar.
  • Leading and trailing whitespaces are meaningful for regular expression patterns. For example /·foo/ matches foo with a leading space (the space is represented as · for clarity).
  • Using backtick symbol in the pattern is safe, unless it is the first symbol or the pattern is enclosed in backticks.
  • A backtick symbol in the pattern enclosed in backticks must be doubled.
  • A pattern that starts with a backtick symbol must be enclosed in backticks.
  • A simple pattern may start or end with a slash, but not both. Such pattern is always interpreted as a regular expression. You can convert the pattern to a regular expression as a workaround.
  • A regular expression pattern may contain slash symbols anywhere.

Wrapping regular expression pattern in backticks is not supported and not needed in general.

Message pattern and search do not support escaping, and do not need it in most cases.

When opening the filter for editing, you may notice that the way of escaping changes. The filter editor doesn’t preserve the original escapes and attempts to employ the simplest possible escaping instead.