Как Android определяет, какой буфер использовать для сообщений logcat?

Question

Как Android определяет, какой буфер использовать для сообщений logcat?

По стандарту Android logcat Система имеет 4 разных кольцевых буфера:

main
system
radio
events

# and alias & groups:
all      -- all available logs
default  -- main
crash    -- n/a

Однако на AOS 6+, похоже, есть и другие буферы:

# logcat --help
...
-b <buffer>     Request alternate ring buffer, 'main', 'system', 'radio',
'events', 'crash' or 'all'. Multiple -b parameters are
allowed and results are interleaved. The default is
-b main -b system -b crash.
...

и андроид logcat.cpp Исходный код, кажется, подразумевает, что есть еще другие, такие как:

security
kernel

Обычно в Java-приложениях, способ поместить сообщение в main logcat использует: Log.i(TAG, msg),

Итак, вопрос:
Как Android определяет, какой буфер использовать для различных сообщений logcat?

(Конкретные ссылки на исходный код AOS будут особенно оценены.)

Тогда естественным последующим вопросом будет то, как вы можете увидеть или включить другого скрытый буферы?

5

android buffer c++java logcat

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Я не люблю отвечать на свои вопросы, но я нашел несколько ответов, а также некоторые очень хорошие заметки.

Во-первых, различные исходные файлы, связанные с журналами (Java), расположены в:
platform_frameworks_base / ядро / Java / Android / Util / И в:
platform_frameworks_base / телефония / Java / Android / телефония /.

EventLog.java   # EVENT Log:  These diagnostic events are for system integrators, not application authors.
Log.java        # MAIN Log:   Where user app logcat goes from:  Log.v() Log.d() Log.i() Log.w() and Log.e()
Slog.java       # SYSTEM Log: Primarily for use by coding running within the system process.
Rlog.java       # RADIO Log:  All radio, wifi, bluetooth etc. related logs. Also scrubs personal info from appearing in logs.

со связанными файлами:

EventLogTags.java       # Deprecated! (Use EventLog)
LocalLog.java           # log(), dump(), reverseDump(), ReadOnlyLocalLog()
LogPrinter.java         #  decides what buffer to print to: LOG_ID_<buffer_name>
LogWriter.java          #  decides priority and TAG
TimingLogger.java       # A utility class to help log timings splits throughout a method call.

Буферы журнала определены в Log.java от:

public static final int LOG_ID_MAIN = 0;
public static final int LOG_ID_RADIO = 1;
public static final int LOG_ID_EVENTS = 2;
public static final int LOG_ID_SYSTEM = 3;
public static final int LOG_ID_CRASH = 4;

В ОС ведение журнала регулируется свойствами:

setprop log.tag.<YOUR_LOG_TAG> <LEVEL>

и в файле /data/local.prop от:

log.tag.<YOUR_LOG_TAG>=<LEVEL>

Кроме того, я нашел интересные комментарии.

ГЛАВНЫЙ журнал:

Порядок с точки зрения многословия, от наименьшего к большинству,
ОШИБКА, ПРЕДУПРЕЖДЕНИЕ, ИНФОРМАЦИЯ, ОТЛАДКА, VERBOSE. Подробный никогда не должен быть скомпилирован
в приложение, кроме как во время разработки. Журналы отладки компилируются
в но раздели во время выполнения. Журналы ошибок, предупреждений и информации всегда сохраняются.

Совет: Не забывайте, что когда вы делаете звонок, как
Log.v (TAG, "index =" + i);
что при создании строки для передачи в Log.d компилятор использует
StringBuilder и происходит как минимум три выделения: StringBuilder
сам по себе, буфер и объект String. Реально, есть также
выделение и копирование другого буфера и еще большее давление на gc.
Это означает, что если ваше сообщение журнала отфильтровано, вы можете делать
значительная работа и влечет за собой значительные накладные расходы.

СОБЫТИЕ журнал:

Доступ к записи о событиях диагностики системы. Системные диагностические события
используется для записи определенных событий системного уровня (таких как сборка мусора,
состояние менеджера активности, системная защита и другая активность низкого уровня),
которые могут быть автоматически собраны и проанализированы во время разработки системы.

Это не основной журнал отладки «logcat» ({@link android.util.Log})!
Эти диагностические события предназначены для системных интеграторов, а не для авторов приложений.

В событиях используются целочисленные коды тегов, соответствующие / system / etc / event-log-tags.
Они несут полезную нагрузку одного или нескольких значений типа int, long или String.
Файл event-log-tags определяет содержимое полезной нагрузки для каждого типа кода.

4