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 `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-