Use __android_log_is_loggable in AndroidLogger::enabled #84

dextero · 2025-02-24T14:48:18Z

Android's C logging API determines the effective log level based on a combination [1] of a global variable, system-wide properties [2], and call-specific default. log + android_logger crates add another layer of log filtering on top of that, independent from the C API.

        .-----.
        | app |
        '-----'
           |
           v
     .-----------.   filter by STATIC_MAX_LEVEL [3] +
     | log crate | - MAX_LOG_LEVEL_FILTER [4],
     '-----------'   overrideable via log::set_max_level
           |
           v
.----------------------.
| android_logger crate | - filter by Config::max_level [5]
'----------------------'
           |
           v
       .--------.
       | liblog | - filter by global state or system-wide properties [2]
       '--------'

The result is that in mixed C/C++ + Rust applications, logs originating from Rust use the least verbose level configured, which sometimes results in unexpected loss of logs.

In addition, adjusting the log level globally via system properties, very useful in work on the AOSP itself, currently works only up to the level android_logger defaults to.

This change makes AndroidLogger completely delegate log filtering to the underlying liblog when Config::max_level is unset by using __android_log_is_loggable.

Setting Config::max_level, or calling log::set_max_level still keep the existing behavior of filtering the logs before they reach liblog, but the default is now to have the log level consistent between Rust and C/C++ logs.

It also removes one TODO from the code :)

Tested by:

running a test app that uses Rust logs of all levels on a rooted device, using both Android's liblog C API and android_logger ones
adjusting the log.tag system property [2] via adb shell setprop
verifying the message filtering changes according to log.tag changes consistently for logs from both languages

This PR depends on bindings being added in rust-mobile/android_log-sys-rs#6

[1] https://cs.android.com/android/platform/superproject/main/+/main:system/logging/liblog/properties.cpp;l=243;drc=b74a506c1b69f5b295a8cdfd7e2da3b16db15934
[2] https://cs.android.com/android/platform/superproject/main/+/main:system/logging/logd/README.property;l=45;drc=99c545d3098018a544cb292e1501daca694bee0f
[3] https://github.com/rust-lang/log/blob/0551261bb4588b7f8afc8be05640347c97b67e10/src/lib.rs#L1536
[4] https://github.com/rust-lang/log/blob/0551261bb4588b7f8afc8be05640347c97b67e10/src/lib.rs#L469
[5]

android_logger-rs/src/lib.rs

Line 198 in d51b7ff

metadata.level() <= config.log_level.unwrap_or_else(log::max_level)

Nercury · 2025-03-04T10:09:36Z

Merged rust-mobile/android_log-sys-rs#6, please use it as dependency.

Nercury · 2025-03-04T14:10:54Z

One question: are we sure it's safe to call __android_log_is_loggable? Is anyone relying on older NDK version?

We can handle this by bumping major version (leave this to someone publishing the crate), plus, adding a note in readme that this library requires specific NDK.

MarijnS95 · 2025-03-04T14:23:04Z

Looks like this requires API level 30 (probably in most recent NDKs, but also requires phones to run Android 11 at runtime):

https://cs.android.com/android/platform/superproject/main/+/main:system/logging/liblog/include/android/log.h;l=336-338;drc=64c4c0403e3bf8eccc843bce2afebf6b2ae5af87

Nercury · 2025-03-04T14:28:19Z

Another way to handle are the cargo features.

dextero · 2025-03-04T14:45:52Z

One question: are we sure it's safe to call __android_log_is_loggable? Is anyone relying on older NDK version?

Great point. After double checking, only 2 bindings from android_log-sys that require API level 30 before rust-mobile/android_log-sys-rs#6 - _android_log_is_loggable and __android_log_write_log_message. Neither of those is used in android_logger currently. I'll wrap the new code in a feature.

Or is there a way to check for Android API version at compile time?

MarijnS95 · 2025-03-04T15:11:11Z

Or is there a way to check for Android API version at compile time?

At runtime: rust-mobile/ndk#479, see how fn device_api_level() is implemented. This requires using weak symbols or linking them via e.g. libloading at runtime.

At compile time crates like the ndk use api-level-NN crate features, but other crates checked if an Android API version was set in the C-only build path via the __ANDROID_API__ define:

