You are misunderstanding the fair-use factor 3, the amount copied. That isn't a positive defense, at best it is neutral: Google can say "We copied no more than necessary." But Oracle will try to argue that they did copy more than necessary.
None of them are positive defenses. All are factors that weigh more or less in favor of fair use or against it. They are also not exhaustive, the jury can use other factors as well. Read the jury instructions.
Amount used (in comparison to the infringed work) is an important factor. The amount of copied material compared to the rest of the infringing work is also a factor, it goes to "the purpose and character of use" - if most of your work is just copied material, it weight against fair use. In Sega, the entire ROM was copied many times in it's entirety, even downloaded from the Internet, for an explicitly commercial use, yet they won on fair use with those two factors completely against them. One factor was that none of the protected material actually ended up in the finished product, other than a very small piece of code that was challenged on trademark but not copyright (and Sega lost on that as well). The other factor was the use and purpose of the copying.
The Java API is clearly HIGHLY functional, and Google clearly copied the absolute minimum required to use it. The only copied material is the names and the relationships between the names, and changing a single character of any of those names would cause that portion of the API, and quite possibly the whole system, to completely fail. Hard to get more functional than that.
Indeed, rather than show that the API was "the heart" of Android, Oracle's demonstration served to show how functional it is (especially since ANY section of code removed from Android, whether from the API or anywhere else, would also make it fail).
The "nature of the copyrighted work" is clearly functional. You don't decide you want to replace the API in your project because you're tired of looking at this one and would like something fresh and new. You don't buy a product that uses Java inside for the artfully selected names like java.net.HttpURLConnection.setChunkedStreamingMode(), and if all the names were changed to AAAAA AAAAB AAAAC, etc. it would be just as functional, except it would be hard to write code for (so, again, the names are functional).
It may take creativity to create it, but the work is functional, and the purpose for copying it is for the function.
In brief, when considering merger for copyright protection, you need to consider the options available to Sun when they originally wrote Java: there were plenty of ways they could have written any of those APIs.
The CAFC confused merger with scènes à faire. Merger is independent of point of view, it either is or it isn't.
The API is an abstraction, it is an idea, protection is not supposed to "extend" to it. The expression is indeed copyrighted, but the idea expressed is not protected.
The CAFC said that the "idea" was "an API", but that isn't what is expressed by the source code. The source code expresses a very specific API, the Java API. That is the "idea" that is not protected, whether you call it a process, a system, or a method of operation, 102(b) says the idea is not protected.
Look at Baker v Selden or Bikram, the idea was not "an accounting system" or "a sequence of yoga poses" the way the CAFC would have you believe. In Bikram the Ninth completely rejected that the idea of "the Sequence" could be protected even though there were any number of ways it could have been created. Bikram was just about the idea being used, but once you have the ruling that the idea is not protected, merger can come into play. For example, expressing the Sequence as a simple list of each of the 26 poses by name would not be protected expression, as almost any expression of the Sequence would necessarily infringe on it.
The Ninth ruled that the Sequence was not protected because it was a system. Not because it was too simple, or not creative, or not choreography, but because it was a system and thus any copyright in the written expression of the Sequence does not extend to the Sequence itself because of 102(b).
Merger occurs AFTER you determine that the idea is not protected. Then, any expression that is required to express that idea (given various factors such as efficiency, industry standards, etc) loses protection itself, since otherwise the idea becomes protected, no one can express it. That's what merger is.
So, unless copyright barred Google from using Java the language, once Google chose to use Java, the declarations effectively wrote themselves. There's only one way to write them in Java without changing the function. They can be written by a program, given a description of the Java API in another form (the compiled library) using javap. That's the very essence of merger.
Once you have merger, then it doesn't matter if you recreate the expression from the idea, or if you simply copy/paste from some other expression of the idea. They'll be the same thing, with only minor differences (and those minor differences that can exist did exist in Google's code, they did not just copy/paste, they didn't even copy from Oracle's code).
My point is that even if Google loses, there is plenty of reason that the ruling would not apply to most other open source projects, like Wine or Samba. There are clear differences between what Samba is doing and what Google did.
Wine and Samba (and many other open source projects) duplicate an API without permission. They are infringing, or would be if the CAFC ruling had any weight. They could be sued, and anyone using them could be sued, and whether it would be found to be fair use is anyone's guess.