tags 1099632 + pending
thanks
Matt Corallo wrote:
In the first instance, just to confirm that file(1) is at fault here? As
in, these are definitely not Android packages. :)
They're android "packages" in that they're libraries that other APKs
can depend on, but certainly not runnable apps or anything of the like.
Getcha. I suppose it was kinda understandable that they lumped them
together as being APK related, even though it's not strictly accurate.
However, that "packages" comes from file(1) itself rather than
diffoscope itself. They may be interested in ensuring the accuracy of
that description: I'm convinced, but you will have to contact the file
upstream for this.
AFAIU, all "Android package (APK)"s should be treated like zips cause
they are just zips with specific files in them.
They are, yes! But diffoscope has special handling for APK files as it
can improve the output for those files, even though they are, as you
say, "just" zip files underneath.
What was preventing diffoscope handling your .aar files properly,
though, was that this special handling for APK files was reserved for
files with the .apk extension only, even if file(1) was reporting them as
an "APK package".
Extending this code to consider AAR files as equivalent as APK files
(at least as far as *diffoscope* is concerned), results in it not
falling back to a binary diff.
--- diffoscope/comparators/apk.py
+++ diffoscope/comparators/apk.py
@@ -238,7 +238,7 @@ class ApkFile(ZipFileBase):
FILE_TYPE_HEADER_PREFIX = b"PK\x03\x04"
FILE_TYPE_RE = re.compile(r"^(Android package|(Java|Zip) archive data)\b")
- FILE_EXTENSION_SUFFIX = {".apk"}
+ FILE_EXTENSION_SUFFIX = {".apk", ".aar"}
CONTAINER_CLASSES = [ApkContainer, ZipContainer]
I've made this change in Git and I plan to release it later this week.
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'`
lamby@debian.org 🍥 chris-lamb.co.uk
`-
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)