gimli-rs/findshlibs#65
rust-lang/backtrace-rs#415

This spiraled into a bunch of bugs when build tools didn't set that:

rust-mobile/xbuild#209
rust-lang/backtrace-rs#656
gimli-rs/findshlibs#82

And in general considering that we're building Rust, assuming a C(++) environment is set up seems flawed (except for the final target-specific linker).

Nercury · 2025-03-04T15:30:20Z

I have landed the PR that splits the project into multiple files, sorry about that. But it should be easier to work with.

dextero · 2025-03-04T17:06:08Z

Thank you for the blazing fast feedback, I can barely keep up 😄 I rebased the PR onto current master.

As for the API version 30 discussion - I ended up adding a feature for this, and adding CI builds for default/no/all features.

Nercury · 2025-03-04T20:53:18Z

Ugh, I did it again. Ok, I promise to not merge anything else before this.

Android's C logging API determines the effective log level based on a combination [1] of a global variable, system-wide properties [2], and call-specific default. log + android_logger crates add another layer of log filtering on top of that, independent from the C API. ``` .-----. | app | '-----' | v .-----------. filter by STATIC_MAX_LEVEL [3] + | log crate | - MAX_LOG_LEVEL_FILTER [4], '-----------' overrideable via log::set_max_level | v .----------------------. | android_logger crate | - filter by Config::max_level [5] '----------------------' | v .--------. | liblog | - filter by global state or system-wide properties [2] '--------' ``` The result is that in mixed C/C++ + Rust applications, logs originating from Rust use the least verbose level configured, which sometimes results in unexpected loss of logs. In addition, adjusting the log level globally via system properties, very useful in work on the AOSP itself, currently works only up to the level android_logger defaults to. This change makes AndroidLogger completely delegate log filtering to the underlying liblog when Config::max_level is unset by using __android_log_is_loggable. Setting Config::max_level, or calling log::set_max_level still keep the existing behavior of filtering the logs before they reach liblog, but the default is now to have the log level consistent between Rust and C/C++ logs. It also removes one TODO from the code :) Tested by: - running a test app that uses Rust logs of all levels on a rooted device, using both Android's liblog C API and android_logger ones - adjusting the log.tag system property [2] via adb shell setprop - verifying the message filtering changes according to log.tag changes consistently for logs from both languages [1] https://cs.android.com/android/platform/superproject/main/+/main:system/logging/liblog/properties.cpp;l=243;drc=b74a506c1b69f5b295a8cdfd7e2da3b16db15934 [2] https://cs.android.com/android/platform/superproject/main/+/main:system/logging/logd/README.property;l=45;drc=99c545d3098018a544cb292e1501daca694bee0f [3] https://github.com/rust-lang/log/blob/0551261bb4588b7f8afc8be05640347c97b67e10/src/lib.rs#L1536 [4] https://github.com/rust-lang/log/blob/0551261bb4588b7f8afc8be05640347c97b67e10/src/lib.rs#L469 [5] https://github.com/rust-mobile/android_logger-rs/blob/d51b7ffdacf20fb09fd36a6b309b50240ef50728/src/lib.rs#L198

Build with default features, no features and all features enabled.

dextero · 2025-03-05T12:36:12Z

Ok, all green now 😄

Nercury · 2025-03-05T13:22:07Z

This requires some documentation: how it is integrated to the android toolchain, and that there is a feature flag to switch it. Nothing much, just enough so that users are aware.

Nercury

LGTM, it would be great to have some info in the README about this feature

dextero · 2025-03-05T16:08:31Z

I added a description of how this integrates with Android logging facilities when the feature is enabled, PTAL 😄

Nercury · 2025-03-05T16:10:55Z

Awesome, thanks! Have you had a chance to test it while running on sim/device?

dextero · 2025-03-06T15:27:50Z

Sorry for the late response, a couple urgent things came up.

Here's the exact code & steps I used to test: https://github.com/dextero/log-test

MarijnS95 · 2025-03-13T19:40:00Z

src/config.rs

+            // LevelFilter::to_level() returns None only for LevelFilter::Off
+            None => android_log_sys::LogPriority::SILENT,
+        },
+        None => android_log_sys::LogPriority::INFO,


