Fix read range computation for some corner cases in redaction ranges
1. Fixed read range computation for redaction range of zero size. For
example, a redaction range of [10, 10). There is nothing to redact here.
Some images can have a redaction range like this.
Previously, computing read ranges for a redaction range like this would
end up in an infinite while loop with getReadRanges() adding a read
range of [10, 0] to the vector in every iteration of while loop. Hence
leading to high memory consumption, which results in MediaProvider
crashing because of lowmemorykiller.
This CL removes these redaction ranges of zero size from
redaction_ranges_ vector.
2. Fixed read range computation for redaction ranges where read offset
or read_end overlaps with start or end of the redaction range.
These kind of reads will be very rare where app would read with offset
that matches exactly with redaction range start/end. But, when it
happens, we might end up in an infinite loop or read ranges with
negative values.
Changed getReadRanges to compute read ranges by collecting sorted
redaction ranges within the read range and finiding the right
index for read_start and read_end.
Added new tests to verify these corner cases in redaction ranges.
Bug: 170779687
Bug: 170357171
Test: atest RedactionInfoTest
Change-Id: I1e62c4b31083ec07e72df066b1bd985289f01783
2 files changed