tree 15996aa8a8349401c47f6edc343045d4c849b1b5
parent ad82607503d9321c6b96c24f128b2120c07938de
author Tom Cherry <tomcherry@google.com> 1590721362 -0700
committer Tom Cherry <tomcherry@google.com> 1591129608 -0700

logd: move leading_dropped logic into FlushTo()

This logic isn't generic, so it should not be in the generic
LogReaderThread.

Moreover, it's currently broken in essentially every case except when
filtering by UID, because it runs as in the filter functions before
the actual filtering by pid/etc takes place.  For example, when
filtering by pid, it's possible to get leading chatty messages.  The
newly added test was failing previously but is fixed by this change.

It's fundamentally broken in the tail case.  Take this example:
1: Normal message
2: Chatty message
3: Normal message
4: Normal message

If you read that log buffer with a tail value of 3, there are three
possible outcomes:
1) Messages #2-4, however this would include a leading chatty message,
   which is not allowed.
2) Messages #3-4, however this is only 2, not 3 messages.
3) Messages #1-4, however this is 4, more than the 3 requested
   messages.

This code chooses 2) as the correct solution, in this case, we don't
need to account for leading chatty messages when counting the total
logs in the buffer.  A test is added for this case as well.

Test: new unit test
Change-Id: Id02eb81a8e77390aba4f85aac659c6cab498dbcd