subjective, optional: There could be a guard clause here and in PlatformPlugin.java#getSystemGestureExclusionRects to reduce nesting.

subjective, optional: I think it would be a little easier to read if this translating was split out into a helper method, like the decode ones.

In javadocs, it's ideal to express the value and/or purpose of a method rather than a purely technical statement. While this javadoc may be technically accurate, I think it's unlikely that this informs the reader of what is happening and why. Would you mind framing the javadoc in terms of why this method exists, and what encoding is taking place? You might consider mentioning when this method is expected to be called, why it is called, what encoding is taking place and why, and what is likely to happen after this. You don't necessarily need all of that, but that's how I would recommend approaching method docs.

Please rename test as mentioned in the other PR

Please clearly identify the areas of this test that setup the test, execute the behavior under test, and verify the expected results.

In tests it is often preferable to avoid using variables for verification purposes. Developers will need to read every line of the test to understand what the expected values are. It essentially moves logic into the test, when a test should only include setup and expectations (or as close to that as possible). I would recommend putting the literal values in this map, rather than the variables.

Sounds good. I was thinking it would be more clear to have both values created from the same variable so that developers know that the API output values should match the parsed values

Are these really the "expected" exclusion rects? This looks to me like fakeExclusionRects...

Yeah, in my mind, I saw it as "these are the exclusion rects that we expect returned in this test". I'll update it to fakeExclusionRects, since that is clearer.

I have the same question here about ResultsMock as the other PR. Do we need to define our own class if we're using mock()? Can Mockito just mock() the interface, instead?

Yeah, I had a misunderstanding of how Mockito worked when I wrote the original tests. I've removed them in #11804

One stylistic recommendation that I have is to define the input and output up here at the top during the setup phase. It can often help readability. So above this comment you have the fake input (I think). Down at the bottom of the test you assemble the expected output. You might consider defining the expected output right here, just below the fake input. This allows readers to immediately see the fake input and expected output, together, without reading the rest of the test.

Please clearly separate the test setup from the behavior under test from the verification.

I'm not sure how these tests overlap with the other PR, but can we separate the behavior under test from the verification? If it's already done in the other PR, then no worries.

I think I mistakenly made this variable name update to this PR instead of the more relevant one. Should I move it over there instead? The other PR addresses separating the behavior under test from verification.

Either place is fine as long as the right change is made :)