This Android OS code looks, to me, like it’s been written by folk who absolutely believe Enums don’t have a place in code, but a 300+ line switch/case statement is just fine. Using Enums and .name() would remove the need for that horror.

Even using reflection would have been nicer. Scanning the class’s static members and printing the name if there was a match in values would be less cognative load that this beast in my view. I wonder if there’s a typo in that code already.

The current test code, verifies some of the values are right. If you look at the test code you’ll see values such as “ELECTRONIC_TOLL_COLLECTION_CARD_STATUS” are in the toString() method, but not in the test code.

Unfortunately, at this point, I don’t have any confidence that an AOSP patch submission to address some of this stuff would be a valuable use of my time. I’ve seen to many AOSP CLs get ignored to think solving this externally is a viable option.

I thought I’d take a look at doing something a little less reader unfriendly. Unfortunately the test is part of the CTS test suite, which requires a device running the firmware, and life is too short to go round that loop for something which is unlikely to get accepted.

If you’re interested in where my head was at. Here’s a rough diff which will make the mega-switch statement obsolete, and syncs itself with any newly added values;

I also found that the switch statement actually has three tests in two different places; In the library repo and in the CTS tests, and yes, the values checked the those two locations has already diverged and are different.


After 15 revisions, a ridiculous number of TreeHugger runs (and subsequent copy pasta of TH errors to a public place), and the discovery that ErrorProne runs on internally but not on the AOSP gerrit, the patch I created has landed, which means one less piece of nasty code for folk to wrestle with in the future.