[feature] Load XAPKs directly

[yoshimo]

APKPure has multi-arch apps in an XAPK file, which is more or less just a zip archive with multiple apks inside.
It would be nice if we could load them directly without unpacking them first and load the folder instead.

[iscle]

@skylot Hey, any plans on implementing this soon? I could do a PR myself if you're willing to review it and point out any changes you might see are necessary to meet the coding standard of the project.

I've noticed that lately more and more apps are only available as xapk from sites such as apkmirror and it's a pain in the ass to extract them before loading them.

[skylot]

@iscle sure, PR will be great 👍

[iscle]

I've been working on this (I've decided to create a new plugin instead of modifying the existing jadx-dex-input) and I feel like especially the input plugins could maybe be improved a bit, with some sort of priority and maybe mutual exclusion so that if, for example, the xapk plugin supports the file, the dex plugin does not get executed.

I've also seen repeated functionality such as functions to read all bytes from an InputStream that maybe could be moved to a common project.

Is this something you've considered?

[iscle]

Furthermore, I've seen a few issues on how jadx handles resources and AndroidManifest.xmls. As you might know, xapk files are just a zip file with many apks inside and a few other support files such as a manifest.json and icon.png.
Each of the split apk contains an AndroidManifest.xml, as well as some resources. If I extract the xapk and then load all the extracted files into jadx directly, the AndroidManifest.xml that will appear in the editor will be a random one.

It would be nice if the UI either showed all of them (maybe with a smaller gray text specifying which file it came from) or selected the "base" one (which we know as it's specified in the xapk manifest.json).

In my opinion, a refactor on the loading code logic and structure would be a great improvement to jadx. :)

[skylot]

Now every plugin search for supported files from input and output decoded results.
To implement your suggestion we can run a global loop over all input files (with zip traversal) and asking every input plugin for decoding result (or even transform to other file format, so other plugins can decode it) and if file is supported stop asking other plugins. This will also allow plugin ordering. I was planing to implement similar thing to support resources decoding in plugins. Such changes require big refactoring with API changes and all plugins rewrite, so it is a lot of work.

As for xapk support, I thought it should be done in dex input plugin with zip unpacking like it already done for apk. This way it not require big refactoring and use will use already implemented approach.

For common parts we can just use jadx-core or jadx-input-api modules.

[skylot]

It would be nice if the UI either showed all of them

I think we can show all files under Resources node as is, every apk can be made expandable, so it will be possible to check all inner files.

[iscle]

A simple modification to the dex input plugin will allow xapk files to be loaded and show decompiled code just fine. However, none of the resources will get loaded because of the way jadx is handling it (basically searching for them in the main file, and not "asking" the plugins to do it instead).

I'm sure with some tweaks it could be made to work, but it will be a bit messy in my opinion. You are right that it will require a lot of work to refactor the code and modify the API but I think it's the right way to do it. Of course, let me know your thoughts, as you're much more familiar with the project than I am :)