This was introduced years ago but never gained any users.
Test: build
Merged-In: Id2deb6de1839f995970c6350a1970a872f0b51cf
Change-Id: Id2deb6de1839f995970c6350a1970a872f0b51cf
This function has been marked deprecated for quite some time, has no
users, and isn't in liblog.map.txt.
Test: build
Change-Id: Ic3bf47c780b18a5d4f1e997b9265be76049fb824
liblog exposed __android_logger_get_buffer_size() which queries log
size properties, but that should not be a generic library function.
Logd should be the only process that queries these properties and
other processes should query the actual used log sizes from logd via
the android_logger_get_log_*_size() functions.
Also, always use 1MB for log buffer tests, instead of just on host and
various other clean up related to improper types.
Test: log buffers are correctly sized
Merged-In: I9b7c86bf58e569618737afe9097cf1c4d4e61d95
Change-Id: I9b7c86bf58e569618737afe9097cf1c4d4e61d95
There is an existing API, android_logger_get_log_readable_size() which
historically reported the consumed amount of data for the chatty log
buffer, since consumed and readable are synonymous with that buffer
type.
With log compression, readable and consumed are not synonymous, since
the readable log size is the uncompressed log size whereas the
consumed log size is the compressed log size.
This change adds android_logger_get_log_consumed_size() which returns
the consumed log size and makes android_logger_get_log_readable_size()
return the readable log size. Note that these values are identical if
compression is not used.
It adds both statistics to logcat:
main: ring buffer is 1 MiB (429 KiB consumed, 817 KiB readable)
radio: ring buffer is 1 MiB (339 KiB consumed, 715 KiB readable)
...
Test: logcat prints the right values with compression and chatty
Change-Id: I8b9688a987736204e2e6026e8635fbd1a5e68bb7
ro.debuggable is set by init before other processes would possibly
call __android_log_is_debuggable(), so this property can be checked
once and stored without liblog's property caching mechanisms.
Test: this function returns accurately
Change-Id: Idb1e5e10e53ca809b7f9a75164a4982f39827d4e
All users have been moved to other, more suitable, interfaces.
Test: build
Merged-In: Ic4eb1f0ed6e35d8d6f7e63b80546f4e8bbe163e2
Change-Id: Ic4eb1f0ed6e35d8d6f7e63b80546f4e8bbe163e2
One of the reasons that logcat and logd statically include liblog is
to access the symbols in log_time.cpp, which we do not expose
otherwise. Except for strptime(), which will be handled in a separate
CL, these symbols are either small enough to inline in the header or
unused and can be removed.
Test: logging unit tests
Change-Id: I1f8cfbb779aef79fc7d5b6d0050438fe5f0e0e2c
This has been around for ~5 years but there has been roughly no
adoption, so remove this as we clean up the logging code.
Future efforts may track the monotonic timestamp in all cases.
Test: logging unit tests
Change-Id: I55ed565669f923988e741f6b384141bba893630d
This header is not needed in many of the places it is included. It
contains functions that are duplicated from the <android/log.h>
header.
Test: build
Change-Id: I6ba41d596bcc956cfed13f1d3b21e023591bce0f
These historically used atomics to manage their lifetime. They were
unfortunately unsafe and later replace with a RwLock. A lock is
also problematic as it is too heavy weight for the typical use case
and implies that logging is neither async nor fork safe.
This change returns us to using atomics with two key changes:
1) compare_exchange_strong() is used instead of atomic_exchange().
The latter has a race condition where a separate thread could have
read the atomic value into a register, while the thread performing
the atomic_exchange closes that FD. The new code only changes the
FD in the atomic if it is uninitialized.
2) Using the fact that DGRAM sockets can have connect() called on them
multiple times, it uses a single logd_socket for the duration of
the program.
These sockets are thread/async/fork safely created and accessed.
The one caveat is __android_log_close(), which is intended only to be
used by zygote when it is single threaded and is therefore not thread
safe. It will close this socket and reset the underlying variable,
such that the next log message will go through the above
initialization.
Bug: 65062446
Test: logging works, logging unit tests
Test: new unit test
Change-Id: Ia4dbf7479dbe50683d124558ab2f83bff53b8f5f
`@{link blah}` != `{@link blah}`. The latter defines a link to blah,
the former defines a custom group that is never closed. This was doing
really exciting things to devsite.
Most identifiers do not need to be explicitly linked. The two in the
struct do need to be for some reason (maybe typedef vs function, or
maybe because it's a struct, idk). I've left those two but removed all
the ones that work implicitly.
Test: staged to devsite
Bug: None
Change-Id: I9f382dab499abb27945d178e17ae8c810c619898
len is not a parameter for the function this comment was attached to.
It seems to be that the documentation was meant to apply to both
functions, so copy it and remove the incorrect parameter from the one
that does not take it.
Test: build_ndk_docs.py
Bug: None
Change-Id: I97225d4ba925a33c73b6c7f81bb7b18def363489
There's a different syntax for putting the comments _after_ the
members, but IMO more readable to just move them before the member.
Test: development/tools/ndk/build_ndk_docs.py
Bug: None
Change-Id: Iad113f449f9cb0996efc4b9d184d8e5b0ed5da85
log/log.h primarily concerns itself with writing logs. The few users
who read logs should directly include log/log_read.h.
Bug: 78370064
Test: build
Change-Id: Ie95c55ea2ffc76fc95768323d445ada6ad4f2520
There's no need to pull in <fcntl.h> to get O_NONBLOCK, since the
ANDROID_LOG_* macros are better standalone.
Also note that 0x00000003 should be reserved since these corresponded
to previously used values.
Test: build
Change-Id: Icaee6ee0250fe97d8324b3b340f7e196767b2711
logger_entry has a hdr_size field meant for backwards compatibility,
however there are a few checks that expect it to be a specific size.
More problematically, it has a variable length array element, msg[0]
at the end, that would be incorrect if the header size was not kept
static.
This change fixes up those issues to facilitate future additions.
Bug: 119867234
Test: logging works with extended size headers, logging unit tests
Test: newly added unit tests with extended size header
Change-Id: I14b2b0855d219d11f374b53a5aa8e05cd6a65eef
1) Rename __android_logger_data to __android_log_message and rename
__android_log_write_logger_data to
__android_log_write_log_message. Move the const char* message
argument into __android_log_message.
2) Add @param, @return, and "Available since API level 30." to the
documentation of new functions.
3) Document that the user defined aborter should but may not abort.
4) Document the line separation is the responsibility of the log
function provided to __android_log_set_logger().
Bug: 150898477
Test: build, liblog and libbase unit tests
Change-Id: I07c41011ef25b3e7cc4943f3f1e240a2f6aa2802
__ANDROID_API__ isn't defined on host, so this check will fail due to
-Wundef. The || is short circuited through, so we can check for host
first and only have the right side of the || evaluated for device
builds.
Bug: 150898477
Bug: 151255209
Test: build
Change-Id: I2e0bc055ac0c7ba8262875801cdaed9cc30d2cef
__android_log_get_minimum_priority caused build failures
when used in combination with strict prototypes compiler flags.
Fix this by specifying void argument.
Bug: 116329414
Bug: 119867234
Change-Id: Icbb8f66a5e35f02b57d772f5acdb9de8638d252c
Test: Manual
* When __FAKE_USE_VA_ARGS has args that are not constexpr,
reaching it in a constexpr function will be make the
constexpr function invalid.
To allow LOG_ALWAYS_FATAL_IF in a constexpr functions when
the tested condition is false, it should call __FAKE_USE_VA_ARGS
only when the tested condition is true.
* Other ALOG*_IF macros are also changed to call
__FAKE_USE_VA_ARGS only when the tested condition is true.
Bug: 148548418
Test: WITH_TIDY=1 make
Change-Id: Ie8a444dffbf9cbef78e5e0b49b44f4092bcf9982
Only print logs with priority >= INFO on host, as fake_log_device
does.
This fixes a regression in host builds where loggability wasn't
checked at all.
Bug: 69935292
Test: ART host tests don't print extraneous logs
Change-Id: I885b794da6f24bd905192252925e4a9f88b06674
See the previous commit moving SetLogger and SetAborter to liblog for
motivation.
This creates more harmony between the two mechanisms in libbase and
liblog for checking loggability.
Currently:
1) libbase filters all messages based on its minimum log priority. For
example, if minimum log priority in libbase remained at its
default, but a tag was specifically opted into DEBUG logs via
log.tag.<tag>, libbase would not print this log.
2) liblog ignores libbase's minimum log priority. For example if a
process called SetMinimumLogPriority(WARNING) but used a library
that logged via liblog's ALOGI macro, that log would still be
printed even though the process intends on filtering out those INFO
messages.
With this change:
1) If both a minimum log priority and a priority through log.tag.<tag>
are set, then the lower of the two values is used.
2) If only one or the other is set, then that value is used. This
fixes the two issues described above.
3) If neither of these values are set, then the default of using INFO
is unchanged.
Bug: 116329414
Bug: 119867234
Test: libbase and liblog minimum log priority tests
Change-Id: Icb49b30b9d93bf797470e23730ae9e537931bb6c
libbase is copied into each APEX module which requires it, meaning
that there may be multiple instances of libbase running within a
single process with their own copy of libbase's globals. This means
that SetLogger() and SetAborter() will only impact logs from the
instance of libbase that calls it. This change moves this state to
liblog, since it will only ever have one instance in a single
process.
One major side-effect here is that now both ALOGE style and LOG(...)
style logs will be handled through the same logger function. For
example, a logger specified through libbase's SetLogger() will now see
logs sent to liblog through ALOGE(). This is intended behavior.
A second side-effect is that libbase's stderr logger is used for all
host logging now. It's simply a better logging default than the
fake_log_device logger in liblog currently and makes ALOGE and
LOG(...) logs on host follow the same format.
Bug: 119867234
Test: libbase and liblog unit tests; logging works
Change-Id: Ib52cbfb4e43749e50910ed19a993dffae19ace86
The current version requires callers to supply a string with 32 extra
bytes for liblog to internally prepend "setPruneList ", and to have
enough space to parse logd's return string. That is an unacceptable
requirement on callers.
This change removes that requirement by having liblog allocate the
needed std::string in any case.
It also stops writing back the 'success' or 'Invalid' string to the
caller's buffer, since that is redundant as well.
Test: changing prune settings works.
Change-Id: Ic0f03a229f0b9a77d03adcb91288370c3bd42903
We don't need to be so strict about this comparison. It's possible
that logd will extend the message that it passes to readers in the
future, and since we have a hdr_size parameter it can do so in a
backwards compatible way, as long as we loosen this restriction.
This keeps a sane upper bound that the hdr_size cannot be larger than
the log message itself.
Test: logcat, liblog-unit-tests
Change-Id: I8a6bea2a2d6e3315d998c51c1029e466ff06b45f
logger_entry and logger_entry_v2 were used for the kernel logger,
which we have long since deprecated. logger_entry_v3 is the same as
logger_entry_v4 without a uid field, so it is trivially removable,
especially since we're now always providing uids in log messages.
liblog and logd already get updated in sync with each other, so we
have no reason for backwards compatibility with their format.
Test: build, unit tests
Change-Id: I27c90609f28c8d826e5614fdb3fe59bde22b5042
1) We don't need two copies of log_id_t
2) We don't need misleading sizeof_log_id_t or typeof_log_id_t macros
3) logd should use android_log_header_t explicitly for its recv buffer
size
4) Following on from b/129272512, we're settling that returning
LOG_ID_MAX is an acceptable return value from
android_name_to_log_id().
Bug: 129272512
Test: build, liblog, logcat unit tests
Change-Id: I67fb964a4a0ae9cb6e1514ca110e47e00dfcfa9a
The log_time struct satisfies all of the requirements for an
implicitly created copy constructor to be present, so not defining one
here does not have any real effect.
We don't want to delete the copy constructor for the rationale given
either; modern C++ favors passing small types by value instead of by
reference as the compiler has more opportunity for optimization in
that case. That's especially true here, where the size of this struct
is the size of a pointer on 64 bit systems.
Test: the copy constructor exists for log_time
Change-Id: Id314ca7729f4b1ca02adb6c7f0ae759b22be2a5c
Per jmgao@, we still need to worry about unaligned integer accesses.
In any case, we already have the packed structs for all of the
unaligned data that we're reading, so this change favors using those
packed structs.
Bug: 142256213
Test: x86,arm32,arm64 liblog-unit-tests
Change-Id: I21fc629eac49895d03b5b31daa4cc494b0c4c230
There are no users; future versions will need to be more generic to
support the libbase style Logger/Aborter options.
Test: build, liblog-unit-tests
Change-Id: Ia4571cd39d3e499f18306920ecbf40ea8878fb81
There are no users of the liblog stderr logger, but 66 users of
android::base::StderrLogger. We'll prefer that format and work to
merge it into liblog.
Test: liblog-unit-tests
Change-Id: Ifad24b27ac0f51379b925f6644caa1f6f3d9ad81
