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.
Use “Add new filter” button to create a new filter:
A filter creation dialog appears:
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
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.
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.
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.
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.
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/
.
If you have created multiple filters the following rules apply:
- If the log line matches by any of the hiding filters it is hidden
- If the log line matches by any of the show-only filters it is shown
- 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
- If there is a highlighting filter and the log line isn’t hidden by the rules above, it is highlighted with the corresponding color
- If the line was added to bookmarks and isn’t hidden it is highlighted
- Lines that are hidden in the main window, are not visible in index windows.
Only lines in the main window are highlighted.
The filter panel is located to the right of the “Add new filter” button. Each filter has a corresponding button on the 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:
When you have too many filters to fit in the panel, scroll buttons appear on the left and the right sides.
Use a filter button’s context menu to edit or remove the filter.
Edited filter moves to the end of the filter panel.
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.
“Create filter for this {pid, app, priority, tag, message}…” opens the pre-filled filter creation dialog. Other actions create the filter immediately.
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
becomesfoo,, 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 asfoo,, bar
. - Leading and trailing whitespaces are meaningful for regular expression
patterns. For example
/·foo/
matchesfoo
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.