You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remove max_level in favour of extracting it from the Filter
Documentation for `log` specifies that all implementations must have a
way to initialize `log::set_max_level()` (because it otherwise defaults
to `Off`), in our case via the `with_max_level()` builder - and by
calling `init_once()`. Over time `android_logger` received `env_filter`
support for much more fine-grained control over filtering, making
`android_logger` similar to `env_logger` in its implementation.
With this change however, ambiguity arises when independently
configuring log levels through `.with_max_level()` and
`env_filter::Filter`. The former acts as an early performance save
directly in `log::log!()` macros while the latter applies additional
filtering inside `android_logger`. In short: `log::max_level()` must
be at least as high as what `Filter` can process, otherwise messages get
lost before they reach the `Filter`.
`env_logger` solved this ambiguity by hiding direct access to
`log::set_max_level()` as an implementation detail and initializing it
to the highest level that could possibly be processed by the `Filter`.
Mimick this inside `android_logger` by removing the `with_max_level()`
setter. In addition all internal `is_enabled()` filtering and related
tests are removed because we rely on the `log` macros themselves to
filter, and no longer track `max_level` inside. Keeping in mind that
any user can techincally change `log::set_max_level()` to increase or
decrease global verbosity.
The only complexity remains around `__android_log_is_loggable_len()`
on Android 30 and above (if enabled on the crate by the user - not
necessarily based on the actual minimum nor target SDK level yet!)
which asks the Android system for `env_filter`-like per-module (tag)
level overrides.
0 commit comments