Background: I have tried several times to upstream a patch from the Chromecast fork, and each time, have found it difficult to cleanly add the new logic. The new feature in question is a followup to internal bug b/30515215, where it turned out that the conservative estimate for MediaFormat.KEY_MAX_WIDTH and MediaFormat.KEY_MAX_HEIGHT was problematic for some decoder implementations on Android TV. I could submit a hack that jams in the new feature in the conventional way, with lots of plumbing, but it would probably not be well-received in review, or worse, would be accepted without complaint and allowed to increase the entropy of MediaCodecBridge even further. Something as simple as plumbing in a strategy class for determining these keys turns out to be hard because of the convoluted setup logic for MediaCodecBridge. This convoluted setup logic includes:

1) Several JNI setter methods that are only supposed to be called before start() (though they are not explicitly documented as such)
2) Various static and non-static Java helper methods that set keys on a MediaFormat. Some are invoked in Java as side effects of other Java methods, and others are called from native code through JNI.
3) Parameters that are redundant depending on the values of other parameters (such as the "direction" parameter in MediaCodecBridge#create()).
4) Nested if statements that are hard to follow.

This makes it really hard to test, and therefore hard to know if a change broke any of the many combinations of platform exceptions, decoder types, and other parameters. There are unittests for MediaCodecBridgeImpl in native code, but it is hard to tell what Java logic is covered.

MediaCodecBridge, in Java and C++, can be refactored to better fit the single-responsibility principle. Here are some ideas on how to do this:

1) Move construction/configuration logic out of MediaCodecBridge.java and into a factory/builder class. The constructor of MediaCodecBridge can just take an already-configured MediaCodec instance
2) Split MediaCodecUtil into multiple helper classes to disambiguate between helper methods for native code (through media_codec_util.cc) and helper methods for Java code.
3) Extract concerns of configuring the MediaFormat and MediaCodec and encapsulate them in methods and classes that don't take redundant arguments.
4) Encapsulate SDK version checks underneath delegate classes or some other means, to make it less necessary to constantly keep track of what OS version we're running on.

As a result, MediaCodecBridge and MediaCodecUtil should be more readable and testable. JNI classes (i.e. the pair of C++ and Java classes with the same name) should be made as small as possible, and can be tested in native code, and helper methods on the Java side can be tested with JUnit tests that can easily mock dependencies. This would allow us to, for instance, test logic that depends on hard-coded whitelists, like the Build.MODEL check in MediaCodecBridge#maybeSetMaxInputSize(), in any JVM, providing much better test coverage.