Запретить определенные сторонние приложения и системные сообщения от входа в LogCat

Question

Есть ли способ заставить тэги определенных системных / сторонних приложений никогда не регистрироваться (или не показываться) в Logcat инструмента DDMS?

Сценарий:

Тестеры QA моей компании и разработчики Android в значительной степени полагаются на журналы в LogCat для сортировки нашего приложения. Есть известная проблема, о которой я много читал в DDMS и Eclipse, когда после того, как написано так много сообщений журнала (~ 10 000), пользовательский интерфейс будет отображать только 1-5 строк и ссылается сам, когда пишутся новые журналы ( http://code.google.com/p/android/issues/detail?id=2752). Обходной путь для этого состоит в том, чтобы очистить журналы, как только мы достигнем этой точки, и затем мы сможем снова просмотреть все журналы.

К сожалению, при тестировании на некоторых устройствах, таких как Thunderbolt или G2X, другие приложения или системные сообщения будут спамить логи. Например, на моем G2X я получаю эти сообщения каждые 3 секунды при подключении к Wi-Fi:

09-08 15:20:11.885: DEBUG/StatusBarPolicy(1270): onSignalStrengthsChanged : SignalStrength: 21 -1 -1 -1 -1 -1 -1 gsm
09-08 15:20:11.895: ERROR/PhoneInterfaceManager(2507): getNetworkType = radiotech =  11
09-08 15:20:11.895: ERROR/PhoneInterfaceManager(2507): getNetworkType =  NETWORK_TYPE_HSPA
09-08 15:20:12.605: DEBUG/WifiStateTracker(1106): WiFiStatetracker.java handleMessage event: 8

На Thunderbolt один из наших инженеров QA получал следующий блок сообщений один раз каждые 0,3 секунды, ссылаясь на GPS:

09-08 14:50:30.950: INFO/RPC(1574): 3000008c:00050000 reading data.
09-08 14:50:30.950: INFO/RPC(1574): 3000008c:00050000 received CALL.
09-08 14:50:30.950: INFO/RPC(1574): 3000008c:00050000 waking up callback thread.
09-08 14:50:30.950: INFO/RPC(1574): 3000008c:00050000 dispatching RPC call (XID 2711,     xdr 0x4f66a8) for callback client 3100008c:00050001.
09-08 14:50:30.950: INFO/RPC(1574): 3000008c:00050000 cloning XDR for callback client 3100008c:00050001.
09-08 14:50:30.950: INFO/RPC(1574): CLONED fd 119 --> 107
09-08 14:50:30.950: INFO/RPC(1574): 3000008c:00050000 marking input buffer as free.
09-08 14:50:30.950: INFO/RPC(1574): reading on fd 107 for 3100008c:327681
09-08 14:50:30.950: INFO/RPC(1574): START: SVC DISPATCH 3100008c:00050001 --> 00000001
09-08 14:50:30.950: INFO/RPC(1574): 3100008c:327681 sending RPC reply (XID 2711)
09-08 14:50:30.950: INFO/RPC(1574): DONE: SVC DISPATCH 3100008c:00050001 --> 00000001
09-08 14:50:30.950: INFO/RPC(1574): CLOSING fd 107

Это приведет к тому, что DDMS перейдет в состояние полного буфера менее чем за минуту, быстрее, чем наш инженер по обеспечению качества сможет выполнить их тест и проверить журналы нашего приложения.

Теперь я хотел бы, чтобы эти сообщения вообще не отображались, чтобы мы не достигли этого лимита буфера.

Наше приложение использует теги серьезности и фильтрации. Однако в DDMS, когда мы создаем новое окно с вкладками с серьезностью / фильтром, который мы хотим просмотреть, поскольку вкладка «Журнал по умолчанию» получает все журналы из любого места, мы достигаем этого предела буфера. Так что обходной путь с фильтром / серьезностью, похоже, не работает.

Известные обходные пути:

Обычно мы пытаемся отключить службу / приложение, которое рассылает спам, если это возможно. Однако, если мы хотим проверить функциональность GPS, мы достигаем предела буфера.

Возможные решения:

Общее ПО, приведенное ниже, дало мне хорошее представление об альтернативных путях.

1. Создайте свой собственный пользовательский интерфейс, и тогда я не буду использовать этот предел буфера пользовательского интерфейса, а пользовательский интерфейс DDMS автоматически очистится.
2. Возможно, люди будут использовать все командную строку и явно фильтровать (убирайтесь из пользовательского интерфейса, поскольку проблема есть, а не в журналах).

Я попытаюсь обновить это, если когда-нибудь найду создание другого пользовательского интерфейса или если когда-нибудь найду серебряную пулю для этой проблемы пользовательского интерфейса DDMS, показывающую только 1-5 журналов после записи X журналов.

Answer 1

Есть ли способ заставить тэги определенных системных / сторонних приложений никогда не регистрироваться (или не показываться) в Logcat инструмента DDMS?

Как указывает @Torid, вы можетеотфильтруйте то, что показано различными способами в LogCat.Вы не можете блокировать другие приложения или ОС от регистрации, кроме написания вашей собственной прошивки.

Существует известная проблема, о которой я много читал о DDMS и Eclipse, когда после стольких сообщений журналанаписано (~ 10 000), пользовательский интерфейс будет отображать только 1-5 строк и будет ссылаться на себя всякий раз, когда записываются новые журналы.

Учитывая, что область регистрации представляет собой кольцевой буфер размером 64 КБ, устройства будут иметь более 10 КБсообщения в них большую часть времени, так как большинство сообщений короткие.

Обходной путь для этого состоит в том, чтобы очистить журналы, как только мы достигнем этой точки, и затем мы сможем снова увидеть все журналы.

Поскольку «очистка журналов» не очищает журналы (он устанавливает фильтр на основе времени в DDMS), ваша проблема связана с пользовательским интерфейсом LogCat, а не с самой регистрацией.Следуйте советам @ Torid.Вы можете использовать свой собственный пользовательский интерфейс, используя adb logcat в качестве источника данных, если вы не можете настроить фильтрацию на свое поведение.

Answer 2

Окно Eclipse LogCat имеет два набора функций (справа), которые должны помочь ...

• Вы можете фильтровать журналы по серьезности, что может скрыть многие журналы проблем из других приложений / служб.
• Ваши приложения могут использовать определенный тег TAG - например, Log.d("MyTestApp", "onCreate");, а затем настроить фильтр LogCat для этого тега. Вы по-прежнему можете видеть, что другие приложения делают (если хотите), перейдя на вкладку по умолчанию, но можете сосредоточиться на своих журналах на вкладке фильтра.