Shouldn't this be log::max_level() to match what default_is_loggable does by default when no config_level is set?

MarijnS95 · 2025-03-13T19:41:38Z

README.md

+[`__android_log_set_minimum_priority`](https://cs.android.com/android/platform/superproject/main/+/main:prebuilts/runtime/mainline/runtime/sdk/common_os/include/system/logging/liblog/include/android/log.h;l=364;drc=4cf460634134d51dba174f8af60dffb10f703f51))
+and Android system properties when deciding if a message should be logged or
+not. In this case, the effective log level is the _least verbose_ of the levels
+set between those and Rust log facilities.


Shall we link Rust log facilities to (the documentation for) log::set_max_level() once again?

MarijnS95 · 2025-03-13T19:42:11Z

@dextero perhaps that test/sample project would be perfect as an example checked in to this repo?

dextero mentioned this pull request Mar 4, 2025

Prevent truncating log tag name #83

Merged

Nercury mentioned this pull request Mar 4, 2025

Split things into different files, to optimize future work #85

Merged

dextero force-pushed the is-loggable branch from 40d9584 to 8b44438 Compare March 4, 2025 17:03

Marcin Radomski added 2 commits March 5, 2025 10:33

Add feature builds to CI

3aa2a12

Build with default features, no features and all features enabled.

dextero force-pushed the is-loggable branch from 8b44438 to 3aa2a12 Compare March 5, 2025 10:34

Reformat with 1.85 toolchain

2581c25

Nercury approved these changes Mar 5, 2025

View reviewed changes

Marcin Radomski added 2 commits March 5, 2025 16:04

Document the behavior of android-api-30 feature

a14e0c8

Fix typos

e6931cf

Nercury merged commit d829810 into rust-mobile:master Mar 5, 2025
72 checks passed

MarijnS95 reviewed Mar 13, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use __android_log_is_loggable in AndroidLogger::enabled #84

Use __android_log_is_loggable in AndroidLogger::enabled #84

dextero commented Feb 24, 2025

Nercury commented Mar 4, 2025 •

edited

Loading

Nercury commented Mar 4, 2025

MarijnS95 commented Mar 4, 2025 •

edited

Loading

Nercury commented Mar 4, 2025

dextero commented Mar 4, 2025

MarijnS95 commented Mar 4, 2025

Nercury commented Mar 4, 2025 •

edited

Loading

dextero commented Mar 4, 2025

Nercury commented Mar 4, 2025

dextero commented Mar 5, 2025

Nercury commented Mar 5, 2025

Nercury left a comment

dextero commented Mar 5, 2025

Nercury commented Mar 5, 2025 •

edited

Loading

dextero commented Mar 6, 2025

MarijnS95 Mar 13, 2025

MarijnS95 Mar 13, 2025

MarijnS95 commented Mar 13, 2025

Use __android_log_is_loggable in AndroidLogger::enabled #84

Use __android_log_is_loggable in AndroidLogger::enabled #84

Conversation

dextero commented Feb 24, 2025

Nercury commented Mar 4, 2025 • edited Loading

Nercury commented Mar 4, 2025

MarijnS95 commented Mar 4, 2025 • edited Loading

Nercury commented Mar 4, 2025

dextero commented Mar 4, 2025

MarijnS95 commented Mar 4, 2025

Nercury commented Mar 4, 2025 • edited Loading

dextero commented Mar 4, 2025

Nercury commented Mar 4, 2025

dextero commented Mar 5, 2025

Nercury commented Mar 5, 2025

Nercury left a comment

Choose a reason for hiding this comment

dextero commented Mar 5, 2025

Nercury commented Mar 5, 2025 • edited Loading

dextero commented Mar 6, 2025

MarijnS95 Mar 13, 2025

Choose a reason for hiding this comment

MarijnS95 Mar 13, 2025

Choose a reason for hiding this comment

MarijnS95 commented Mar 13, 2025

Nercury commented Mar 4, 2025 •

edited

Loading

MarijnS95 commented Mar 4, 2025 •

edited

Loading

Nercury commented Mar 4, 2025 •

edited

Loading

Nercury commented Mar 5, 2025 •

edited

Loading