Implement zip64 support for ZipFile/ZipInputStream/ZipOutputStream.

There are several open questions that I hope to resolve in future
changes :

- Our heuristics for detecting whether a zip outputstream should
  switch over to zip64 or not are imprecise.

- Also, given that we now officially support zip64, we have to assume
  new entries whose size is unknown need the zip64 header / footer.
  This will make output files slightly larger and less compatible with
  older tools. If we don't do this, we'll have to go back and rewrite &
  compact parts of the stream we'd already flushed, which isn't always
  possible. The other option is to assume zip32 for streams of unknown
  length and throw if more than 4G of data is written to them.

Change-Id: Ibb4a97b5f83fd3ab850d7c407ecfda663968a6b9

1 files changed, 9 insertions, 0 deletions

diff --git a/expectations/knownfailures.txt b/expectations/knownfailures.txt
index c6d3dd7..77d301e 100644
--- a/expectations/knownfailures.txt
+++ b/expectations/knownfailures.txt
@@ -1492,5 +1492,14 @@
   names: [
     "org.apache.harmony.tests.java.nio.charset.CharsetTest#testForName_withProviderWithRecursiveCall"
   ]
+},
+{
+  description: "Zip64 tests take too long to execute and need more than 5GB of space to run.",
+  result: EXEC_FAILED,
+  names: [
+    "libcore.java.util.zip.ZipFileTest#testZip64Support_largeNumberOfEntries",
+    "libcore.java.util.zip.ZipFileTest#testZip64Support_totalLargerThan4G",
+    "libcore.java.util.zip.ZipFileTest#testZip64Support_hugeEntry"
+  ]
 }
 ]