* 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
1) Fix up the host tests for new logging format
2) Add recently added tests to the host test
3) Ensure that properties are cleaned up by liblog-unit-tests
Test: unit tests
Change-Id: I303549aecc26d11ec87e59d48758ced4c198b72c
Do not write to binary buffers, this was already done for logd,
but wasn't explicitly done for other loggers, so do that too.
Test: unit tests
Change-Id: Ia36e0d2e1b6c833780239a5ef459abea99bc4a1f
This is now dead code as __android_log_stderr_logger() has superseded it.
Bug: 147496863
Test: build
Change-Id: Ibdea2961ec4fc093bf9e35581dc1c46db2cff06a
Some recent changes can have these logging functions potentially set
errno. This change places android::base::ErrnoRestorer at the entry
point of the public functions where we want to guarantee errno is
restored to ensure this will not happen again.
Test: build
Change-Id: Iab4170ab16b9c7301474a509ee42d38b370b91a4
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
__BEGIN_DECLS and __END_DECLS are all that are left, and I can compile
with using normal <sys/cdefs.h>, so hopefully we can remove this at
last.
Test: build
Change-Id: I6df7ef0da027bb91c98806e0f9661d7416ebaa5d
Cleanup the headers; we really don't want to encourage any more
cutils/list.h usage...
Remove __android_log_uid() since the only remaining users are built
for device, so they can just use getuid() directly.
Test: build
Change-Id: I62be2c1e43d83807deaa9342afcc72459947cf15
Marks this CTS test module as supporting secondary_user, meaning that
the tests are eligible to be run from a regular Android user other
than the system user (i.e. other than user 0).
Note that 'user' here refers to the concept of users in Android
Multiuser; it is NOT the same as a uid.
Bug: 141773058
Test: module passed with secondary_user params
(--enable-optional-parameterization --module-parameter secondary_user)
Change-Id: Iaff9fb5d21473129ce3a802d179db474f7c763bc
Some objects may log when they're destructed, so don't destroy the
global std::mutex in fake_log_device.cpp.
Test: AAPT works with a log in VectorImpl::finish_vector()
Change-Id: Ie5a0ac9fc4e6a137e9516059a831e499d55d5ddb
Remove the transport available and open functions since the writers
are able to manage their own state. Remove the initialization dance
with write_to_log, since it is unneeded once this is removed as well.
Remove the global lock around the close() functions as correct locking
has been added to the writers in a previous change.
Test: logging works, liblog-unit-tests
Change-Id: If7fa11e773763d0b5fcb2e696ad1c88ff4a4cfdf
The current system of using atomics isn't thread safe and may result
in doubly closing FDs or closing actively used FDs. The safest way to
do this is to use a rwlock, which should not have a much higher
overhead than the atomics do, as a vast majority of the time, there
will not be writers.
This moves us further away from using the transport interface, which
will be removed. Each writer should be self contained, without a
separate open or available function.
Also, keep the pmsg fd open if it is opened by
__android_log_pmsg_file_write(). This fd was closed due to issues
with zygote, but it looks like it is only called by recovery now, so
there is no reason to close this fd at the end of that function.
Test: logging works, liblog-unit-tests
Change-Id: I345c9a5d18c55b11a280c8362df854784abf46fd
This code was introduced to help performance by skipping sending these
messages to logd when logd would later drop them. However it has
multiple flaws:
1) Event logs aren't super common and non-loggable event logs are even
less common, so it would be a trivial benefit if any.
2) This code is not particularly safe as written, which is even
acknowledged in the comments.
3) This forces processes that write event logs to allocate a rather
sizable amount of memory.
Therefore, it's better to simply remove this and let logd drop these
messages when it receives them.
Bug: 139705697
Test: logging works, liblog-unit-tests
Change-Id: Ide01574112e173d4922137b3d3868cf8c2c09086
This still fakes the long removed /dev/log devices, whereas it only
needs to print to stderr, so simplify that code.
Use std::mutex now that it is C++ to easy portability concerns.
Use the proper liblog headers for formatting information instead of
hardcoding a copy.
Test: liblog-host unit test
Change-Id: I310a6e7ad939960300eafa729cbfc535c5ced445
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
This is unneeded, since we're already checking the length returned by
recv() and log_msg that is read for validity.
It costs ~4% of CPU with `logcat -s` and ~2% of CPU when running
simpleperf for 1 second on walleye on master.
Bug: 144311420
Test: logcat works, simpleperf doesn't show memset() costing as much.
Change-Id: I986e7e96518774034340f1b1201a2071a904e3bb
This is simplified down to the point there are only two branches that
need to be made, so remove the rest of the transport structs and
simply branch where needed.
Test: liblog-unit-tests
Change-Id: Ic82e7e70eb7b4e40b381a4d8066629c5b7d4f827
Shifting a signed 32-bit value by 31 bits is implementation-
defined behavior. So we change to an unsigned value for our
shift by 31 bits, and go ahead and change the others to
unsigned for consistency.
Test: TreeHugger
Change-Id: Ib98f9b1e468d28dafd09e86273bf76beb1ea1fa5
There are a set of functions, such as android_logger_get_log_size()
and android_logger_get_prune_list() that talk to the logd command
socket to perform their activities. There's a transport abstraction
layer that handles these symbols to optionally route them to other
transports, originally designed for pstore or local logger; however
these functions fundamentally only make sense for logd.
Ideally, these functions would be removed and new functions would be
added that do not depend on struct logger_list or struct logger and
more clearly indicate that they only work with logd. For example:
android_logger_get_size(struct logger*) could be
logd_get_buffer_size(log_id_t log_id). We would remove the need to
'open' the struct logger and make it clear that it only operates on
logd.
Since liblog is an llndk library however, we cannot change or remove
these symbols. Since these symbols are not frequently used, it seems
acceptable to keep them as is and not introduce improved versions.
We, however, do want to simplify the code that handles them and this
change removes the transport abstraction layer that handles them.
They retain the behavior that unless the struct logger_list was opened
for logd, that the functions return -EINVAL.
The one exception to this is android_logger_clear(). If the struct
logger provided to this function was opened from a struct logger_list
that used pstore for its mode argument, this function will clear the
entire pstore log. This function does not respect the 'logId'
parameter of the struct logger, since that would not be possible.
This change removes this android_logger_clear() behavior and makes it
strictly for logd, for symmetry with the rest of the functions and due
to the lack of clarity regarding the 'logId' parameter of its input.
The only caller of this function, logcat, will clear pstore directly.
struct logger was built to encapsulate the information needed to
connect to a logger device from the old kernel logger. Now that we
only support reading from pstore and from logd, there is much less
information needed to be captured. Specifically, we only need to know
the log_id and whether or not it was opened as part of a pstore or
logd 'list'.
Test: liblog-unit-test
Test: logcat -c/-g/-G/-p/-P/-S work
Test: logcat -c works with -L
Test: logcat -g/-G/-p/-P/-S continue to fail with -L
Change-Id: I2c549b6f8539de94510e223949ab209ecc40e2d0
We used to do this, but it got lost while refactoring this code.
Bug: 144311420
Test: we see "unexpected EOF!" instead of "unexpected length" from logcat
Change-Id: I7858d0a774a9eac63e5547ee67e85ef8fb0c682d
There's a lot of unnecessary boilerplate around these opaque types,
and this change simplifies it.
Test: liblog-unit-tests
Change-Id: I0c4e133037fd5f04157ac22175181a6a496e18c4
The APIs that are tagged with # vndk are actually for LLNDK libraries.
Although LLNDK is part of VNDK, calling those APIs 'vndk' has given
users a wrong perception that the APIs don't need to be kept stable
because that's the norm for most of the VNDK libraries that are not
LLNDK.
In order to eliminate the misunderstanding, rename the tag to 'llndk' so
that people introducing new such API will realize what they are signing
themselves up for.
Bug: 143765505
Test: m
Merged-In: Iae2acdf1ff4097a64a5c6280797c66abb1d5a5e6
(cherry picked from commit 0e957b82c8)
Change-Id: Iae2acdf1ff4097a64a5c6280797c66abb1d5a5e6
This protocol documentation is spread out among various functions
where it is implemented. This change makes a single
README.protocol.md file with a high level overview, referencing the
struct names where useful.
Test: n/a
Change-Id: I83c9f484352b489b4a20cce241d92413f780f9ec
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
I'm about to make a bunch of changes that are safe for backwards
compatibility, but would otherwise flag the checker, so it's time to
temporarily disable it.
Test: CLs pass despite making header changes
Change-Id: Ibc2d4ae51fb8e6125b9117ccd92bf821db945e67
This reverts commit 5f8162b086.
Reason for revert: Turns out they're being used.
Merged-In: Iad9010190c7a4140b69dc553df5debdd88dcf81a
Change-Id: Iad9010190c7a4140b69dc553df5debdd88dcf81a
These functions and headers were all mistakenly added to the vndk.
They should not be used by vendors.
Test: these symbols do not appear in vendor libraries
Merged-In: I03919b437c2d9f0e573b7a6b40249ed12fe874b9
Change-Id: I03919b437c2d9f0e573b7a6b40249ed12fe874b9
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
There's no point in client side security checks in this library. If a
process has access to these files, then they'll be able to do any of
these operations themselves.
Test: liblog unit tests
Change-Id: I75d4e1509eb8ff0ac4579f820a8968f4f5ad4e06
