Per this copy of the Java standard book, the body of the previously-named  OBJ03-J looks like the current DCL61-J. Do not use raw types . This points to a problem: When the rule/rec belonging to a different standard is changed, its applicability to Android might also change. It would be very helpful to have an automated notification system, which would quickly provide a list of rules/recs which need re-review for applicability. Perhaps it would be useful to provide this info to readers as well, so they would know if the rule/rec has changed since the last analysis of applicability (and it would be good if they could easily check what was changed in the rule/rec since the last analysis of applicability).

Another important point you bring up: For totally new rules, (for example the new DCL61-J), which we haven't yet reviewed for applicability, those needs entries in lists/tables of Android applicability. An automated solution for identifying rules/recs which have not been analyzed for applicability would be quite helpful here, since any human-process-only solution is much more fallible.  

 Another one that used to exist (see https://books.google.com/books?id=FDun60sHwUgC&pg=PA24&dq=%22IDS00-J.+Sanitize+untrusted+data+passed+across+a+trust+boundary%22&hl=en&sa=X&ei=cys5VdK6H_WOsQTQvYDoBg&ved=0CCgQ6AEwAQ ), so same issues discussed above apply.

This advice applies: https://www.securecoding.cert.org/confluence/display/java/Input+Validation+and+Data+Sanitization

I did a quick wiki search on the previous rule title text, and found a lot of potential Java rules which inherited from the old rule. Some I checked out, and we already have analyzed those for applicability above. The others I don't have time to look at today.