Unpack .tar.bz2 and .tar.xz, which only half-extracted

formatOf matched .tar.gz/.tgz as a combined format and then fell through to the bare .bz2 and .xz wrappers, so a .tar.bz2 was read as one compressed file: extracting it decompressed a single layer and left a .tar to extract again, while the same archive named .tar.gz unpacked in one step. The store listing advertised "extract ZIP, TAR, TAR.GZ, GZ, BZ2, XZ and 7z", which reads as though they all behave alike.

Found by extracting one archive of every supported format through the UI on the API 35 AVD rather than trusting the suite. A real z4.tar.bz2 left z4/z4.tar - raw ustar headers and all - beside z3.tar.gz fully unpacked to z3/a.txt and z3/sub/b.txt.

TAR_BZIP2 and TAR_XZ now sit alongside TAR_GZIP, detection consumes the whole tar suffix (.tar.bz2/.tbz2, .tar.xz/.txz) before the bare compressor, and the engine gains the two readArchive branches. The bare spellings still mean a single compressed file.

The suite had a gap that let this hide: only ZIP, GZIP, XZ and 7z had round-trip tests, so neither plain TAR nor TAR_GZIP did, and there was nothing for the asymmetry to contradict. All four tar spellings have one now, built in memory with the same library that reads them. 212 JVM tests, lint clean.

Also records the format sweep in EDGE_CASE_TESTING and re-measures the release artefacts (aab 4 838 235 / sha256 e1d23130..., apk 2 155 455 / sha256 37fb46cb...). The APK byte count happened to land on the same figure as the previous build, so the new literals were confirmed present in the shipped dex rather than trusted to the size.

CHANGELOG.md

@@ -46,6 +46,18 @@ upload needs a **higher `versionCode`** than every previous upload.
   gesture that had already proved flaky; the note that this path "is still worth a manual pass"
   turned out to be exactly right.
 
+- **`.tar.bz2` and `.tar.xz` did not unpack, unlike `.tar.gz`.** `ArchiveFormats.formatOf`
+  matched `.tar.gz`/`.tgz` as a combined format but let `.tar.bz2` and `.tar.xz` fall through to
+  the bare `.bz2` and `.xz` wrappers, so extracting one decompressed a single layer and left the
+  user holding a `.tar` to extract again — while the same archive named `.tar.gz` unpacked in one
+  step. The store listing advertised "extract ZIP, TAR, TAR.GZ, GZ, BZ2, XZ and 7z", which reads
+  as though all of them behave alike. Found by extracting one of every supported format through
+  the UI on a device instead of trusting the unit tests, which is also how the `.xz` crash was
+  found. `TAR_BZIP2` and `TAR_XZ` now sit alongside `TAR_GZIP`, detection consumes the whole tar
+  suffix before the bare compressor, and round-trip tests cover all four tar spellings — and the
+  suite had a gap there worth naming: neither plain `TAR` nor `TAR_GZIP` had a round-trip test
+  either, so the asymmetry had nothing to fail against.
+
 - **`.xz` extraction would have crashed on a real device.** Commons Compress declares its
   LZMA/LZMA2 support — the `.xz` compressor and the 7z format — against `org.tukaani:xz` as
   an **optional** dependency. Optional means it is not pulled in transitively, so nothing