rust-mobile/android_logger-rs

A Rust logging implementation for `log` which hooks to android log output

android_logger-rs's Issues

How to link to android log lib?

Hi,

This only works on Android and requires linking to log which is only available under android.

But how can I linking to the log? Thanks!

Compilation error

Hi! I am trying to use your lib in my project, but it won't compile:

   Compiling android_logger v0.11.1
error: type parameters must be declared prior to const parameters
   --> /home/caiiiycuk/.cargo/registry/src/github.com-1ecc6299db9ec823/android_logger-0.11.1/src/lib.rs:437:33
    |
437 | fn uninit_array<const N: usize, T>() -> [MaybeUninit<T>; N] {
    |                -----------------^- help: reorder the parameters: lifetimes, then types, then consts: <T, const N: usize>

Not all Android versions do now log

I upgraded from 0.12.0 to 0.13.0, and while logging still works at API 33, I get with indentical apk, no output in API 26 for example.
I don't know why? Could it be not selecting proper output log buffer? I basically do this:

 android_logger::init_once(Config::default().with_max_level(LevelFilter::Trace));

RFC: may be use std::sync::Once instead of std::sync::RwLock ?

Number of RwLock were increased after #23

filter: RwLock<Filter>,
tag: RwLock<Option<CString>>,

may be use std::sync::Once instead? It looks like
much simplier (one atomic) in compare to RwLock which implementation depend on OS,
in case of android I suppose it uses pthread_rwlock_t which is not light weight.

What do you think?

Setting levels for multiple crates does not function?

// Show trace and above level messages for this crate and some_other_crate
    android_logger::init_once(
        Config::default().with_min_level(Level::Trace).with_filter(FilterBuilder::default()
            .parse("trace,some_other_crate=trace").build()))

First, I want to make sure the syntax above is correct. Whereas the primary crate displays logs correctly, some_other_crate doesn't show anything at all. Just incase, in some_other_crate, I have this in Cargo.toml:

log = { version = "0.4.8", features = ["std", "max_level_trace", "release_max_level_trace"] }

I'm including the aforementioned line because I don't know if that may cause interference or not

Crate compilation broken on Android

Hello,

I've not been able to compile the latest release (0.11.2) of this crate on Android. Compilation fails with the following output:

   Compiling android_logger v0.11.2
error[E0061]: this function takes 2 arguments but 1 argument was supplied
   --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/android_logger-0.11.2/src/lib.rs:295:9
    |
295 |           Self::new_with_priority(match level {
    |  _________^^^^^^^^^^^^^^^^^^^^^^^-
296 | |             Level::Warn => LogPriority::WARN,
297 | |             Level::Info => LogPriority::INFO,
298 | |             Level::Debug => LogPriority::DEBUG,
299 | |             Level::Error => LogPriority::ERROR,
300 | |             Level::Trace => LogPriority::VERBOSE,
301 | |         })
    | |__________- an argument of type `&CStr` is missing
    |
note: associated function defined here
   --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/android_logger-0.11.2/src/lib.rs:282:12
    |
282 |     pub fn new_with_priority(priority: log_ffi::LogPriority, tag: &CStr) -> PlatformLogWriter {
    |            ^^^^^^^^^^^^^^^^^ ------------------------------  ----------
help: provide the argument
    |
295 ~         Self::new_with_priority(match level {
296 +             Level::Warn => LogPriority::WARN,
297 +             Level::Info => LogPriority::INFO,
298 +             Level::Debug => LogPriority::DEBUG,
299 +             Level::Error => LogPriority::ERROR,
300 +             Level::Trace => LogPriority::VERBOSE,
301 +         }, /* &CStr */)
    |

As specified in the output, it looks like function new doesn't pass the mandatory tag argument to new_with_priority: https://github.com/Nercury/android_logger-rs/blob/38186ece1056d90b8f75fd2a5eb5c860e0a1704e/src/lib.rs#L281-L302

Don't use `::` as a module separator

That's pretty annoying, but Android tag names are not supposed to include columns apparently.

With adb logcat, we can not filter by module if the module include a column.

For foo::bar, we can't do adb logcat foo::bar because adb will interpret that as "tag foo, log level bar".

I'm not sure what should be done here. Maybe replace :: with ;;, then we could do: adb logcat foo;;bar.

Panic messages are not printed on android.

I have android logger setup in the rust library.
If the library panics, there are no errors logged. Messages are only logged if the explicit info!() or error!() is called.

Add a way to unhook the logger

Currently the app would segfault on attempt to log after the activity is destroyed (i.e. because the screen was rotated). Provide a way to easily unhook this logger, and make it part of example.

Expose AndroidLogger

I see that you made AndroidLogger private in the last release. Would it be possible to make it public? I need to use this underneath another logging system.

Allow for multiple log level depending on the module

Hi!

I'm in the case where I want to have a different log level depending on the crate emitting the log. The current API allows only for a single level and an additional white list.

Proposed new api

add a with_module_path_level to the filter to specify the different modules you want to be treated differently from the default. As a side note the behaviour in #29 would be interesting here too

Enhance module path match in filter

Is that possible to use str.contains to do module path match in filter, just like env_logger did? The use case is when there are many crates and modules could output logs, it is easier to use string pattern match to filter out it.

Consider implementing `Log::enabled`

I was curious if there was a particular reason why Log::enabled was implemented to return true all the time: was it because it was never really implemented historically, or because it would entail taking the global lock more often? I think it would be nice to implement because log's log_enabled!() macro relies on this to decide whether to enter a code section or not, and this can have a pretty large performance impact, so it would be nice to have. If there's interest and no particular reason why it was not implemented, I'd be happy to write the simplest patch: take lock, compare config filters with what's in the metadata.

Support selecting the target log buffer

Android has several different log buffers that can be targeted when writing a log message. This library currently only supports writing to the main buffer, but it would be useful to select different target buffers in some cases. In the Android codebase we're currently patching android_logger so that we can select a target buffer from Rust code, but it would be nice to add this support in the main crate so that others can take advantage of it (and so that it's easier for us to pull in future updates of android_logger).

I'll open up a PR that pulls in our existing patches shortly, but I wanted to also open this separate issue in case there were any comments/concerns with adding this feature 🙂

Is there a way to filter logs origin?

My project use multiple crates. I only want the logs from mine, not all the others.

Include module path in log message if explicit tag present

Having used the android logger for a number of months now, I disagree with https://github.com/Nercury/android_logger-rs/issues/22#issuecomment-409182664 . I think including the module name in the message is helpful for understanding the context of various debug messages, especially when several modules are included in the output. It would be useful to include the module path in the final log message.

Use MaybeUninit instead of mem::uninitialized() or somehow remove unitialized memory usage

mem::uninitialized() was used to put outgoing messages on stack and avoid hitting allocator for each and every message. The same effect could be achieved in safe code by re-using the same allocated storage.

Care must be taken to ensure that logged messages do not exceed android allowed message length. It would also be great if the current behavior of splitting too long message at new lines is preserved.