Too many vendors assume that this is included, and it's not worth the
effort to clean up.
Bug: 165825252
Test: build
Change-Id: Ib99f0de4aac64134c21c0ee09f7ea576ebd0fe9e
Too many vendors assume that this is included, and it's not worth the
effort to clean up.
Bug: 165825252
Test: build
Change-Id: I42fb32be7e5e3201dfc5c58734e3ef5b9251faf1
android_filesystem_config.h is found since system/core/include is on
the include path for all projects and contains a symlink to the real
android_filesystem_config.h. This is fragile and the below bug seeks
to remove this symlink and have users correctly depend on
libcutils_headers.
Bug: 165825252
Test: build
Change-Id: I1aad6a2e8fbe87635e97b0ac1be3414403353382
There are libraries built with the NDK but bundled with the platform
that were otherwise directly including the header path. It's better
for them to include liblog_headers instead.
Test: build
Change-Id: Icca3684ba5b2539789d30de9df840da4ade0dc67
This was introduced years ago but never gained any users.
Test: build
Merged-In: Id2deb6de1839f995970c6350a1970a872f0b51cf
Change-Id: Id2deb6de1839f995970c6350a1970a872f0b51cf
This reverts commit 4af349b072.
Reason for revert: post submit test logs too much fails after this
Bug: 163611679
Change-Id: If9939f3c9864dad67536d0c5481f662b9d07c58e
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 uses a non-blocking socket for sending messages to logd as a
performance/reliability trade-off, favoring not blocking processes
when they log over reliably tracking all logs.
This change asserts that the above is the wrong trade-off: that log
relability is more important than slight delays when logging. Further
points to consider:
1) The new logd implementation without chatty has lower latency and
less variance in its ::Log() function.
2) liblog also writes to /dev/pmsg0 and this call is already blocking.
3) Logging is already expensive and excess spam must be eliminated
regardless.
Bug: 151654749
Bug: 155922578
Bug: 160314220
Test: No messages are dropped by this socket
Change-Id: I163b7d51aa73a10978850f1868cb9fc4bf9ead1b
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
Add a 2s timeout for logd command socket operations:
android_logger_clear
android_logger_get_log_readable_size
android_logger_get_log_size
android_logger_set_log_size
android_logger_get_statistics
android_logger_get_prune_list
android_logger_set_prune_list
That correspond to:
logcat -c
logcat -g
logcat -G
logcat -S
logcat -p
logcat -P
These operations should return immediately in typical circumstances,
but if logd is stuck, they would otherwise block indefinitely. This
allows the commands to gracefully timeout instead.
Test: kill -s STOP `pidof logd`; logcat -g (and other options)
times out appropriately
Test: logcat -g (and other options) work successfully otherwise
Change-Id: I6c4671a9b3daa4a454c0a14ae7d0b7d3b08be77a
Don't cache the property size values since they're only queried at the
start of logd and only once during dumpstate. Initializing
SerializedLogBuffer, which includes all of the logd queries, takes
under 100us without the cache, certainly fast enough that this cache
is unneeded.
Move these functions to their own file in preparation for removing
them from liblog.
Test: log sizes set appropriately
Change-Id: I15a2fd687dcffb4eab2f22ee0825ca86e40cdba3
Apparently these tests are run in parallel, which causes errors since
they use the same log tag. Use unique log tags based on pid to fix
this.
Also re-enable the previously disabled tests.
Bug: 162669552
Test: run these tests 100x+ and see that they no longer fail
Change-Id: Ib20d638e5e559bca23adec479a5dcf64075e376e
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
__android_logger_property_get_bool() has a clunky API and doesn't
belong in liblog, since a vast majority of liblog users will never
query this property.
Specifically
1) Replace with GetBoolProperty() when completely equivalent.
2) Remove checking if property values are 'eng' or 'svelte', since
there's no evidence that those values were ever used.
3) Remove checking 'persist.logd.statistics' and 'ro.logd.statistics',
since there's no evidence that those values were ever used.
4) Set ro.logd.kernel explicitly, so other processes don't need to
replicate the defaults that logd uses.
Test: build
Change-Id: I7c37af64ba7754e839185f46da66bf077f09d9c3
In testing, I saw that the 'main' and 'events' log buffers were set to
incorrect sizes when they were intended to be >= 4MB. The bug is
tracked down to an invalid line in
__android_logger_valid_buffer_size():
/* maximum memory impact a somewhat arbitrary ~3% */
pages = (pages + 31) / 32;
There are two issues with this line:
1) That is not the right calculation for 3%.
2) `pages` is a static variable, so it repeatedly is decremented until
reaching 1.
The consequence is that this function gives invalid results for the
first few calls, then returns true as long as the input is between
LOG_BUFFER_MIN_SIZE and LOG_BUFFER_MAX_SIZE. That check is enough, so
the rest of this logic is removed.
Test: buffers are set to the right sizes.
Change-Id: I4d19b1d0fdbd83843d2d61a484ac083d571ef37b
Previously, colors were specified from the 216 additional colors, which
typically specify an exact RGB color value. Instead, use escape codes
for standard colors (default foreground, red, green, yellow, etc.),
which are commonly adjusted by terminal emulators user preferences.
Bug: 159503129
Test: adb logcat --format color
Test: atest liblog
Change-Id: I0b10a70a76a29d896d04d6c49e716b09cb09b19a
d3ecc66b9c "liblog: support extended logger_entry headers" removed
the logger_entry::msg variable and instead uses hdr_size as an offset
from logger_entry to where the message starts in parent log_msg
buffer.
In pmsg, hdr_size is not recorded and therefore uninitialized when it
was referenced, causing corruption when reading last logcat. This
change uses sizeof(log_msg->entry) instead.
Bug: 158263230
Test: last logcat works
Change-Id: Ic01e73bf4d8ba8419cc770138565aa1210a6078b
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
Some tests require root to be run, so we require_root to run all of
them.
Test: tests pass as root
Change-Id: I5b3ca4f08e41f16e81c5d5995043ab55d379a882
Bug: 65062446
Test: multi_connect_dgram_socket is skipped for non-root
Test: multi_connect_dgram_socket passes for root
Change-Id: I610bed5987580e0c5a01952efc2e32e7d8cdf9b4
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
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
For now setting min_sdk_version doesn't change build outputs.
But build-time checks will be added soon.
Bug: 152655956
Test: m
Change-Id: If4ff1fbc31e5be3f5611a4713ae4032aba4ee5f2
`@{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
There are no libbase users that require thread safety for SetLogger,
SetAborter, or SetDefaultTag and the equivalent liblog symbols are
unreleased, thus have effectively no users.
It is hard to imagine a scenario where a user would need to use these
functions in a multi-threaded program, and it is unreasonable for all
users to pay for thread safety for a vast minority of potential
scenarios. Thread safety implies less efficiency and necessarily means
that these functions are neither fork safe nor async-signal safe, and
we do have users who depend on those characteristics.
It is always possible for users of the non-thread safe versions of
these functions to build thread safe versions on top of them. For
example, if a user needs a thread safe SetLogger(), they can use the
non-thread safe SetLogger at the start of their program to register a
logger that has its own lock and pointer to a logger function.
Bug: 119867234
Test: logging unit tests
Change-Id: I8afffec1a6957d3bda95502a4c59493e0c5049ce
Dan Shi