`@{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
- Zero initialize log_time instances by default
- Disable implicit conversions by making constructors explicit
- Explicitly initialize to EPOCH in most places
- Change sniffTime() to avoid in-place modification of a log_time
I stopped here, but we could consider following up with a more invasive
change to make log_time instances immutable and perhaps also remove the
default constructor to force explicit initialization to EPOCH.
Test: atest libbase_test netd_unit_test
Change-Id: I67e716ef74adaaf40ab2c6e2e0dddb8d309bc7ca
readv() isn't used by anyone, writev() has one easily replaced user.
uio.h can be left as a private header for windows compatibility with
struct iovec.
Test: build
Change-Id: I33d4c6bdee6fd818271f78ae06abdd2aa09430f2
After a few years of being available, there only ended up being one
user of this, so it is clear that logd's duplicate message mechanism
is the favored solution.
The one user of this rate limiting is questionable as is, since due to
the nature of storaged, the mainloop only runs once per minute by
default as is, so there is essentially nothing to be gained by rate
limiting any further.
Test: build
Change-Id: I0610d11efda1ce8b581b939bad11ff295cb2daa6
These headers are platforms headers, so by definition they'll never be
compiled for a platform less than the current one.
Test: build
Change-Id: Ic1c1535b935929d713806faf17fbf9cd82275329
