Re: OTGH
The problem here isn't the OS itself, it's the user applications that are written in the Java language that are the problem. The apps that are written in other languages are not at issue. If you port the Java language apps to a new OS, you haven the identical problem. If you replace the Java language apps on Android, you've gotten rid of the Oracle problem.
In other words, the problem isn't the Android OS, it's the apps written in the Java language (even though it's technically not "Java").
Replacing the Android OS itself would be silly, as their are loads of simple apps written in Javascript (which has no relation to Java) and loads of complex games written in C++ which are unaffected by this.
As for what Google's "plan B" might be in all this, the most straightforward one would be to replace the recommended programming language with one that doesn't duplicate any of the Java APIs. Since it's the Java library APIs and not the language itself that is in question, any language that runs on the JVM and calls the Java libraries could be equally problematic. That means that Kotlin, recently given official support from Google, could be in trouble until and unless the lawyers can give the standard library a good going over and assure everyone that there's nothing resembling Java APIs in there. Google Dart might be a safer alternative.
Once Google have picked a new recommended language, they need to figure out what to do about the existing apps written in the Java language. Perhaps they could release a program that mechanically translates Java to another language. For those developers who don't want to do that, they could let those developers negotiate their own license directly with Oracle. I suspect that given that alternative, most developers would either choose to port to the new language (using the automated tools provided by Google) or withdraw the app from the app store (for apps that were not selling well anyway).
For software developers in general though the message seems to be to avoid Java like the plague unless the customer insists on it, and in that case make sure the customer is the one bearing any and all risk (get that in writing).
The above applies to mobile phones. If Oracle are successful however, I doubt they would stop there. Traditional server systems would be at risk when Oracle casts their eyes upon them looking for excuses to squeeze licensing fees out of everyone using the JVM in some way. Alternative languages which run on the JVM and use the standard Java libraries are an obvious target if they implement the library interfaces in a similar fashion.
American software copyright law has something called "non-literal copying", whereby the judge decides that something looks sort of like something else, even if they're not actually identical. That means the fact that the function and parameter names and the syntax decoration aren't the same doesn't mean that it isn't a copy. That's why Google can't simply make the whole problem go away with a bunch of "sed" scripts.
Third party trolls will have a field day as these newly created IP rights become the functional equivalent of new software patents. The fact that you wrote the software entirely yourself won't save you from copyright infringement claims, including claims of non-literal copying.
In other words, if you're in the software business, be prepared to be royally screwed by Oracle if the case goes their way.