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
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
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
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
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
This is renamed to ro.organization_owned to cover the extended
usage now that there is a new management mode for fully-managed
organization owned devices: organization-owned managed profile.
A device is considered fully-managed if there is a device owner
or an organization-owned managed profile.
Test: atest liblog-unit-tests
Test: atest propertyinfoserializer_tests
Bug: 148437300
Change-Id: Iaa8ea246c973732526abc1da5b307af8bce1a0af
This is now dead code as __android_log_stderr_logger() has superseded it.
Bug: 147496863
Test: build
Change-Id: Ibdea2961ec4fc093bf9e35581dc1c46db2cff06a
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
Tom Cherry